Thank you for the review, Aaron!

• Don't crash when pretty-printing an Attribute with optional type argument
• Don't crash AST dump when Owner/Pointer has no Type argument
• gsl::Owner/gsl::Pointer: Make DerefType parameter optional
• Unify type and non-type attribute parsing; don't add OwnerAttr/PointerAttr twice
• Improve documentation

In D64448#1581771, @gribozavr wrote:

In D64448#1581719, @mgehre wrote:

In D64448#1577779, @gribozavr wrote:

I don't know how various versions of libstdc++ differ.

The current implementation passed the (partial) test case
https://github.com/mgehre/llvm-project/blob/lifetime-ci/lifetime-attr-test.cpp
for different standard libraries, namely libc++ 7.1.0, libc++ 8.0.1rc2, libstdc++ 4.6.4, libstdc++ 4.8.5,
libstdc++ 4.9.4, libstdc++ 5.4.0, libstdc++ 6.5.0, libstdc++ 7.3.0,
libstdc++ 8.3.0 and libstdc++ 9.1.0.

Yes, I saw the testcase -- but how do different libstdc++ versions differ?

I didn't know whether they would differ, but the test tells me that they don't differ significantly (i.e. in introducing new techniques).
Would you like me to test with other standard libraries (besides MSVC, which I already planned)?

• Implement comments

This should address all remaining comments.

Implement comments

In D64448#1577779, @gribozavr wrote:

For example, libc++ wraps everything in std in an inline namespace.

I believed that I had written a test for inline namespaces, but seems that I shouldn't be working in the middle of the night.
I will add one.

Move checks into AST matchers

• Address review comments

Friendly ping. Are there outstanding concerns that I could address?

• Make the list of attribute properties more consistent.

• Add newline at end of file

I understand that putting types on forward declared header (standard libraries / third party libraries) is not a approach we should favor.
Thank you for your good arguments.
API notes seems like a really good approach for this (I would like to help with the upstreaming), and in the meanwhile
I will work on hard-coding attributes for standard library types in clang for a follow-up PR. I think we could have them always attached (I will measure performance),
so that -Wlifetime will not change the AST.

• Address more review comments.
• git-clang-format

Address some review comments.

We can and should explore both options and see what works best.

We can try to add the annotations to libcxx (which will still take time),
but there are also other standard libraries (libstdc++, MSVC) that
can be used with clang.
Eventually everybody will have lifetime annotations (of course ;-) ),
but in the meantime there seems to be no other way to enable
the analysis on unmodified STL.

Fix typo

Fix rewrapped comment

Ping

Fix wrong merge of ReleaseNotes

Remove `const` part from this PR. Address comments.

Do I wait for @alexfh to turn his red into a green, too?

I have thought about splitting the check into separate static & const, but kept it together because
the analysis for both cases is very similar, i.e. finding the usage of this.

Implement review comments

Thank you for the review input! After learning about inlinehint, I don't feel its worthwhile for me to continue this check.

Does it also work with lambdas (being implicitly auto) that return pointers? A test case for that would be nice.

I would be against make this the default. Maybe provide it as an option?

Implemented all review comments
Use global settings "UseAssignment"

Please consider also https://reviews.llvm.org/D15031
It already handles all possible control flows. Instead of ScopeBegin and ScopeEnd,
it introduces LifetimeEnds elements. It's a more specific in that is also
correctly models the order of lifetime expiry of variables and the order
or destructor calls / lifetime ending.

Please have a look at the discussion in https://reviews.llvm.org/D18914 (which is for a similar check)
It turns out that an inline specifier which is redundant for deciding linkage is still
used to drive the inliner. Basically, the inliner will consider larger function bodies for inlining
if the have an explicit inline specifier.

Did you run this check over the llvm/clang code base?

only check C++ code; only match operators that can have alternative representations

Friendly ping

Put 'u' and 'l' on integer literals

Updated for comments

Improved diagnostic; updated documentation; added test for overloaded operator

Friendly ping

Rename check to readability-operators-representation

Add suffix for floating point literals; clang-format

Added test to misc; minor wording

Thank you for the comments; all of them have been addressed.

Thanks for your feedback, Eugene!

Friendly ping