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

[Richard Smith]

+def err_integer_literal_too_large : Error<
+  "integer literal is a value that cannot be represented as %select{a|an}0
"
+  "%select{signed|unsigned}0 integer">;

I don't think the "is a value that" adds anything here. Also, I'd like to
see something that more directly says we don't have a signed/unsigned
integer type large enough.


 def err_integer_too_large : Error<
-  "integer constant is larger than the largest %0-bit unsigned integer
type">;
-def ext_integer_too_large_for_signed : ExtWarn<
-  "integer constant is larger than the largest %0-bit signed integer
type">,
+  "integer constant evaluates to value %0 that cannot be represented as a "
+  "%1-bit %select{signed|unsigned}2 integer">;

Please rename this to something about ICEs, and move it to
DiagnosticSemaKinds next to the existing err_ice_ diagnostics. (This is
pretty similar to ext_cce_narrowing...)


+def ext_integer_literal_too_large_for_signed : ExtWarn<
+  "integer literal is a value that cannot be represented as a signed
integer, "
+  "and will instead be interpreted as unsigned">,

Again, mentioning integer types and not just integers would make this
clearer.

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

> How about something along these lines?
>
> ~Aaron
>
> On Tue, Jul 22, 2014 at 6:57 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
> > 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/5be4d661/attachment.html>