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 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
