[PATCH] D130055: Clang extensions yolo, woot & kaboom

[Jan Korous via Phabricator via cfe-commits]

jkorous added a comment.

In D130055#3683173 <https://reviews.llvm.org/D130055#3683173>, @aaron.ballman wrote:

> Are there circumstances where we cannot "simply" infer this from the constructor itself? (After instantiation) we know the class hierarchy, we know the data members, and we know the ctor init list/in-class initializers, so it seems like we should be able to recursively mark a constructor as yolo for the user rather than making them write it themselves.

The init list can be in a different translation unit (TU) which means we can't compute all properties just from the code in current TU. (Unless we decide to pessimistically consider such unanalyzable constructors as non-initializing.)
Some variation of proposed attributes could work as the cross-TU communication channel that would provide the missing information based on analysis of other TUs.

Example - 1 header, 1 implementation file, 1 file with client code:

- foo.hpp
- foo.cpp - implements interface in foo.hpp
- client_of_foo.cpp - uses the interface from foo.hpp.

We can have per-TU analysis that results in correct attributes in the header:

- foo.cpp - Analysis of the available implementation can verify correctness of `[[yolo]]` attributes on related declarations in foo.hpp.
- client_of_foo.cpp - Analysis of the implementation can take into the account attributes in foo.hpp. (And inductively we should also verify correctness of attributes on related declarations.)

That way we could infer properties based on code in current implementation file and attributes on declarations it uses from headers.
I believe we should be able to have one-TU-at-a-time analysis that could guarantee correctness of the attributes on declarations (or warn otherwise) and that could iteratively give us full-project (global) correctness.
The order in which we analyze TUs shouldn't matter as long as we analyze all of them.

BTW Even for the constructor analysis - the base class initializer list can be in another TU again.

> It seems like inferring this would reduce false positives and false negatives

I strongly support the idea that we should not put the burden of not making mistakes on the user if we can make a tool that guarantees or verifies correctness.

> ... we might only need this attribute in very rare circumstances ...

I think this is orthogonal to the above but agree that changing the default for constructors to be implicitly `[[yolo]]` could be a win for ergonomics.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D130055/new/

https://reviews.llvm.org/D130055