juanvazquez wrote:

Hi @cor3ntin,

> For this to work you would also need to understand what the default 
> constructor does, would not that require additional annotation.
> ie, in the case of unique_ptr, how do you know the object is initially null?

In the case of unique_ptr, the standard tells what the default constructor 
does. And tells the state of the moved from ptr after a move constructor or 
assignment. Although this annotations is to be used by user defined types 
(likely user defined pointer-like implementations).

And the important bit is that the object moved from is not left unspecified 
anymore. Instead the user defined type is making guarantees about the state of 
the moved-form object. imho, even without additional annotations describing the 
exact guarantees, this annotation is enough to help static analyzers.

Maybe there is a better alternative for the name of the attribute to convey the 
information and avoid confusion. Feel free to share if there are any 
suggestions :-)

> You also need to know that the object was moved which is the more difficult 
> bit.

That is the job of the static analyzers. For instance the 
bugprone-use-after-move tidy check. This annotation will help the tidy to avoid 
false positives.

Would it help if I share early how the bugprone-use-after-move tidy would use 
this attribute?

https://github.com/llvm/llvm-project/pull/178432
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to