thanks Jim

lgtm

Before this, I didn't realize that quit/exit worked without being a function call. I think it's unfortunate we have to preserve that, but oh well.

This is good, but it also illustrates how the strings "->" and ".'" should actually come from the typesystem and not be hardcoded. We're just lucky that all languages have a "." operator.

More elegant would be to just add an API to TypeSystem to get the operator to access ivars.

check valid compiler type

use explicit type instead of auto

update TestConvenienceVariables.test

add test/API/sanity/TestReprStrEquality.py

Note also that the tests use str() in many places, so we can be sure this hasn't regressed that. I will add a test for repr.

thank you again

@mib I tried but failed to answer that in the original commit description. I have reworded it to be more clear. Here's the relevant paragraph:

@JDevlieghere assertEquals is the deprecated name, assertEqual is the

nice, I've wanted this too.

instead of reducing and picking returning a single result, can we return the raw counts and then report the totals of the counts?

That means that if you have a test that has 3 passes and 4 skips, it will be reported as unsupported (while currently it's considered a pass).

I noticed that the example python command and this feature don't support specifying breakpoint locations. Should it?

thank you for fixing!

+1 – it doesn't make sense to have to repeat the same -arch flag and value N times for N binaries.

thanks!

The patch gets a little hard to read with all the no-longer in the right places comments

@DavidSpickett I might do some follow up work, if so I will add coverage then.

add to TestHelp.py

thanks for fixing these, especially the lr technique!

Fixed/improved docstring

Addresses Adrian's feedback.

Fixed: comment formatting; bool logic bug

Updated for code review.

thanks for the review @DavidSpickett

I don't agree that an #include and a function call "add complexity". By that reasoning, writing any code is adding complexity, and then the question is not whether code is complex (because it all would be), and only whether reviewers choose to evoke a "code complexity" argument. The llvm project has lots of complexity, and I don't believe this is an example of it.

@MaskRay sorry for butting in, but what am I missing here? The hardline and opaque rejection don't reconcile with such a minor change. To me, there is no complexity whatsoever to this change. You mention consistency, but don't say with what (which doesn't allow people to make their own judgement). I also don't see how feature orthogonality relates. Rejections happen, but I think it's rejections ought to be clear to readers, and in this instance I found it confusing.

There's some CMake trickery

Ignore previous comment, wrong diff.

Merged in rG3ca91adef8e885d89658a540860d3cee8746b1d9