- fixed flags in RUN declaration in lit test
- added tests for C++20 concepts and requires clause
- added manual tokenization for AutoType return types which are not plain 'auto' to find source range
- 'const auto'
- 'Concept<int> auto'
- improved formatting of documentation
- support for 'decltype(...)'
- added test for bug 44206, which seems to be fixed
- removed stale FIXME
Is there an easier way to get the token previous to the function name?
I tried 2 online rst editors and they failed to format the code blocks inside the tables. Will this work with the clang documentation?
How do you want to handle these tests which require C++20? I have seen other checks use a separate file for tests which require a different language version.
Furthermore: how can I schedule another CI build with the newest version of the diff? When I go to the failed build from Harbormaster and I click restart, it rebuilds an older version of the diff. Thanks for the info!
The restart build feature is only really useful when something on trunk caused the failure and will restart the build with the diff it had when the build was first started. The CI should build each time you update the diff, not sure why it isn't, but I don't think there is a special way to fix that. As the failure was caused by the test cases you could try and run ninja check-clang-tools from your build directory to ensure things are working, Alternatively if you upload another diff it should force a new build.
That's exactly the issue; the tests run fine on my local machine. I run check_clang_tidy.py manually, since I lack some Unix tools for the full test suite. And the CI build that failed seems to have used the first verison of my diff, which I updated in the meantime. From my point of few the diff is ready. I am just waiting for feedback, a LGTM and a nice person who can commit it for me :)
There isn't, but if you find you're missing source location information for something, you can also consider modifying Clang to add that source location information and mark this as a dependent patch. It's not clear to me whether that would be worth the effort for this patch or not, but my preference is to avoid these little hacks whenever possible.
Should we verify that End is valid before doing this pointer arithmetic with a value derived from it? For instance, what if End points into the scratch buffer because it relies on a macro defined on the command line -- will the logic still work?
Why do we need to check that there aren't any nested local qualifiers?
I'm still wondering about this.
The change to the language standard line makes me wonder if the fixme below it is now stale, or if the test will fail in C++20 mode.
Great, it seems I forgot to submit the inline comments. Sorry about that!
Thank you for the hint! I considered this for the concept location in an AutoReturnType and the expression inside a decltype AutoReturnType. Unfortunately I could not wrap my head around what is going on in SemaType.cpp :/
That sounded like a scary scenario! Fortunately, expandIfMacroId even expands source locations inside the scratch buffer correctly into a location in a real file. I added two tests for it and they seem to pass. Thank you for the hint!
Because I would like the check to rewrite e.g. const auto f(); into auto f() -> const auto;. If I omit the check for nested local qualifiers, then those kind of declarations would be skipped.
I just ran the tests again using python .\check_clang_tidy.py -std=c++20 .\checkers\modernize-use-trailing-return-type.cpp modernize-use-trailing-return-type aa -- -- -DCOMMAND_LINE_INT=int and I did not see mentioning of the use of an uninitialized variable. But I run on Windows, maybe the issue just surfaces on another OS? Is there a way to trigger the CI again?
I removed the FIXME in question in the hope the issue resolved itself.
I don't think I understand why that's desirable though? What is it about the qualifier that makes it worthwhile to repeat the type like that?
I also run on Windows so I can't easily test the behavior elsewhere for you. The CI will get triggered on new patch uploads, but I still don't always trust it. The bots are usually a more reliable source of CI truth but we have no way to speculatively trigger all the bots.
Btw: what is the general rule for Phabricator reviews here when to tick the Done checkbox of a comment? What is the semantic of this checkbox? Is the ticked state the same for everyone?
Thank you for the help!
Thank you for insisting on that peculiarity! The choice is stylistically motivated to align function names:
auto f() -> int; auto g() -> std::vector<float>; auto& h(); const auto k(); decltype(auto) l();
auto f() -> int; auto g() -> std::vector<float>; auto h() -> auto&; auto k() -> const auto; auto l() -> decltype(auto);
But judging from your response, this might be a surprise to users. Would you prefer having an option to enable/disable this behavior?
Thank you @riccibruno for verifying that for me!
I don't think we have any hard-and-fast rules for it and I suspect the ticked state differs from review to review. Personally, I appreciate when the person who was asked to do some work is the one to check the Done box signalling that they think it's done (whether it's an author fixing a comment from a reviewer or a reviewer answering a question from an author, etc). This tells me "hey, someone thinks this is done, go look at it and comment if you disagree." However, I am guessing others have a different workflow.
I don't think I have any further concerns with this patch, so LGTM.
Maybe it will be, maybe it won't. :-D The reason I was surprised was because it feels like a formatting related choice rather than a modernization related choice. However, I've always struggled to understand the utility of this check (it's one I disable in every .clang-tidy configuration file I can), so my reasoning may be flawed. I feel like the goal of this check isn't to format code nicely, it's to modernize to using a trailing return type where that adds clarity. But I don't think auto& func() changing into auto func() -> auto& adds clarity (I think it removes clarity because the second signature is strictly more complex than the first), and similar for qualifiers. However, I think the exact same thing about int func() changing into auto func() -> int.
Given that we document this function to rewrite all functions to a trailing return type signature, I guess the behavior you've proposed here is consistent with that goal and so I'm fine with it.
Thank you for the time to review this!
Could you please also commit it for me? Thank you!
I am sorry to hear that, but I have heard this from many other people as well. I am sometimes questioning myself whether it was a mistake to put this check into clang-tidy and annoy a lot of people. It might have been better as a standalone tool.
I like that thinking! I started with trailing return types as a stylistic choice, but I soon realized that it indeed can add clarity by shifting away complicated return types to the end of a line where they bother me less.
With regard to clarity, you are right. And I noted down now that I shall add an option to prevent some of these rewrites. Thank you for the feedback!
I've commit on your behalf in 345053390ac17dd4a2e759de9e0e24c2605035db, thank you for the patch!
FWIW, I don't question whether it was a mistake to add it. I just figure it wasn't targeted at me, and that's fine too. I can see the utility for people who want that kind of declaration style.