This is a reapplication of r203236 with modifications to the definition of attrs() and following the new style guidelines on auto usage.
llvm-svn: 203362
This changes the iterators so that they are no longer implemented in terms of ranges (so it's a very partial revert of the existing rangification efforts).
llvm-svn: 203299
This patch fixes PR18964. In linkage computation, assertion fails when
an old invalid declaration's linkage mismatches with the current
decl's one.
llvm-svn: 203168
If a guard variable will be created for an entity at global scope,
then we cannot rely on the scope depth to disambiguate names for us.
Instead, mangle the entire variable into the guard to ensure it's uniqueness.
llvm-svn: 203151
Initializers and finalizers for static data members have the variable's
access-specifier, storage-class, type and CV-qualifiers mangled in.
llvm-svn: 203145
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
According to the GNU docs, zero-sized bitfields should not be affected by the
packed attribute.
Differential Revision: http://llvm-reviews.chandlerc.com/D2693
llvm-svn: 201288
useBitFieldTypeAlignment() and appears to ignore the special
bit-packing semantics of __attribute__((packed)).
Further flesh out an already-extensive comment.
llvm-svn: 201282
These features are new in VS 2013 and are necessary in order to layout
std::ostream correctly. Currently we have an ABI incompatibility when
self-hosting with the 2013 stdlib in our convertible_fwd_ostream wrapper
in gtest.
This change adds another implicit attribute, MSVtorDispAttr, because
implicit attributes are currently the best way to make sure the
information stays on class templates through instantiation.
Reviewers: majnemer
Differential Revision: http://llvm-reviews.chandlerc.com/D2746
llvm-svn: 201274
vptr injection must inject padding equivalent to the alignment of the
most aligned non-virtual subobject, not the alignment of the enclosing
record.
To fascilitate this change, don't let record layout observe the
alignment of the record until we've injected our vptrs. Also, do not
allow the alignment of vbases to affect required alignment until just
before we insert the vtordisp field.
llvm-svn: 201199
It is actually useful to warn in such cases, thanks to Dmitri for pushing on this and making us see the light!
Related to rdar://15925483 and rdar://15922612. The latter radar is where the usefulness of the warning is most clear.
llvm-svn: 201165
Introduce a notion of a 'current representation method' for
pointers-to-members.
When starting out, this is set to 'best case' (representation method is
chosen by examining the class, selecting the smallest representation
that would work given the class definition or lack thereof).
This pragma allows the translation unit to dictate exactly what
representation to use, similar to how the inheritance model keywords
operate.
N.B. PCH support is forthcoming.
Differential Revision: http://llvm-reviews.chandlerc.com/D2723
llvm-svn: 201105
Properly support fields that come from anonymous unions and structs
when used as template arguments for pointer to data member params.
llvm-svn: 200921
Properly determine the inheritance model when dealing with nullptr:
- If a nullptr template argument is being checked against
pointer-to-member parameter, nail down an inheritance model.
N.B. We will chose an inheritance model even if we won't ultimately
choose the template to instantiate! Cooky, right?
- Null pointer-to-datamembers have a virtual base table offset of -1,
not zero. Previously, we chose an offset of 0.
llvm-svn: 200920
Function references always use $1? like function pointers and never $E?
like var decl references. Static methods are mangled like function
pointers.
llvm-svn: 200869
Member pointers are mangled as they would be represented at runtime.
They can be a single integer literal, single decl, or a tuple with some
more numbers tossed in. With Clang today, most of those numbers will be
zero because we reject pointers to members of virtual bases.
This change required moving VTableContextBase ownership from
CodeGenVTables to ASTContext, because mangling now depends on vtable
layout.
I also hoisted the inheritance model helpers up to be inline static
methods of MSInheritanceAttr. This makes the AST code that deals with
member pointers much more readable.
MSVC doesn't appear to have stable manglings of null member pointers:
- Null data memptrs in function templates have a mangling collision with
the first field of a non-polymorphic single inheritance class.
- The mangling of null data memptrs changes if you add casts.
- Large null function memptrs in class templates crash MSVC.
Clang uses the class template mangling for null data memptrs and the
function template mangling for null function memptrs to deal with this.
Reviewers: majnemer
Differential Revision: http://llvm-reviews.chandlerc.com/D2695
llvm-svn: 200857
Ranges before:
void test(void (*)(int), int, float);
~~~~~~~~~~~~~ ~~~~ ~~~~~~
Ranges after:
void test(void (*)(int), int, float);
~~~~~~~~~~~~~ ~~~ ~~~~~
This does not change the actual location of the ParmVarDecl, it still
points to the location where the name would be. PR17970.
llvm-svn: 200640
With this change, we give different results for __alignof than MSVC, but
our record layout is compatible.
Some data member pointers also now have a size that is not a multiple of
their alignment.
Fixes PR18618.
Reviewers: majnemer
Differential Revision: http://llvm-reviews.chandlerc.com/D2669
llvm-svn: 200585
We would previously allow inappropriate inheritance keywords to appear
on class declarations. We would also allow inheritance keywords on
templates which were not fully specialized; this was divergent from
MSVC.
Differential Revision: http://llvm-reviews.chandlerc.com/D2585
llvm-svn: 200423
(comment without a decl).
I think this can not happen during normal compilation with -Wdocumentation,
only while using Clang APIs to parse comments outside of a source file.
Based on a patch by Olivier Goffart.
llvm-svn: 200230
initialized from a constant expression in C++98, it can be used in
constant expressions, even if it was brace-initialized. Patch by
Rahul Jain!
llvm-svn: 200098
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
llvm-svn: 200082
not using backing ivar warning, ignore when
property is not being synthesized (user declared its
implementation @dynamic). // rdar://1583425
llvm-svn: 199820
Lift the getFunctionDecl() utility out of the parser into a general
Decl::getAsFunction() and use it to simplify other parts of the implementation.
Reduce isFunctionOrFunctionTemplate() to a simple type check that works the
same was as the other is* functions and move unwrapping of shadowed decls to
callers so it doesn't get run twice.
Shuffle around canSkipFunctionBody() to reduce virtual dispatch on ASTConsumer.
There's no need to query when we already know the body can't be skipped.
llvm-svn: 199794
language options. This is not really ideal -- we should require the right
language options to be passed in, or not require language options to format a
name -- but it fixes a number of *obviously* wrong formattings. Patch by
Olivier Goffart!
llvm-svn: 199778
The MSVC C++ ABI always uses the deduced type in place of auto when
generating external names for variables.
N.B. MSVC doesn't support C++1y's 'operator auto' and this patch will
not give us said functionality.
llvm-svn: 199764
Fix a perennial source of confusion in the clang type system: Declarations and
function prototypes have parameters to which arguments are supplied, so calling
these 'arguments' was a stretch even in C mode, let alone C++ where default
arguments, templates and overloading make the distinction important to get
right.
Readability win across the board, especially in the casting, ADL and
overloading implementations which make a lot more sense at a glance now.
Will keep an eye on the builders and update dependent projects shortly.
No functional change.
llvm-svn: 199686
This reverts commit r199475 (which reverted r199416) with fixes for the
breakages.
We wouldn't lock an inheritance model if we saw a pointer-to-member
formed as a result of the address-of operator.
llvm-svn: 199482
pointer, since this invokes undefined behavior. Based on a patch by Artyom
Skrobov! Handling of dependent exception specifications and some additional
testcases by me.
llvm-svn: 199452
The MSVC ABI is rather finicky about the exact representation of it's
pointer-to-member representation. The exact position of when and where
it will go with one representation versus another appears to be when it
desires the pointer-to-member to be complete.
To properly implement this in clang, do several things:
- Give up on tracking the polymorphic nature of the class. It isn't
useful to Sema and is only pertinent when choosing CodeGen-time
details like whether the field-offset can be 0 instead of -1.
- Insist on locking-in the inheritance model when we ask our
pointer-to-member type to be complete. From there, grab the
underlying CXXRecordDecl and try to make *that* complete. Once we've
done this, we can calculate it's inheritance model and apply it using
an attribute.
N.B. My first bullet point is a lie. We will eventually care about the
specifics of whether or not a CXXRecordDecl is or is not polymorphic
because MSVC compatible mangling of such things depends on it. However,
I believe we will handle this in a rather different way.
llvm-svn: 199416
Additionally, remove the optional nature of the spelling list index when creating attributes. This is supported by table generating a Spelling enumeration when the spellings for an attribute are distinct enough to warrant it.
llvm-svn: 199378
There's been long-standing confusion over the role of these two options. This
commit makes the necessary changes to differentiate them clearly, following up
from r198936.
MicrosoftExt (aka. fms-extensions):
Enable largely unobjectionable Microsoft language extensions to ease
portability. This mode, also supported by gcc, is used for building software
like FreeBSD and Linux kernel extensions that share code with Windows drivers.
MSVCCompat (aka. -fms-compatibility, formerly MicrosoftMode):
Turn on a special mode supporting 'heinous' extensions for drop-in
compatibility with the Microsoft Visual C++ product. Standards-compilant C and
C++ code isn't guaranteed to work in this mode. Implies MicrosoftExt.
Note that full -fms-compatibility mode is currently enabled by default on the
Windows target, which may need tuning to serve as a reasonable default.
See cfe-commits for the full discourse, thread 'r198497 - Move MS predefined
type_info out of InitializePredefinedMacros'
No change in behaviour.
llvm-svn: 199209
This patch makes a small behavioral change to the interaction between
pack and alignment. Specifically it makes __declspec(align()) on a
field change that field's alignment without respect to pack but the
alignment change to the record alignment as a whole still obeys pack.
llvm-svn: 199172
Although VBPtrs were being placed correctly by the ms-abi layout engine,
their offsets were being improperly reported to the ASTRecordLayout
builder due to a bug. This patch fixes that and fixes the test cases to
use the correct values.
y
llvm-svn: 199168
This patch moves the check for pragma pack until after the application
of __declspec align to before pragma pack. This causes observable
changes in the use of tail padding for bases. A test case is included.
llvm-svn: 199154
The MS-ABI tracks a bit that asserts that the first sub-object is zero
sized. This bit is used to add padding between objects if there's the
potential for zero sized objects to alias. The bit is still true even
if the zero sized base is lead by a VFPtr. This patch makes clang mimic
that behavior.
llvm-svn: 199132
This patch more cleanly seperates the concepts of Preferred Alignment
and Required Alignment. Most notable that changes to Required Alignment
do *not* impact preferred alignment until late in struct layout. This
is observable when using pragma pack and non-virtual bases and the use
of tail padding when laying them out.
Test cases included.
llvm-svn: 198988
The presence of a VBPtr suppresses the presence of zero sized
sub-objects in the non-virtual portion of the object in the context of
determining if two base objects need alias-avoidance padding placed
between them.
Test cases included.
llvm-svn: 198975
__declspec(align), when applied to bitfields affects their perferred
alignment instead of their required alignment. We don't know why.
Also, #pragma pack(n) turns packing *off* if n is greater than the
pointer size. This is now observable because of the impact of
declspec(align) on bitfields.
llvm-svn: 198907
just valid C++11 =)
Original commit message:
PR18427: Use an appropriately-aligned buffer in APValue, to avoid a crash on
SPARC, where uint64_t apparently requires higher alignment than void*.
llvm-svn: 198903
The MS abi lays out *all* non-virtual bases with leading vfptrs before
laying out non-virutal bases without vfptrs. This guarantees that the
primary base is laid out first. r198818 fixed RecordLayoutBuilder to
produce compatiable layouts. This patch fixes CGRecordLayoutBuilder to
be able to consume those layouts and produce meaningful output without
tripping any asserts about assumed incoming layout.
A test case is included that shows CGRecordLayoutBuilder in fact
produces output in the compatiable order.
llvm-svn: 198900
This patch refactors microsoft record layout to be more "natural". The
most dominant change is that vbptrs and vfptrs are injected after the
fact. This simplifies the implementation and the math for the offest
for the first base/field after the vbptr.
llvm-svn: 198818
encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.
llvm-svn: 198686
enum-scoped.cpp:93:6: error: enumeration redeclared with different underlying type 'short' (was 'int')
enum Redeclare6 : short;
^
enum-scoped.cpp:92:6: note: previous declaration is here
enum Redeclare6 : int;
^ ~~~
The redeclaration source range is still missing but this is a step forward,
potentially edging towards a FixIt.
llvm-svn: 198601
This has the dual effect of (1) enabling more dead-stripping in release builds
and (2) ensuring that debug helper functions aren't stripped away in debug
builds, as they're intended to be called from the debugger.
Note that the attribute is applied to definitions rather than declarations in
headers going forward because it's now conditional on NDEBUG:
/// \brief Mark debug helper function definitions like dump() that should not be
/// stripped from debug builds.
Requires corresponding macro added in LLVM r198456.
llvm-svn: 198489
Aaron Ballman