Changes in p4.cpp

888673b6 - Revert "[clang] Implement ElaboratedType sugaring for types written bare"

Fri, 15 Jul 2022 04:13:57 +0000

Revert "[clang] Implement ElaboratedType sugaring for types written bare"This reverts commit 7c51f02effdbd0d5e12bfd26f9c3b2ab5687c93f because itstills breaks the LLDB tests. This was re-landed without addressing theissue or even agreement on how to address the issue. More details anddiscussion in https://reviews.llvm.org/D112374. List of files: /llvm-project-15.0.7/clang/test/CXX/class.access/p4.cpp

7c51f02e - [clang] Implement ElaboratedType sugaring for types written bare

Mon, 11 Oct 2021 16:15:36 +0000

[clang] Implement ElaboratedType sugaring for types written bareWithout this patch, clang will not wrap in an ElaboratedType node types writtenwithout a keyword and nested name qualifier, which goes against the intent thatwe should produce an AST which retains enough details to recover how things arewritten.The lack of this sugar is incompatible with the intent of the type printerdefault policy, which is to print types as written, but to fall back and printthem fully qualified when they are desugared.An ElaboratedTypeLoc without keyword / NNS uses no storage by itself, but stillrequires pointer alignment due to pre-existing bug in the TypeLoc bufferhandling.---Troubleshooting list to deal with any breakage seen with this patch:1) The most likely effect one would see by this patch is a change in how a type is printed. The type printer will, by design and default, print types as written. There are customization options there, but not that many, and they mainly apply to how to print a type that we somehow failed to track how it was written. This patch fixes a problem where we failed to distinguish between a type that was written without any elaborated-type qualifiers, such as a 'struct'/'class' tags and name spacifiers such as 'std::', and one that has been stripped of any 'metadata' that identifies such, the so called canonical types. Example: ``` namespace foo { struct A {}; A a; }; ``` If one were to print the type of `foo::a`, prior to this patch, this would result in `foo::A`. This is how the type printer would have, by default, printed the canonical type of A as well. As soon as you add any name qualifiers to A, the type printer would suddenly start accurately printing the type as written. This patch will make it print it accurately even when written without qualifiers, so we will just print `A` for the initial example, as the user did not really write that `foo::` namespace qualifier.2) This patch could expose a bug in some AST matcher. Matching types is harder to get right when there is sugar involved. For example, if you want to match a type against being a pointer to some type A, then you have to account for getting a type that is sugar for a pointer to A, or being a pointer to sugar to A, or both! Usually you would get the second part wrong, and this would work for a very simple test where you don't use any name qualifiers, but you would discover is broken when you do. The usual fix is to either use the matcher which strips sugar, which is annoying to use as for example if you match an N level pointer, you have to put N+1 such matchers in there, beginning to end and between all those levels. But in a lot of cases, if the property you want to match is present in the canonical type, it's easier and faster to just match on that... This goes with what is said in 1), if you want to match against the name of a type, and you want the name string to be something stable, perhaps matching on the name of the canonical type is the better choice.3) This patch could exposed a bug in how you get the source range of some TypeLoc. For some reason, a lot of code is using getLocalSourceRange(), which only looks at the given TypeLoc node. This patch introduces a new, and more common TypeLoc node which contains no source locations on itself. This is not an inovation here, and some other, more rare TypeLoc nodes could also have this property, but if you use getLocalSourceRange on them, it's not going to return any valid locations, because it doesn't have any. The right fix here is to always use getSourceRange() or getBeginLoc/getEndLoc which will dive into the inner TypeLoc to get the source range if it doesn't find it on the top level one. You can use getLocalSourceRange if you are really into micro-optimizations and you have some outside knowledge that the TypeLocs you are dealing with will always include some source location.4) Exposed a bug somewhere in the use of the normal clang type class API, where you have some type, you want to see if that type is some particular kind, you try a `dyn_cast` such as `dyn_cast` and that fails because now you have an ElaboratedType which has a TypeDefType inside of it, which is what you wanted to match. Again, like 2), this would usually have been tested poorly with some simple tests with no qualifications, and would have been broken had there been any other kind of type sugar, be it an ElaboratedType or a TemplateSpecializationType or a SubstTemplateParmType. The usual fix here is to use `getAs` instead of `dyn_cast`, which will look deeper into the type. Or use `getAsAdjusted` when dealing with TypeLocs. For some reason the API is inconsistent there and on TypeLocs getAs behaves like a dyn_cast.5) It could be a bug in this patch perhaps.Let me know if you need any help!Signed-off-by: Matheus Izvekov Differential Revision: https://reviews.llvm.org/D112374 List of files: /llvm-project-15.0.7/clang/test/CXX/class.access/p4.cpp

