Recast representation-sensitive tests as SemaCXX tests using array bounds

I'll update the tests to be in terms of constant/variable array length tomorrow. I think I've gotten through the rest of the comments.

Address remaining ExprConstant.cpp review comments

Use lvalue designator, add assertions for type matching

Make an initial pass at addressing the review comments

LGTM.

some test points check the error report for ambiguous call because of too many implicit cast choices from ext_vector_type to vector type.

It appears the answer is to update these tests and remove the restriction on the type class.

I can commit sometime today; thanks.

Address review comments by Marshall

In D50736#1200774, @hubert.reinterpretcast wrote:

In D50736#1200761, @mclow.lists wrote:

Is this test that's being added libc++ specific, or would it apply to other implementations as well?

The test can apply to other implementations as well (although I am not sure how the initializer_list include behaves under C++03 on other implementations). Is there some other place to put such tests?

It seems that test/std/numerics/rand/rand.eng/rand.eng.mers/ may be the place to add the test. I am looking into it.

In D50736#1200761, @mclow.lists wrote:

Is this test that's being added libc++ specific, or would it apply to other implementations as well?

The test can apply to other implementations as well (although I am not sure how the initializer_list include behaves under C++03 on other implementations). Is there some other place to put such tests?

Use cp -R, which is sufficient instead of cp -RPp

I'll commit with cp -R tomorrow then; thanks.

Maybe cp -R is sufficient? cp -RPp was the just-to-be-safe "minimal change".

Ping

Looks good to me.

In D33833#789436, @kuang_he wrote:

Can we get this patch reviewed by any chance?

@kuang_he; it is customary to "ping". In this case, "Ping 2".

Remove stray ellipsis treatment entirely

In D33339#759797, @rsmith wrote:

In D33339#759146, @hubert.reinterpretcast wrote:

The check-all target passes even if the ellipsis-after-declarator-id disambiguation as a declarator is removed entirely.

[...]

So, on the whole, the stray ellipsis treatment is both too complicated and not complicated enough.

I think if we want to keep it, the way to do that would be to carry on through the disambiguation process and treat it as a tiebreaker (that's what we do, for instance, if we see an undeclared identifier in a position where we're looking for a type). I'm not convinced that's worthwhile, especially since our existing testcases do not need this disambiguation rule, but perhaps we could remove the stray ellipsis treatment entirely for now and reconsider adding it back if we find poor diagnostics result from it later?

In D33339#759125, @rsmith wrote:

Should I assume our "misplaced ellipsis" diagnostic requires that we disambiguate the ill-formed ellipsis-after-declarator-id as a declarator in some cases? If so, do we have tests for that somewhere?

Tests for the diagnostics are in clang/test/FixIt/fixit-cxx0x.cpp and clang/test/Parser/cxx11-templates.cpp.
The check-all target passes even if the ellipsis-after-declarator-id disambiguation as a declarator is removed entirely. The disambiguation process is not needed in many cases, and—when it is—can choose the declarative interpretation for other reasons.

Has it been discussed whether this is something to be addressed in the optimizer as opposed to the front-end?

Address review comments; update to revision 294580

Ping 2?

Ping!

Address review comments; update to revision 292996

Friendly ping...