Skip to content

[clang] Don't warn on zero literals with -std=c2y #149688

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jul 21, 2025

Conversation

anematode
Copy link
Contributor

Fixes #149669; the old check compared with the end of the literal, but we can just check that after parsing digits, we're pointing to one character past the token start.

@llvmbot llvmbot added clang Clang issues not falling into any other category clang:frontend Language frontend issues, e.g. anything involving "Sema" labels Jul 20, 2025
@llvmbot
Copy link
Member

llvmbot commented Jul 20, 2025

@llvm/pr-subscribers-clang

Author: Timothy Herchen (anematode)

Changes

Fixes #149669; the old check compared with the end of the literal, but we can just check that after parsing digits, we're pointing to one character past the token start.


Full diff: https://github.com/llvm/llvm-project/pull/149688.diff

2 Files Affected:

  • (modified) clang/lib/Lex/LiteralSupport.cpp (+1-1)
  • (modified) clang/test/C/C2y/n3353.c (+3-5)
diff --git a/clang/lib/Lex/LiteralSupport.cpp b/clang/lib/Lex/LiteralSupport.cpp
index a62508e3e27bf..5b08d7f0efe5a 100644
--- a/clang/lib/Lex/LiteralSupport.cpp
+++ b/clang/lib/Lex/LiteralSupport.cpp
@@ -1467,7 +1467,7 @@ void NumericLiteralParser::ParseNumberStartingWithZero(SourceLocation TokLoc) {
   if (s != PossibleNewDigitStart)
     DigitsBegin = PossibleNewDigitStart;
   else
-    IsSingleZero = (s == ThisTokEnd); // Is the only thing we've seen a 0?
+    IsSingleZero = (s == ThisTokBegin + 1);
 
   if (s == ThisTokEnd)
     return; // Done, simple octal number like 01234
diff --git a/clang/test/C/C2y/n3353.c b/clang/test/C/C2y/n3353.c
index cd61cbf039067..44dc1cabae2a1 100644
--- a/clang/test/C/C2y/n3353.c
+++ b/clang/test/C/C2y/n3353.c
@@ -44,7 +44,9 @@ static const void *ptr = 0o0;  /* ext-warning {{octal integer literals are a C2y
 #endif
 
 // 0 by itself is not deprecated, of course.
-int k = 0;
+int k1 = 0;
+long k2 = 0l;
+unsigned long long k3 = 0ull;
 
 // Test a preprocessor use of 0 by itself, which is also not deprecated.
 #if 0
@@ -65,7 +67,6 @@ static_assert(__extension__ _Generic(typeof(l), const int : 1, default : 0)); //
 
 // Note that 0o by itself is an invalid literal.
 int m = 0o; /* expected-error {{invalid suffix 'o' on integer constant}}
-               c2y-warning {{octal literals without a '0o' prefix are deprecated}}
              */
 
 // Ensure negation works as expected.
@@ -83,13 +84,11 @@ int n = 0o18; /* expected-error {{invalid digit '8' in octal constant}}
                  cpp-warning {{octal integer literals are a Clang extension}}
                */
 int o1 = 0o8; /* expected-error {{invalid suffix 'o8' on integer constant}}
-                 c2y-warning {{octal literals without a '0o' prefix are deprecated}}
                */
 // FIXME: however, it matches the behavior for hex literals in terms of the
 // error reported. Unfortunately, we then go on to think 0 is an octal literal
 // without a prefix, which is again a bit confusing.
 int o2 = 0xG; /* expected-error {{invalid suffix 'xG' on integer constant}}
-                 c2y-warning {{octal literals without a '0o' prefix are deprecated}}
                */
 
 // Show that floating-point suffixes on octal literals are rejected.
@@ -130,7 +129,6 @@ constexpr int p = 0o0'1'2'3'4'5'6'7; /* compat-warning {{octal integer literals
                                       */
 static_assert(p == 01234567); // c2y-warning {{octal literals without a '0o' prefix are deprecated}}
 int q = 0o'0'1; /* expected-error {{invalid suffix 'o'0'1' on integer constant}}
-                   c2y-warning {{octal literals without a '0o' prefix are deprecated}}
                  */
 
 #define M 0o123

@tbaederr tbaederr requested a review from AaronBallman July 20, 2025 07:04
Copy link
Collaborator

@AaronBallman AaronBallman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thank you for the fix! (I also like that this fixed some spurious add-on diagnostics.)

@AaronBallman
Copy link
Collaborator

Do you need someone to land this on your behalf?

@AaronBallman
Copy link
Collaborator

Do you need someone to land this on your behalf?

I'm going to assume yes, but mostly I want to get this pushed so we can backport it to the release branch.

@AaronBallman AaronBallman merged commit 8366dc2 into llvm:main Jul 21, 2025
9 checks passed
@AaronBallman AaronBallman added this to the LLVM 21.x Release milestone Jul 21, 2025
@github-project-automation github-project-automation bot moved this to Needs Triage in LLVM Release Status Jul 21, 2025
@AaronBallman
Copy link
Collaborator

/cherry-pick 8366dc2

@llvmbot
Copy link
Member

llvmbot commented Jul 21, 2025

/pull-request #149842

@llvmbot llvmbot moved this from Needs Triage to Done in LLVM Release Status Jul 21, 2025
tru pushed a commit to llvmbot/llvm-project that referenced this pull request Jul 22, 2025
Fixes llvm#149669; the old check compared with the end of the literal, but
we can just check that after parsing digits, we're pointing to one
character past the token start.

(cherry picked from commit 8366dc2)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clang:frontend Language frontend issues, e.g. anything involving "Sema" clang Clang issues not falling into any other category
Projects
Development

Successfully merging this pull request may close these issues.

Unexpected -std=c2y octal warnings on zero with type suffix
4 participants