Use a scheme inspired by the Itanium ABI to properly implement the
mangling of lambdas.
N.B. The incredibly astute observer will notice that we do not generate
external names that are identical, or even compatible with, MSVC.
This is fine because they don't generate names that they can use across
translation units. Technically, we can generate any name we'd like so
long as that name wouldn't conflict with any other and would be stable
across translation units.
This fixes PR15512.
llvm-svn: 202962
Summary:
The MSVC ABI appears to mangle the lexical scope into the names of
statics. Specifically, a counter is incremented whenever a scope is
entered where things can be declared in such a way that an ambiguity can
arise. For example, a class scope inside of a class scope doesn't do
anything interesting because the nested class cannot collide with
another nested class.
There are problems with this scheme:
- It is unreliable. The counter is only incremented when a previously
never encountered scope is entered. There are cases where this will
cause ambiguity amongst declarations that have the same name where one
was introduced in a deep scope while the other was introduced right
after in the previous lexical scope.
- It is wasteful. Statements like: {{{{{{{ static int foo = a; }}}}}}}
will make the mangling of "foo" larger than it need be because the
scope counter has been incremented many times.
Because of these problems, and practical implementation concerns. We
choose not to implement this scheme if the local static or local type
isn't visible. The mangling of these declarations will look very
similar but the numbering will make far more sense, this scheme is
lifted from the Itanium ABI implementation.
Reviewers: rsmith, doug.gregor, rnk, eli.friedman, cdavis5x
Reviewed By: rnk
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2953
llvm-svn: 202951
anonymous structs to the same Decl in the
ASTImporter, ensure that both are filled in
from their external sources (if present).
Otherwise two different structs may be
identified erroneously.
llvm-svn: 202869
We wouldn't recognize variable templates as being templates leading us
to leave the template arguments off of the mangled name. This would
allow two unrelated templates to map to the same mangled name.
N.B. While MSVC doesn't support variable templates as of this date,
this mangling is the most likely thing they will choose to use. Their
demangler can successfully demangle our manglings with the template
arguments shown.
llvm-svn: 202789
or virtual functions, but permit that error to be downgraded to
a warning (with -Wno-error=incompatible-ms-struct), and officially
support this kind of dual, ABI-mixing layout.
The basic problem here is that projects which use ms_struct are often
not very circumspect about what types they annotate; for example,
some projects enable the pragma in a prefix header and then only
selectively disable it around system header inclusions. They may
only care about binary compatibility with MSVC for a subset of
those structs, but that doesn't mean they have no binary
compatibility concerns at all for the rest; thus we are essentially
forced into supporting this hybrid ABI. But it's reasonable for
us to at least point out the places where we're not making
any guarantees.
The original diagnostic was for dynamic classes, i.e. those with
virtual functions or virtual bases; I've extended it to include
all classes with bases, because we are not actually making any
attempt to duplicate MSVC's base subobject layout in ms_struct
(and it is indeed quite different from Itanium, even for
non-virtual bases).
rdar://16178895
llvm-svn: 202427
Summary:
This merges VFPtrInfo and VBTableInfo into VPtrInfo, since they hold
almost the same information. With that change, the vbtable mangling
code can easily be applied to vftable data and we magically get the
correct, unambiguous vftable names.
Fixes PR17748.
Reviewers: timurrrr, majnemer
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2893
llvm-svn: 202425
With r197755 we started reading the contents of buffer file entries, but the
buffers may point to ASTReader blobs that have been disposed.
Fix this by having the CompilerInstance object keep a reference to the ASTReader
as well as having the ASTContext keep reference to the ExternalASTSource.
This was very difficult to construct a test case for.
rdar://16149782
llvm-svn: 202346
Erroring out until we fix the bug means we don't have to keep chasing down
this same miscompile in a bunch of different places.
Differential Revision: http://llvm-reviews.chandlerc.com/D2890
llvm-svn: 202331
This was changed to use manual desugaring and multiplication in r201832
and fixed for multi-dimensional arrays in r201917. However, it breaks
down in the presence of typedefs. Rather than attempting to handle all
the desugaring, just go back to calling the generic type info code.
This was discovered while compiling SIInstrWaits.cpp in the R600
backend.
llvm-svn: 202175
- Don't emit anything when we encounter a call to a conversion operator.
"bar(a & b)" instead of "bar(a & b.operator int())"
This preserves the semantics and is still idempotent if we print the AST multiple times.
- Properly print declarations of conversion operators.
"explicit operator bool();" instead of "bool operator _Bool();"
PR18776.
llvm-svn: 202167
When calculating the preferred alignment of a type, consider if a alignment
attribute came from a typedef declaration. If one did, do not naturally align
the type.
Patch by Stephan Tolksdorf, with a little tweaking and an additional testcase by me.
llvm-svn: 202088
Most 64-bit targets define int64_t as long int, and AArch64 should
make same definition to follow LP64 model. In GNU tool chain, int64_t
is defined as long int for 64-bit target. So to get consistent with GNU,
it's better Changing int64_t from 'long long int' to 'long int',
otherwise clang will get different name mangling suffix compared with g++.
llvm-svn: 202004
A recent change caused multi-dimensional arrays not to be handled
correctly, this patch fixes that. Also, it adds a lit test for
multi-dimensional arrays.
llvm-svn: 201917
This does;
- clang_tablegen() adds each tblgen'd target to global property CLANG_TABLEGEN_TARGETS as list.
- List of targets is added to LLVM_COMMON_DEPENDS.
- all clang libraries and targets depend on generated headers.
You might wonder this would be regression, but in fact, this is little loss.
- Almost all of clang libraries depend on tblgen'd files and clang-tblgen.
- clang-tblgen may cause short stall-out but doesn't cause unconditional rebuild.
- Each library's dependencies to tblgen'd files might vary along headers' structure.
It made hard to track and update *really optimal* dependencies.
Each dependency to intrinsics_gen and ClangSACheckers is left as DEPENDS.
llvm-svn: 201842
Slight change to the way zero-sized sub-objects are tracked in the
presence of virtual bases.
In addition we correctly distinguish between dsize and nvsize.
addresses http://llvm.org/bugs/show_bug.cgi?id=18826
Unit tests are included.
llvm-svn: 201832
This reverts commit r201810.
It was failing these tests on my workstation:
Clang :: CodeGen/override-layout.c
Clang :: CodeGenCXX/override-layout.cpp
Clang :: PCH/check-deserializations.cpp
llvm-svn: 201823
External sources shouldn't prevent the layout engine from using
MSLayout. If lldb were to support debugging in microsoft mode, some
code will need to be added to MSRecordLayoutBuilder to handel external
layouts.
llvm-svn: 201810
In the Microsoft ABI, the vftable is laid out as if all methods in every
overload set were declared in reverse order of declaration at the point
of declaration of the first overload in the set.
Previously we only considered virtual methods in an overload set, but
MSVC includes non-virtual methods for ordering purposes.
Fixes PR18902.
llvm-svn: 201722
Extended qualifiers can appear in many places, refactor the code so it's
more reusable. Add tests in areas where we've increased compatibility.
llvm-svn: 201574
Pointer types in the MSVC ABI are a bit awkward, the width of the
pointer is considered a kind of CVR qualifier.
Restrict is handled similarly to const and volatile but is mangled after
the pointer width qualifier.
This fixes PR18880.
llvm-svn: 201569
Richard Trieu