+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 <[email protected]>
wrote:
> How about something along these lines?
>
> ~Aaron
>
> On Tue, Jul 22, 2014 at 6:57 PM, Richard Smith <[email protected]>
> wrote:
> > On Tue, Jul 22, 2014 at 3:47 PM, Aaron Ballman <[email protected]>
> > wrote:
> >>
> >> On Tue, Jul 22, 2014 at 6:40 PM, Richard Smith <[email protected]>
> >> wrote:
> >> > On Tue, Jul 22, 2014 at 3:39 PM, Richard Smith <[email protected]
> >
> >> > 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.
>
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