3968936b - Revert "[clang] Implement ElaboratedType sugaring for types written bare"

Wed, 13 Jul 2022 16:11:45 +0000

Revert "[clang] Implement ElaboratedType sugaring for types written bare"This reverts commit bdc6974f92304f4ed542241b9b89ba58ba6b20aa because itbreaks all the LLDB tests that import the std module. import-std-module/array.TestArrayFromStdModule.py import-std-module/deque-basic.TestDequeFromStdModule.py import-std-module/deque-dbg-info-content.TestDbgInfoContentDequeFromStdModule.py import-std-module/forward_list.TestForwardListFromStdModule.py import-std-module/forward_list-dbg-info-content.TestDbgInfoContentForwardListFromStdModule.py import-std-module/list.TestListFromStdModule.py import-std-module/list-dbg-info-content.TestDbgInfoContentListFromStdModule.py import-std-module/queue.TestQueueFromStdModule.py import-std-module/stack.TestStackFromStdModule.py import-std-module/vector.TestVectorFromStdModule.py import-std-module/vector-bool.TestVectorBoolFromStdModule.py import-std-module/vector-dbg-info-content.TestDbgInfoContentVectorFromStdModule.py import-std-module/vector-of-vectors.TestVectorOfVectorsFromStdModule.pyhttps://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/45301/ List of files: /llvm-project-15.0.7/clang/test/CXX/class.access/p4.cpp

bdc6974f - [clang] Implement ElaboratedType sugaring for types written bare

Mon, 11 Oct 2021 16:15:36 +0000

1db60c13 - Remove redundant check for access in the conversion from the naming

Mon, 30 Nov 2020 03:17:49 +0000

Remove redundant check for access in the conversion from the namingclass to the declaring class in a class member access.This check does not appear to be backed by any rule in the standard (therule in question was likely removed over the years), and only everproduces duplicate diagnostics. (It's also not meaningful because thereisn't a unique declaring class after the resolution of core issue 39.) List of files: /llvm-project-15.0.7/clang/test/CXX/class.access/p4.cpp

58ea1059 - [AST][RecoveryExpr] Build recovery expressions by default for C++.

Thu, 23 Apr 2020 09:14:01 +0000

[AST][RecoveryExpr] Build recovery expressions by default for C++.Reland https://reviews.llvm.org/D76696All known crashes have been fixed, another attemption.We have rolled out this to all internal users for a while, didn't seebig issues, we consider it is stable enough.Reviewed By: sammccallSubscribers: rsmith, hubert.reinterpretcast, ebevhan, jkorous, arphaman, kadircet, usaxena95, cfe-commitsTags: #clangDifferential Revision: https://reviews.llvm.org/D78350 List of files: /llvm-project-15.0.7/clang/test/CXX/class.access/p4.cpp

96573859 - [AST] Dont invalide VarDecl even the default initializaiton is failed.

Fri, 03 Apr 2020 09:00:16 +0000

[AST] Dont invalide VarDecl even the default initializaiton is failed.Summary:This patch would cause clang emit more diagnostics, but it is much better than https://reviews.llvm.org/D76831```cppstruct A { A(int); ~A() = delete;};void k() { A a;}```before the patch:/tmp/t3.cpp:24:5: error: no matching constructor for initialization of 'A' A a; ^/tmp/t3.cpp:20:3: note: candidate constructor not viable: requires 1 argument, but 0 were provided A(int); ^/tmp/t3.cpp:19:8: note: candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 0 were providedstruct A {After the patch:/tmp/t3.cpp:24:5: error: no matching constructor for initialization of 'A' A a; ^/tmp/t3.cpp:20:3: note: candidate constructor not viable: requires 1 argument, but 0 were provided A(int); ^/tmp/t3.cpp:19:8: note: candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 0 were providedstruct A { ^/tmp/t3.cpp:24:5: error: attempt to use a deleted function A a; ^/tmp/t3.cpp:21:3: note: '~A' has been explicitly marked deleted here ~A() = delete;Reviewers: sammccallReviewed By: sammccallSubscribers: cfe-commitsTags: #clangDifferential Revision: https://reviews.llvm.org/D77395 List of files: /llvm-project-15.0.7/clang/test/CXX/class.access/p4.cpp

