[clang] clang::drop attribute (PR #204318)
Yanzuo Liu via cfe-commits
cfe-commits at lists.llvm.org
Wed Jun 24 23:50:40 PDT 2026
zwuis wrote:
> > I don't understand this example. If we change `bar(std::move(x))` to `bar(drop(x))`, `use(x)` uses `x` after it has been dropped.
>
> use(x) will be error
I see, but `bar(std::move(x))` has been already handled correctly by bugprone-use-after-move.
> > bugprone-use-after-move
>
> Its cland-tidy check, not clang itself, isnt it?
>
>
> Why additional attribute needed:
>
> 1. now clang hardcodes isStdMoveCall
> 2. Now clang warns about move on "trivial" types. E.g. code with foo(std::move(my_string_view)) will be warned, while foo(drop(my_string_view)) will explicitly do what it says and dont warn
If you make it clang-tidy check, users can specify which parameters will be dropped, which is almost equivalent to attributes. See [the documentation of bugprone-use-after-move](https://clang.llvm.org/extra/clang-tidy/checks/bugprone/use-after-move.html#options) for example.
> Coroutine example shows case when you dont move object, but it shoud be inaccessable after co_await
There is a PR working on it for bugprone-use-after-move. (#172566)
---
Perhaps it would be better to move it to clang analysis warnings like thread safety analysis and lifetime safety analysis, because analysis on complex control flow may be involved. Personally I'd suggest make it a clang-tidy check.
https://github.com/llvm/llvm-project/pull/204318
More information about the cfe-commits
mailing list