cor3ntin added inline comments.
================
Comment at: clang/include/clang/Basic/DiagnosticLexKinds.td:290
+ "encoding prefix '%0' on an unevaluated string literal has no effect"
+ "%select{| and is incompatible with c++2c}1">,
+ InGroup<DiagGroup<"invalid-unevaluated-string">>;
----------------
hubert.reinterpretcast wrote:
> aaron.ballman wrote:
> > hubert.reinterpretcast wrote:
> > > I am not seeing any tests covering C mode.
> > >
> > > @aaron.ballman, can you confirm that you are okay with the warning when
> > > processing C code (and, moreover, the newly-added errors for numeric
> > > escape sequences)?
> > >
> > Good call on C test coverage, thank you for bringing that up!
> >
> > I think the behavior in C is reasonable, even if it's not mandated by the
> > standard. We're going from issuing an error in C to issuing a warning and
> > the warning text helpfully omits the C++2c part of the diagnostic, so it
> > seems like we're more relaxed in C than we previously were.
> >
> > Do you have concerns about the behavior in C? (Or are you saying you'd
> > prefer this to be an error in C as it was before?)
> My question was with respect to the change from the Clang 16 status quo for
> numeric escapes introduced by the prior change and carried forward with this
> one: https://godbolt.org/z/aneGr1Yfb
>
> ```
> _Static_assert(1, "\x30"); // error in Clang 17
> ```
>
Yes, this is intended, numeric escape sequences in unevaluated string literals
are not allowed in any language modes - the motivation for C is the same as
C++.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D156596/new/
https://reviews.llvm.org/D156596
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