55efb68c - [MS] Mark vbase dtors used when marking dtor used

Tue, 11 Feb 2020 00:16:17 +0000

[MS] Mark vbase dtors used when marking dtor usedIn the MS C++ ABI, the complete destructor variant for a class withvirtual bases is emitted whereever it is needed, instead of directlyalongside the base destructor variant. The complete destructor calls thebase destructor of the current class and the base destructors of eachvirtual base. In order for this to work reliably, translation units thatuse the destructor of a class also need to mark destructors of virtualbases of that class used.Fixes PR38521Reviewed By: rsmithDifferential Revision: https://reviews.llvm.org/D77081 List of files: /llvm-project-15.0.7/clang/test/CXX/class.access/p4.cpp

afcfb6bc - Fix implementation of [temp.local]p4.

Fri, 15 Feb 2019 21:53:07 +0000

Fix implementation of [temp.local]p4.When a template-name is looked up, we need to give injected-class-namedeclarations of class templates special treatment, as they denote atemplate rather than a type.Previously we achieved this by applying a filter to the lookup resultsafter completing name lookup, but that is incorrect in various ways, notleast of which is that it lost all information about access and howmembers were named, and the filtering caused us to generally loseall ambiguity errors between templates and non-templates.We now preserve the lookup results exactly, and the few places that needto map from a declaration found by name lookup into a declaration of atemplate do so explicitly. Deduplication of repeated lookup results ofthe same injected-class-name declaration is done by name lookup insteadof after the fact.This reinstates r354091, which was previously reverted in r354097because it exposed bugs in lldb and compiler-rt. Those bugs were fixedin r354173 and r354174 respectively.llvm-svn: 354176 List of files: /llvm-project-15.0.7/clang/test/CXX/class.access/p4.cpp

0650f897 - Revert "Fix implementation of [temp.local]p4."

Fri, 15 Feb 2019 03:06:15 +0000

Revert "Fix implementation of [temp.local]p4."This reverts commit 40bd10b770813bd1471d46f514545437516aa4ba.This seems to now emit an error when building the sanitizer tests:http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/53965/consoleFull.llvm-svn: 354097 List of files: /llvm-project-15.0.7/clang/test/CXX/class.access/p4.cpp

40bd10b7 - Fix implementation of [temp.local]p4.

Fri, 15 Feb 2019 00:29:04 +0000

Fix implementation of [temp.local]p4.When a template-name is looked up, we need to give injected-class-namedeclarations of class templates special treatment, as they denote atemplate rather than a type.Previously we achieved this by applying a filter to the lookup resultsafter completing name lookup, but that is incorrect in various ways, notleast of which is that it lost all information about access and howmembers were named, and the filtering caused us to generally loseall ambiguity errors between templates and non-templates.We now preserve the lookup results exactly, and the few places that needto map from a declaration found by name lookup into a declaration of atemplate do so explicitly. Deduplication of repeated lookup results ofthe same injected-class-name declaration is done by name lookup insteadof after the fact.llvm-svn: 354091 List of files: /llvm-project-15.0.7/clang/test/CXX/class.access/p4.cpp

883dbc43 - Switch from using a DiagnosticTrap and a note for "while defining a special

Thu, 25 May 2017 22:47:05 +0000

