On Jul 14, 2011, at 5:19 PM, Chandler Carruth wrote:
> On Thu, Jul 14, 2011 at 5:04 PM, Douglas Gregor <[email protected]> wrote:
> IMO, the right approach would be to suppress this warning when the constant
> value itself was instantiated from something... although that's rather
> trickier to implement.
>
> I don't disagree with your premise.... but it does seem much trickier to
> implement. We don't have the nice type sugar in non-types to indicate that
> substitution took place. Is it worth adding that for this? Are there other
> good reasons to add it?
Yes, there are other reasons to add it. For one, it helps us track the
correlation between instantiation and definition, but it also leads to a more
sane AST for instantiations that's also consistent with the way we handle
substitutions of template type and template template parameters. See, for
example, the FIXME in Sema::BuildExpressionFromIntegralTemplateArgument
regarding enumeration values.
> (Also, this patch seems a strict improvement, and we can add the refined
> checking you're mentioning as a second step? I'd like to avoid the false
> positives we were seeing with the previous incarnation)
Unless I misunderstood the effect, it also eliminates some true positives as
well, in code like
if (dependent-thing && 0)
so it's not strictly an improvement. I'm not asking to revert it---the patch
probably does more good than harm---but I do believe that there is a better
solution.
- Doug
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
