On 03/18/2016 01:04 PM, Jeff Law wrote:
On 03/17/2016 03:16 PM, Martin Sebor wrote:
The difficulty I've run into with detecting these problems in later
phases is that some invalid expressions have already been simplified
by the front end. The example that applies here (even though this
is still the front end) is this:
Yea. I was hoping that the delayed folding work would be helping in
getting a more faithful representation out of the front-ends.
It should.
constexpr int* p = 0;
constexpr bool b0 = &p[0] == 0; // accepted
constexpr bool b1 = &p[1] == 0; // rejected
Both b0 and b1 are invalid and should be diagnosed, but only b1
is. b1 isn't because because by the time we see its initializer
in constexpr.c it's been transformed into the equivalent of "b1
= (int*)ps" (though we don't see the cast which would also make
it invalid).
But if we can avoid these early simplifying transformations and
retain a more faithful representation of the original source then
doing the checking later will likely be simpler and result in
detecting more problems with greater consistency and less effort.
Do we know where the folding is happening for this case and is it
something we can reasonably defer? ie, is this just a case we missed
as part of the deferred folding work and hence should have its own
distinct BZ to track?
Yes, why is it already folded?
Jason
