Skip to content

[clang] Force AttributedStmtClass to not be scope parents #125370

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 1 commit into from
Feb 11, 2025

Conversation

YutongZhuu
Copy link
Contributor

@YutongZhuu YutongZhuu commented Feb 2, 2025

This PR addresses #84072.
Example from the issue:

void Func(int x) {
    switch (x) {
        [[likely]] case 0:
        case 1:
            int i = 3;
        case 2:
            break;
    }
}

Clang checks if case 2 can be reachable by checking its scope. The variable declaration should create a scope containing case 2, but due to the structure of the AST, case 2 gets the scope of the likely statement, but not int i = 3;. Therefore, I changed this code to force attribute statement not to be scope parents. Please confirm this is something legal to do :)

Copy link

github-actions bot commented Feb 2, 2025

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

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

llvmbot commented Feb 2, 2025

@llvm/pr-subscribers-clang

Author: Yutong Zhu (YutongZhuu)

Changes

This PR addresses #84072.


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

1 Files Affected:

  • (modified) clang/lib/Sema/JumpDiagnostics.cpp (+7-10)
diff --git a/clang/lib/Sema/JumpDiagnostics.cpp b/clang/lib/Sema/JumpDiagnostics.cpp
index d465599450e7ff..c5577e09a86a1c 100644
--- a/clang/lib/Sema/JumpDiagnostics.cpp
+++ b/clang/lib/Sema/JumpDiagnostics.cpp
@@ -597,15 +597,6 @@ void JumpScopeChecker::BuildScopeInformation(Stmt *S,
     LabelAndGotoScopes[S] = ParentScope;
     break;
 
-  case Stmt::AttributedStmtClass: {
-    AttributedStmt *AS = cast<AttributedStmt>(S);
-    if (GetMustTailAttr(AS)) {
-      LabelAndGotoScopes[AS] = ParentScope;
-      MustTailStmts.push_back(AS);
-    }
-    break;
-  }
-
   case Stmt::OpenACCComputeConstructClass: {
     unsigned NewParentScope = Scopes.size();
     OpenACCComputeConstruct *CC = cast<OpenACCComputeConstruct>(S);
@@ -658,7 +649,13 @@ void JumpScopeChecker::BuildScopeInformation(Stmt *S,
         Next = SC->getSubStmt();
       else if (LabelStmt *LS = dyn_cast<LabelStmt>(SubStmt))
         Next = LS->getSubStmt();
-      else
+      else if (AttributedStmt *AS = dyn_cast<AttributedStmt>(SubStmt)) {
+        if (GetMustTailAttr(AS)) {
+          LabelAndGotoScopes[AS] = ParentScope;
+          MustTailStmts.push_back(AS);
+        }
+        Next = AS->getSubStmt();
+      } else
         break;
 
       LabelAndGotoScopes[SubStmt] = ParentScope;

@dwblaikie
Copy link
Collaborator

Could you add a test case - check in clang/test to see if other tests for the diagnostic text in the original bug, and add a test case for that nearby (maybe the same file the diagnostic is already tested in)?

@AaronBallman
Copy link
Collaborator

Thank you for the fix!

Could you add a test case - check in clang/test to see if other tests for the diagnostic text in the original bug, and add a test case for that nearby (maybe the same file the diagnostic is already tested in)?

Also, please add a more descriptive summary of what's changing and why (it makes it easier on us when we have to dig through a blame a few years down the line) and a release note in clang/docs/ReleaseNotes.rst so users know about the fix.

@YutongZhuu
Copy link
Contributor Author

Could you add a test case - check in clang/test to see if other tests for the diagnostic text in the original bug, and add a test case for that nearby (maybe the same file the diagnostic is already tested in)?

Do you mean I should check if there exists a test for the original bug, if not, add one?

@AaronBallman
Copy link
Collaborator

Could you add a test case - check in clang/test to see if other tests for the diagnostic text in the original bug, and add a test case for that nearby (maybe the same file the diagnostic is already tested in)?

Do you mean I should check if there exists a test for the original bug, if not, add one?

I think David means to find a related test file to add a new test case into (and you can tell the file is related by searching for tests that have "cannot jump from switch statement to this case label" and adding the new test there, such as clang/test/CXX/stmt.stmt/stmt.select/stmt.if/p4.cpp).

@YutongZhuu
Copy link
Contributor Author

Could you add a test case - check in clang/test to see if other tests for the diagnostic text in the original bug, and add a test case for that nearby (maybe the same file the diagnostic is already tested in)?

Done

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.

Aside from the issue with the release notes, I think this LGTM!

Comment on lines 124 to 301

- Clang now omits shadow warnings for enum constants in separate class scopes (#GH62588).

- When diagnosing an unused return value of a type declared ``[[nodiscard]]``, the type
itself is now included in the diagnostic.

- Clang will now prefer the ``[[nodiscard]]`` declaration on function declarations over ``[[nodiscard]]``
declaration on the return type of a function. Previously, when both have a ``[[nodiscard]]`` declaration attached,
the one on the return type would be preferred. This may affect the generated warning message:

.. code-block:: c++

struct [[nodiscard("Reason 1")]] S {};
[[nodiscard("Reason 2")]] S getS();
void use()
{
getS(); // Now diagnoses "Reason 2", previously diagnoses "Reason 1"
}

- Clang now diagnoses ``= delete("reason")`` extension warnings only in pedantic mode rather than on by default. (#GH109311).

- Clang now diagnoses missing return value in functions containing ``if consteval`` (#GH116485).

- Clang now correctly recognises code after a call to a ``[[noreturn]]`` constructor
as unreachable (#GH63009).

- Clang now omits shadowing warnings for parameter names in explicit object member functions (#GH95707).

- Improved error recovery for function call arguments with trailing commas (#GH100921).

- For an rvalue reference bound to a temporary struct with an integer member, Clang will detect constant integer overflow
in the initializer for the integer member (#GH46755).

- Fixed a false negative ``-Wunused-private-field`` diagnostic when a defaulted comparison operator is defined out of class (#GH116961).

- Clang now diagnoses dangling references for C++20's parenthesized aggregate initialization (#101957).

- Fixed a bug where Clang would not emit ``-Wunused-private-field`` warnings when an unrelated class
defined a defaulted comparison operator (#GH116270).

.. code-block:: c++

class A {
private:
int a; // warning: private field 'a' is not used, no diagnostic previously
};

class C {
bool operator==(const C&) = default;
};

- Clang now emits `-Wdangling-capture` diangostic when a STL container captures a dangling reference.

.. code-block:: c++

void test() {
std::vector<std::string_view> views;
views.push_back(std::string("123")); // warning
}

- Clang now emits a ``-Wtautological-compare`` diagnostic when a check for
pointer addition overflow is always true or false, because overflow would
be undefined behavior.

.. code-block:: c++

bool incorrect_overflow_check(const char *ptr, size_t index) {
return ptr + index < ptr; // warning
}

- Fix -Wdangling false positives on conditional operators (#120206).

- Fixed a bug where Clang hung on an unsupported optional scope specifier ``::`` when parsing
Objective-C. Clang now emits a diagnostic message instead of hanging.

- The :doc:`ThreadSafetyAnalysis` now supports passing scoped capabilities into functions:
an attribute on the scoped capability parameter indicates both the expected associated capabilities and,
like in the case of attributes on the function declaration itself, their state before and after the call.

.. code-block:: c++

#include "mutex.h"

Mutex mu1, mu2;
int a GUARDED_BY(mu1);

void require(MutexLocker& scope REQUIRES(mu1)) {
scope.Unlock();
a = 0; // Warning! Requires mu1.
scope.Lock();
}

void testParameter() {
MutexLocker scope(&mu1), scope2(&mu2);
require(scope2); // Warning! Mutex managed by 'scope2' is 'mu2' instead of 'mu1'
require(scope); // OK.
scope.Unlock();
require(scope); // Warning! Requires mu1.
}

Copy link
Collaborator

Choose a reason for hiding this comment

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

It looks like a bunch of unrelated release notes came in; these should be dropped.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I made this change to resolve the conflicts with main. Should I not do this?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Resolving the conflict with main should have left just the one-line addition from your PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I see, thanks for the explanations.

require(scope); // Warning! Requires mu1.
}

- Clang now forces attributes to not be scope parents (#84072).
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
- Clang now forces attributes to not be scope parents (#84072).
- A statement attribute applied to a ``case`` label no longer suppresses
'bypassing variable initialization' diagnostics (#84072).

@YutongZhuu
Copy link
Contributor Author

Aside from the issue with the release notes, I think this LGTM!

Addressed, thanks for reviewing :)

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!

@AaronBallman AaronBallman merged commit 8d902f2 into llvm:main Feb 11, 2025
7 checks passed
Copy link

@YutongZhuu Congratulations on having your first Pull Request (PR) merged into the LLVM Project!

Your changes will be combined with recent changes from other authors, then tested by our build bots. If there is a problem with a build, you may receive a report in an email or a comment on this PR.

Please check whether problems have been caused by your change specifically, as the builds can include changes from many authors. It is not uncommon for your change to be included in a build that fails due to someone else's changes, or infrastructure issues.

How to do this, and the rest of the post-merge process, is covered in detail here.

If your change does cause a problem, it may be reverted, or you can revert it yourself. This is a normal part of LLVM development. You can fix your changes and open a new PR to merge them again.

If you don't get any reports, no action is required from you. Your changes are working as expected, well done!

@llvm-ci
Copy link
Collaborator

llvm-ci commented Feb 11, 2025

LLVM Buildbot has detected a new failure on builder openmp-offload-amdgpu-runtime running on omp-vega20-0 while building clang at step 7 "Add check check-offload".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/30/builds/15573

Here is the relevant piece of the build log for the reference
Step 7 (Add check check-offload) failure: test (failure)
******************** TEST 'libomptarget :: amdgcn-amd-amdhsa :: api/omp_host_call.c' FAILED ********************
Exit Code: 2

Command Output (stdout):
--
# RUN: at line 1
/home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/./bin/clang -fopenmp    -I /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.src/offload/test -I /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/openmp/runtime/src -L /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/offload -L /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/./lib -L /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/openmp/runtime/src  -nogpulib -Wl,-rpath,/home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/offload -Wl,-rpath,/home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/openmp/runtime/src -Wl,-rpath,/home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/./lib  -fopenmp-targets=amdgcn-amd-amdhsa /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.src/offload/test/api/omp_host_call.c -o /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/offload/test/amdgcn-amd-amdhsa/api/Output/omp_host_call.c.tmp /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/./lib/libomptarget.devicertl.a && /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/offload/test/amdgcn-amd-amdhsa/api/Output/omp_host_call.c.tmp | /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/./bin/FileCheck /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.src/offload/test/api/omp_host_call.c
# executed command: /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/./bin/clang -fopenmp -I /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.src/offload/test -I /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/openmp/runtime/src -L /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/offload -L /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/./lib -L /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/openmp/runtime/src -nogpulib -Wl,-rpath,/home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/offload -Wl,-rpath,/home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/openmp/runtime/src -Wl,-rpath,/home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/./lib -fopenmp-targets=amdgcn-amd-amdhsa /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.src/offload/test/api/omp_host_call.c -o /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/offload/test/amdgcn-amd-amdhsa/api/Output/omp_host_call.c.tmp /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/./lib/libomptarget.devicertl.a
# note: command had no output on stdout or stderr
# executed command: /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/runtimes/runtimes-bins/offload/test/amdgcn-amd-amdhsa/api/Output/omp_host_call.c.tmp
# note: command had no output on stdout or stderr
# error: command failed with exit status: -11
# executed command: /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/./bin/FileCheck /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.src/offload/test/api/omp_host_call.c
# .---command stderr------------
# | FileCheck error: '<stdin>' is empty.
# | FileCheck command line:  /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.build/./bin/FileCheck /home/ompworker/bbot/openmp-offload-amdgpu-runtime/llvm.src/offload/test/api/omp_host_call.c
# `-----------------------------
# error: command failed with exit status: 2

--

********************


Icohedron pushed a commit to Icohedron/llvm-project that referenced this pull request Feb 11, 2025
Example from the issue:
```c++
void Func(int x) {
    switch (x) {
        [[likely]] case 0:
        case 1:
            int i = 3;
        case 2:
            break;
    }
}
```

Clang checks if ``case 2`` can be reachable by checking its scope. The
variable declaration should create a scope containing ``case 2``, but
due to the structure of the AST, ``case 2`` gets the scope of the
``likely`` statement, but not ``int i = 3;``. Therefore, I changed this
code to force attribute statement not to be scope parents.

Fixes llvm#84072
joaosaffran pushed a commit to joaosaffran/llvm-project that referenced this pull request Feb 14, 2025
Example from the issue:
```c++
void Func(int x) {
    switch (x) {
        [[likely]] case 0:
        case 1:
            int i = 3;
        case 2:
            break;
    }
}
```

Clang checks if ``case 2`` can be reachable by checking its scope. The
variable declaration should create a scope containing ``case 2``, but
due to the structure of the AST, ``case 2`` gets the scope of the
``likely`` statement, but not ``int i = 3;``. Therefore, I changed this
code to force attribute statement not to be scope parents.

Fixes llvm#84072
sivan-shani pushed a commit to sivan-shani/llvm-project that referenced this pull request Feb 24, 2025
Example from the issue:
```c++
void Func(int x) {
    switch (x) {
        [[likely]] case 0:
        case 1:
            int i = 3;
        case 2:
            break;
    }
}
```

Clang checks if ``case 2`` can be reachable by checking its scope. The
variable declaration should create a scope containing ``case 2``, but
due to the structure of the AST, ``case 2`` gets the scope of the
``likely`` statement, but not ``int i = 3;``. Therefore, I changed this
code to force attribute statement not to be scope parents.

Fixes llvm#84072
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
None yet
Development

Successfully merging this pull request may close these issues.

5 participants