llvm / llvm/llvm-project

Missing deprecation and availability warnings for unannotated declarators following an annotated declarator in the same declaration

Open
#191,243 0 comments 0 reactions 0 assignees View on GitHub
clang:diagnostics
Dominant language
LLVM
Stars
40.5k
Forks
18.7k
PR merge metrics
PR metrics pending

Description

When a declaration list contains multiple declarators and the first is annotated with a deprecation or availability attribute, subsequent unannotated declarators using the same deprecated/unavailable type do not produce a diagnostic.

```
struct __attribute__((availability(macosx, introduced=10.15))) S1 {};
S1 a1 __attribute__((availability(macosx, introduced=10.15))), b1; // missing warning on b1

struct [[deprecated]] S2 {};
S2 a2 [[deprecated]], b2; // missing warning on b2
```

`b1` uses `S1` without any availability annotation and `b2` uses S2 without being deprecated. The annotation on the sibling declarator (`a1` and `a2`) should not suppress diagnostics for the other declarators in the list.

Related to [#191099](https://github.com/llvm/llvm-project/issues/191099), which covers the converse problem: a spurious warning on an annotated `using` alias whose aliased type carries the same attribute. Both issues stem from the same general area of how delayed diagnostics interact with declaration parsing.

Contributor guide

Open the contributing guide

Research direction

Start by compiling the two declaration examples in the issue and confirm that b1 and b2 lack the expected diagnostics. Trace the Clang declaration-parsing and delayed-diagnostic paths involved in availability and deprecated attributes. Done means each unannotated sibling declarator receives the appropriate warning without introducing a spurious warning for the annotated declarator or alias described in issue #191099.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
compilers
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.