r213657 - Provide extra information in the "integer constant is too large" diagnostic. This will be used to improve other diagnostics.

[Richard Smith]

On Tue, Jul 22, 2014 at 3:47 PM, Aaron Ballman <aaron at aaronballman.com>
wrote:

> On Tue, Jul 22, 2014 at 6:40 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
> > On Tue, Jul 22, 2014 at 3:39 PM, Richard Smith <richard at metafoo.co.uk>
> > wrote:
> >>
> >>  def ext_integer_too_large_for_signed : ExtWarn<
> >> -  "integer constant is larger than the largest %0-bit signed integer
> >> type">,
> >> -  InGroup<DiagGroup<"implicitly-unsigned-literal">>;
> >> +  "integer constant evaluates to value %0 that cannot be represented
> as a
> >> "
> >> +  "%1-bit signed integer">,
> >> InGroup<DiagGroup<"implicitly-unsigned-literal">>;
> >>
> >> This should probably go on to say that we're interpreting the value as
> >> unsigned.
> >>
> >> I also think we should have separate diagnostics for the case where we
> >> evaluate a constant expression (which should include the 'evaluates to
> value
> >> %0' part) and the case where it's a literal (where we shouldn't). We
> don't
> >> need to repeat things that are literally present in the source code.
> (Sorry
> >> for suggesting the unconditional change here, I hadn't really looked at
> the
> >> use cases other than the one in SemaDeclAttr.cpp)
> >
> >
> > Actually, more than this, I think the original diagnostic text was better
> > than any of the updated wordings in the case of a literal. The bit-width
> is
> > incidental; the point is that the literal doesn't fit in the largest
> signed
> > type.
>
> What about literals whose suffix defines the type, like
> 90000000000000000000UL?
>

Such a suffix does not really define the type. L means "no smaller than
long", not "exactly long". Arguably the new wording is better for the MS
i32/i64 suffixes, though.

... but the SemaDeclAttr diagnostic and the "integer literal too large"
diagnostic are different problems and should have separate diagnostics.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140722/daf4c7c0/attachment.html>