[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