Switch from using a DiagnosticTrap and a note for "while defining a specialmember function" context notes to registering an entry on the context stack.Also reorder the steps within defining special members to be consistent.This has a few benefits: if multiple diagnostics are produced while checkingsuch a member, the note is now attached to the first such diagnostic ratherthan the last, this prepares us for persisting these diagnostics between thepoint at which we require the implicit instantiation of a template and thepoint at which that instantiation is actually performed, and this fixes somecases where we would fail to produce a full note stack leading back to usercode in the case of such a diagnostic.The reordering exposed a case where we could recursively attempt to define adefaulted destructor while we're already defining one (and other such casesalso appear to be possible, with or without this change), so this change alsoreuses the "willHaveBody" flag on function declarations to track that we're inthe middle of synthesizing a body for the function and bails out if we try todefine a function that we're already defining.llvm-svn: 303930 List of files: /llvm-project-15.0.7/clang/test/CXX/class.access/p4.cpp

53851923 - Fix all tests under test/CXX (and test/Analysis) to pass if clang's default

Wed, 31 Aug 2016 23:24:08 +0000

Fix all tests under test/CXX (and test/Analysis) to pass if clang's defaultC++ language standard is not C++98.llvm-svn: 280309 List of files: /llvm-project-15.0.7/clang/test/CXX/class.access/p4.cpp

e81daee2 - When formatting a C++-only declaration name, enable C++ mode in the formatter's

Wed, 22 Jan 2014 00:27:42 +0000

When formatting a C++-only declaration name, enable C++ mode in the formatter'slanguage options. This is not really ideal -- we should require the rightlanguage options to be passed in, or not require language options to format aname -- but it fixes a number of *obviously* wrong formattings. Patch byOlivier Goffart!llvm-svn: 199778 List of files: /llvm-project-15.0.7/clang/test/CXX/class.access/p4.cpp

f24e6e74 - Fix some confusing diagnostic wording. s/implicit default/implicit/ if we're

Thu, 13 Jun 2013 03:34:55 +0000

Fix some confusing diagnostic wording. s/implicit default/implicit/ if we'renot actually talking about a default constructor.llvm-svn: 183885 List of files: /llvm-project-15.0.7/clang/test/CXX/class.access/p4.cpp

5dadb65e - Fix several problems with protected access control:

Sat, 07 Apr 2012 03:04:20 +0000

Fix several problems with protected access control: - The [class.protected] restriction is non-trivial for any instance member, even if the access lacks an object (for example, if it's a pointer-to-member constant). In this case, it is equivalent to requiring the naming class to equal the context class. - The [class.protected] restriction applies to accesses to constructors and destructors. A protected constructor or destructor can only be used to create or destroy a base subobject, as a direct result. - Several places were dropping or misapplying object information.The standard could really be much clearer about what the object type issupposed to be in some of these accesses. Usually it's easy enough tofind a reasonable answer, but still, the standard makes a very confidentstatement about accesses to instance members only being possible ineither pointer-to-member literals or member access expressions, whichjust completely ignores concepts like constructor and destructorcalls, using declarations, unevaluated field references, etc.llvm-svn: 154248 List of files: /llvm-project-15.0.7/clang/test/CXX/class.access/p4.cpp

31feb337 - Diagnose tag and class template declarations with qualified

Sat, 17 Mar 2012 23:06:31 +0000

Diagnose tag and class template declarations with qualifieddeclarator-ids that occur at class scope. Fixes PR8019.llvm-svn: 153002 List of files: /llvm-project-15.0.7/clang/test/CXX/class.access/p4.cpp

119c10ef - Update our diagnostics to properly account for move operations.

Wed, 25 May 2011 23:16:36 +0000

Update our diagnostics to properly account for move operations.llvm-svn: 132096 List of files: /llvm-project-15.0.7/clang/test/CXX/class.access/p4.cpp

6c307aee - Undo enough of r131143 to make private copy ctor diags say "copy constructor" again

Thu, 19 May 2011 23:44:42 +0000

Undo enough of r131143 to make private copy ctor diags say "copy constructor" againllvm-svn: 131706 List of files: /llvm-project-15.0.7/clang/test/CXX/class.access/p4.cpp

80f00ff9 - Re-do R131114 without breaking code.

Tue, 10 May 2011 19:08:14 +0000

Re-do R131114 without breaking code.I've edited one diagnostic which would print "copy constructor" for copyconstructors and "constructor" for any other constructor. If anyone isextremely enamored with this, it can be reinstated with a simple booleanflag rather than calling getSpecialMember, which is inappropriate.llvm-svn: 131143 List of files: /llvm-project-15.0.7/clang/test/CXX/class.access/p4.cpp