LGTM

LGTM

In D127033#3563576, @jwakely wrote:

Also, Billy O'Neal reported that the new overload caused ambiguities for some morally questionable code in Google Test, which was trying to define it's own overload for this type. Breaking existing code (even if it's bad code) is another reason to not enable it unconditionally. I guess that's no longer an issue, or somebody would have noticed it when using gtest and libc++!

It seems like the only known uses for this operator<< are in Boost.Test, Google Test, and Mozilla's assertion macros ... so I super don't care about it.

In D119136#3462660, @aaron.ballman wrote:>

Thanks for the apology, but I still think the reverts were premature, so hopefully we don't do this again. The issue with reverting all of these is that you put the burden back onto a relatively new contributor to try to figure out how to reapply all these changes when there wasn't actually a need to do so.

In terms of where we go from here, there's a few options:

1. revert the reverts; this is easiest, but causes the most churn
2. merge all three patches into one (squashed) patch and commit that; this requires a little bit more work, but causes less churn
3. assume that P2036R3 is not implementable until WG21 resolves CWG2569 because it breaks too much code

I think I have a preference for #2 as that will hopefully leave us with the most clear git history for when we do a blame later, but I could live with #1. If we find that there is significant broken code still, but it's not in system headers, then I think we should explore #3, but I don't think we have evidence that we're in this situation either.

• Add a trigraph test case

• Revert some auto's

Restore the right diff

Nit

Use the right copy of clang-format

Re-run build

Rebase

Rebase

In D113393#3345275, @aaron.ballman wrote:

Also implemented decltype(auto)(x) (https://wg21.link/p0849r2) as a Clang extension.

I'd like to better understand the use cases for this. WG21 considered this as part of the feature and ultimately rejected it (fairly strongly, according to the EWG polls). From the meeting minutes, [...]

In D113393#3340878, @aaron.ballman wrote:

Are there changes needed for the AST printer for this new form of cast notation?

• Remove decltype(auto) from the patch
• Parenthesize deduced casts in AST print

• Do not overwrite braced inits when forming AST
• Explain why losing decltype(auto) as written in AST

In D113393#3340878, @aaron.ballman wrote:

I spotted some test coverage that I think we should add:

static_cast<auto>(whatever);
reinterpret_cast<auto>(whatever);
const_cast<auto>(whatever);
dynamic_cast<auto>(whatever);
(auto)whatever;

• Add more tests to diagnose other forms of casts

Rerun pre-merge checks

• Rephrase a warning message

Rebased

• Retarget Clang 15

LGTM

@rsmith, your suggestion in 2017 solves this issue:

Rebased

Looks nice, and works for me (as in https://github.com/llvm/llvm-project/issues/53430).

Ping.

Restricted the ellipsis only to diagnosis. Type comparison now shows full initializers, which could be made smarter next time.

• Flip the default and set EntireContentsOfLargeArray off only in diagnosis

• clang-format

• Put tests in TypePrinterTest.cpp

• Fix categorizing int64_t chars of negative values
• More ArrayRef
• Fix and test the EntireContentsOfLargeArray bit

Looks reasonable to me.

@rsmith Ping. I'm all on you :) You are almost the only one designed these files.

In D113393#3190788, @Quuxplusone wrote:

Am I seeing correctly that there's no feature-test macro for auto(x)?

Ping. Ready to review again.

• Switch to llvm::SmallString
• Refactor code that prints C-style builtin escape sequences
• Stop printing strings with embedded NULs in NTTP types
• Add an EntireContentsOfLargeArray pretty-print policy

Ensure the ellipses output is never shorter than the normal ones (will look at review comments later)

Add EOL to source file

• Add tests

Fix failed assertion

I reverted the attempt to fix auto(&a)->n = 0; in this revision. The fix is definitely not 3 lines and does not fit in this patch.
Long story short, our tentative parsing code does not look at trailing return types and fails to disambiguate template <class T> void e(auto (*p)(T y) -> decltype(y())) {} if it is still ambiguous after seen auto (. The following files have more interesting cases:

CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p2.cpp
CXX/dcl/dcl.fct/p17.cpp
CodeGenCXX/mangle-exprs.cpp
Parser/cxx0x-ambig.cpp
Parser/cxx1z-decomposition.cpp
SemaCXX/trailing-return-0x.cpp
SemaTemplate/alias-templates.cpp

and not all of them are correct. It needs a closer look in a future issue.

• revert the tentative parsing fix
• warn in -Wpre-c++2b-compat and -Wdecltype-auto-cast (ExtWarn)

Ping. Please review.

• Adapt tests instead

In D113393#3128840, @rsmith wrote:

I also wonder whether we should accept decltype(auto)(x) as an extension, but we can discuss that separately.

In D113393#3128835, @rsmith wrote:

It looks like we'll need some additional work on disambiguation to handle cases like:

struct A { int n; } a;
void f() { auto(&a)->n = 0; }

I think that's valid, but right now we misparse it as a declaration of a variable &a. [...]:

struct A { int n; } a;
using T = A*;
void f() { T(&a)->n = 1; }

• Implement decltype(auto)(x) as well

Thanks for the patch! It works for me, both for the auto{x} and new auto{x} cases. Some corner cases left:

• Manually adjust auto{x} formatting

Address review comments

Clang-format