================
@@ -2068,7 +2068,8 @@ bool Lexer::LexNumericConstant(Token &Result, const char
*CurPtr) {
}
// If we have a digit separator, continue.
- if (C == '\'' && (LangOpts.CPlusPlus14 || LangOpts.C23)) {
+ if (C == '\'' &&
+ (LangOpts.CPlusPlus14 || LangOpts.C23 || ParsingPreprocessorDirective)) {
----------------
AaronBallman wrote:
> Sure, but we don't have to expose that language extension to users, it can
> remain internal to the compiler.
This still doesn't address my concerns from earlier about how it impacts
maintenance of Clang itself:
> I don't think per-feature LangOptions is viable. There's digit separators,
> hex float support, binary literal support, different literal suffixes,
> various keywords, etc and that doesn't seem likely to scale well. Also, it
> makes it seem like we support a la carte language features when we don't --
> we intentionally don't want to let users disable standard features (in
> general; exceptions exist) and so that approach gives the impression
> contributors need to check both language mode and feature availability which
> is a maintenance concern.
How do we avoid this situation, as that's my primary concern.
https://github.com/llvm/llvm-project/pull/95798
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
