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
Per more discussion, 'objc_protocol_requires_explicit_implementation' is
refinement that it mainly adds that requirement that a protocol must be
explicitly satisfied at the moment the first class in the class hierarchy
conforms to it. Any subclasses that also conform to that protocol,
either directly or via conforming to a protocol that inherits that protocol,
do not need to re-implement that protocol.
Doing this requires first doing a pass on the super class hierarchy,
gathering the set of protocols conformed to by the super classes,
and then culling those out when determining conformance. This
two-pass algorithm could be generalized for all protocol checking,
and could possibly be a performance win in some cases. For now
we restrict this change to protocols with this attribute to isolate
the change in logic (especially as the design continues to evolve).
This change needs to be adjusted for properties as well; this
only impacts methods right now.
llvm-svn: 202948
Some unreachable code is only "sometimes unreachable" because it
is guarded by a configuration value that is determined at compile
time and is always constant. Sometimes those represent real bugs,
but often they do not. This patch causes the reachability analysis
to cover such branches even if they are technically unreachable
in the CFG itself. There are some conservative heuristics at
play here to determine a "configuration value"; these are intended
to be refined over time.
llvm-svn: 202912
Summary:
Our usual definition of max_align_t wouldn't match up with MSVC if it
was used in a template argument.
Reviewers: chandlerc, rsmith, rnk
Reviewed By: chandlerc
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2924
llvm-svn: 202911
Use llvm::sys::fs::make_absolute to get an absolute path before
matching. Also, allow "." directories to enable testing. ".." is still
not supported, and will require crossing file system boundaries to
implement correctly.
llvm-svn: 202903
This fails an "isa<> used with null pointer" assert during a clang-cl
self-host on Windows. This was caused by r202769, and I'm currently
reducing a test case.
Reviewers: dblaikie
Differential Revision: http://llvm-reviews.chandlerc.com/D2944
llvm-svn: 202888
line arguments and directories tree. The old toolchain selection heuristics
worked incorrectly when user has a reduced MIPS toolchain supports
the O32 ABI only.
Patch reviewed by Jonathan Roelofs, David Majnemer.
llvm-svn: 202873
if an ivar offset load is invariant iff inside an instance method
and ivar belongs to instance method's class and one of its super class.
// rdar://16095748
llvm-svn: 202872
and one for PCLMUL support. The current immintrin.h header only includes
wmmintrin.h if AES support is enabled. It should include it if either AES or
PCLMUL is enabled (GCC's version of immintrin.h does this).
Patch by John Baldwin!
llvm-svn: 202871
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
a missing include from CLog.h.
CLog.h referenced most of the core libclang types but never directly
included Index.h that provides them. Previously it got lucky and other
headers were always included first but with the sorting it ended up
first in one case and stopped compiling. Adding the Index.h include
fixes it right up.
llvm-svn: 202810
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
We should only have this optimization fire when the explicit
instantiation definition would cause at least one member function to be
emitted, thus ensuring that even a compiler not performing this
optimization would still emit the full type information elsewhere.
But we should also pessimize output still by always emitting the
definition when the explicit instantiation definition appears so that at
some point in the future we can depend on that information even when no
code had to be emitted in that TU. (this shouldn't happen very often,
since people mostly use explicit spec decl/defs to reduce code size -
but perhaps one day they could use it to explicitly reduce debug info
size too)
This was worth about 2% for Clang and LLVM - so not a huge win, but a
win. It looks really great for simple STL programs (include <string> and
just declare a string - 14k -> 1.4k of .dwo)
llvm-svn: 202769
predicate. The wrapper used by SetVector was erroneously requiring an
adaptable predicate. It has been fixed and we really don't want to
require an indirect call for every predicate evaluation.
llvm-svn: 202744
Serialized diagnostics were accidentally using the AST diagnostic level values
rather than a dedicated stable enum, so the addition of "remark" broke the
reading of existing serialized diagnostics files. I've added a .dia file
generated from Xcode 5's Clang to make sure we don't break this in the future.
llvm-svn: 202733
It isn't appropriate for a tool to be stomping over the dependency files,
especially if the actual build uses a compiler other than Clang or the tool
cannot find all the headers for some reason (which would cause the existing
dependency file to be deleted).
If a tool actually needs to care about dependency files we can think about
adding a mechanism for getting to this information.
Differential Revision: http://llvm-reviews.chandlerc.com/D2912
llvm-svn: 202669
This adds support for the PPC "wc" inline asm constraint (used for allocating
individual CR bits). Support for this constraint type was recently added to the
LLVM PowerPC backend. Although gcc does not currently support allocating
individual CR bits, this identifier choice has been coordinated with the gcc
PowerPC team, and will be marked as reserved for this purpose in the gcc
constraints.md file.
Prior to this change, none of the multi-character PPC constraints were handled
correctly (the '^' escape character was not being added as required by the
parsing code in LLVM). This should now be fixed. I'll add tests for these other
constraints as support is added for them in the backend.
llvm-svn: 202658
init list formatting. This suggestion has now gone into the LLVM coding
standards, and is particularly relevant now that we're using C++11.
Updated a really ridiculous number of tests to reflect this change.
llvm-svn: 202637
When lowering a bitfield, CGRecordLowering would assign the wrong
storage type to a bitfield in some cases and trigger an assertion. In
these cases the layout was still correct, just the bitfield info was
wrong.
llvm-svn: 202562
it, importers of B should not see the macro. This is complicated by the fact
that A's macro could also be visible through a different path. The rules (as
hashed out on cfe-commits) are included as a documentation update in this
change.
With this, the number of regressions in libc++'s testsuite when modules are
enabled drops from 47 to 7. Those remaining 7 are also macro-related, and are
due to remaining bugs in this change (in particular, the handling of submodules
is imperfect).
llvm-svn: 202560
Was r202442
There were two issues with the original patch that have now been fixed.
1. We were memset'ing over a FileEntry in a test case. After adding a
std::string to FileEntry, this still happened to not break for me.
2. I didn't pass the FileManager into the new compiler instance in
compileModule. This was hidden in some cases by the fact I didn't
clear the module cache in the test.
Also, I changed the copy constructor for FileEntry, which was memcpy'ing
in a (now) unsafe way.
llvm-svn: 202539
A 'remark' is information that is not an error or a warning, but rather some
additional information provided to the user. In contrast to a 'note' a 'remark'
is an independent diagnostic, whereas a 'note' always depends on another
diagnostic.
A typical use case for remark nodes is information provided to the user, e.g.
information provided by the vectorizer about loops that have been vectorized.
This patch provides the initial implementation of 'remarks'. It includes the
actual definiton of the remark nodes, their printing as well as basic parameter
handling. We are reusing the existing diagnostic parameters which means a remark
can be enabled with normal '-Wdiagnostic-name' flags and can be upgraded to
an error using '-Werror=diagnostic-name'. '-Werror' alone does not upgrade
remarks.
This patch is by intention minimal in terms of parameter handling. More
experience and more discussions will most likely lead to further enhancements
in the parameter handling.
llvm-svn: 202475
const char *format = "%s";
std::experimental::string_view view = "foo";
printf(format, view);
In this case, not only warn about a class type being used here, but also suggest that calling c_str() might be a good idea.
llvm-svn: 202461
Pass through the externally-visible names that we got from the VFS down
to FileManager, and test that this is the name showing up in __FILE__,
diagnostics, and debug information.
llvm-svn: 202442
Keep the copy constructor around, and add a FIXME that we should really
remove it as soon as we have C++11 std::map's emplace function.
llvm-svn: 202439
In r201528, I changed the PGO instrumentation counter for a "do" loop to not
include the fall-through count. That fall-through count is included later, b
it means that this assertion may fail for "do" loops.
llvm-svn: 202437
This is a heuristic. Many switch statements, although they look covered
over an enum, may actually handle at runtime more values than in the enum.
This is overly conservative, as there are some cases that clearly
can be ruled as being clearly unreachable, e.g. 'switch (42) { case 1: ... }'.
We can refine this later.
llvm-svn: 202436
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
This cleans up some constructors that would not be safe once FileEntry
owns the storage for its name. These were already suspect, since they
wouldn't work if the FileEntry had an open file descriptor. The only
user for these constructors was in UniqueFileContainer, which wasn't a
very useful abstraction anyway. So it and UniqueDirContainer have been
replaced with std::map<UniqueID, *>.
This change should not affect anything outside the FileManager.
llvm-svn: 202420
In llvm the only semantic difference between internal and private is that llvm
tries to hide private globals my mangling them with a private prefix. Since
the globals changed by this patch already had the magic don't mangle marker,
there should be no change in the generated assembly.
A followup patch should then be able to drop the \01L and \01l prefixes and let
llvm mangle as appropriate.
llvm-svn: 202419
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
When true, sets the name of the file to be the name from
'external-contents'. Otherwise, you get the virtual path that the file
was looked up by. This will not affect any non-virtual paths, or fully
virtual paths (for which there is no reasonable 'external' name anyway).
The setting is available globally, but can be overriden on a per-file
basis.
The goal is that this setting will control which path you see in debug
info, diagnostics, etc. which are sensitive to which path is used. That
will come in future patches that pass the name through to FileManager.
llvm-svn: 202329
For example:
unreachable();
break;
This code is idiomatic and defensive. The fact that 'break' is
unreachable here is not interesting. This occurs frequently
in LLVM/Clang itself.
llvm-svn: 202328
This is to support some analyses, like -Wunreachable-code, that
will need to recover the original unprunned CFG edges in order
to suppress issues that aren't really bugs in practice.
There are two important changes here:
- AdjacentBlock replaces CFGBlock* for CFG successors/predecessors.
This has the size of 2 pointers, instead of 1. This is unlikely
to have a significant memory impact on Sema since a single
CFG usually exists at one time, but could impact the memory
usage of the static analyzer. This could possibly be optimized
down to a single pointer with some cleverness.
- Predecessors can now contain null predecessors, which means
some analyses doing a reverse traversal will need to take into
account. This already exists for successors, which contain
successor slots for specific branch kinds (e.g., 'if') that
expect a fixed number of successors, even if a branch is
not reachable.
llvm-svn: 202325
Clang is using llvm::StructType::isOpaque() as a way of signaling if
we've finished record type conversion in
CodeGenTypes::isRecordLayoutComplete(). However, Clang was setting the
body of the type before it finished laying out the type as a base type.
Laying out the %class.C.base LLVM type attempts to convert more types,
eventually recursively attempting to layout 'C' again, at which point we
would say that layout was complete, even though we were still in the
middle of it.
By not setting the body, we correctly signal that layout is not
complete, and things work as expected.
At some point, it might be worth refactoring this to avoid looking at
the LLVM IR types under construction.
llvm-svn: 202320
Before this patch the globals were created with the wrong linkage and patched
afterwards. From the comments it looks like something would complain about
having an internal GV with no initializer. At least in clang the verifier will
only run way after we set the initializer, so that is not a problem.
This patch should be a nop. It just figures out the linkage earlier and
converts the old calls to setLinkage to asserts. The only case where that is
not possible is when we first see a weak import that is then implemented. In
that case we have to change the linkage, but that is the only setLinkage left.
llvm-svn: 202305
null comparison when the pointer is known to be non-null.
This catches the array to pointer decay, function to pointer decay and
address of variables. This does not catch address of function since this
has been previously used to silence a warning.
Pointer to bool conversion is under -Wbool-conversion.
Pointer to null comparison is under -Wtautological-pointer-compare, a sub-group
of -Wtautological-compare.
void foo() {
int arr[5];
int x;
// warn on these conditionals
if (foo);
if (arr);
if (&x);
if (foo == null);
if (arr == null);
if (&x == null);
if (&foo); // no warning
}
llvm-svn: 202216
For now, just ignore them. Later, we could try looking through LazyCompoundVals,
but we at least shouldn't crash.
<rdar://problem/16153464>
llvm-svn: 202212
The warnings fall into three groups.
1) Using an absolute value function of the wrong type, for instance, using the
int absolute value function when the argument is a floating point type.
2) Using the improper sized absolute value function, for instance, using abs
when the argument is a long long. llabs should be used instead.
From these two cases, an implicit conversion will occur which may cause
unexpected behavior. Where possible, suggest the proper absolute value
function to use, and which header to include if the function is not available.
3) Taking the absolute value of an unsigned value. In addition to this warning,
suggest to remove the function call. This usually indicates a logic error
since the programmer assumed negative values would have been possible.
llvm-svn: 202211
Generating RTTI in the MS ABI is currently not supported, and the failures
are confusing to users, so let's disable it by default for now.
llvm-svn: 202178
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
The 'f' modifier is designed for integer type arguments really (according to
its documentation). It's better to use the "half width, same number" modifier.
Should be no user-visible change.
llvm-svn: 202152
The __forceinline keyword's semantics are now recast as AlwaysInline and
the kw___forceinline token has its language mode set for KEYMS.
This preserves the semantics of the previous implementation but with
less duplication of code.
llvm-svn: 202131
This allows the 'name' field to contain a path, like
{ 'type': 'directory',
'name': '/path/to/dir',
'contents': [ ... ] }
which not only simplifies reading and writing these files (for humans),
but makes it possible to easily modify locations via textual
replacement, which would not have worked in the old scheme.
E.g. sed s:<ROOT>:<NEW ROOT>
llvm-svn: 202109
Take advantage of CharUnits::alignmentAtOffset instead of calculating it
by hand.
Differential Revision: http://llvm-reviews.chandlerc.com/D2862
llvm-svn: 202098
Previously the X86 backend would look for the sret attribute and handle
this for us. inalloca takes that all away, so we have to do the return
ourselves now.
llvm-svn: 202097
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
We were previously checking at every destructor declaration, but that was a bit
excessive. Since the deleting destructor is emitted with the vtable, do the
check when the vtable is marked used.
Differential Revision: http://llvm-reviews.chandlerc.com/D2851
llvm-svn: 202046
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
We still don't use the PGO to set branch weights for these loops, but at
least this keeps the compiler from crashing. <rdar://problem/16137778>
llvm-svn: 202002
- Only include offsets with local (in function scope) symbols, where we don't encode scoping
- Only include the filename with non-system symbols. Presumably the system headers will not provide conflicting definitions.
rdar://15976823
llvm-svn: 201990
The DiagnosticBuilder's lifetime in parser typo recovery was overlapping with
the subsequent consume which can itself emit PP diagnostics.
Patch by Olivier Goffart!
llvm-svn: 201965
The integrated assembler is a feature. This makes the new flags the default
option, and the previous versions aliases. Ideally, at some point the aliases
would be entirely removed.
llvm-svn: 201963
Forward the -no-integrated-as option to -cc1 rather than simply invoking the
appropriate tool. This is useful since this option has been overloaded to
permit disabling of parsing inline assembly at the MC layer.
This re-applies the previous version of the patch with a renaming of the driver
option to the public name rather than the internal name (-target vs -triple).
The actual failure is fixed separately of an overly aggressive negative pattern
match in the MIPS driver tests. It also fixes the incorrect test for targets
that have the integrated assembler disabled by default.
llvm-svn: 201960
Forward the -no-integrated-as option to -cc1 rather than simply invoking the
appropriate tool. This is useful since this option has been overloaded to
permit disabling of parsing inline assembly at the MC layer.
llvm-svn: 201952
The language forbids defining enums in prototypes, so this check is normally
redundant, but if an enum is defined during template instantiation it should
not be added to the prototype scope.
While at it, clean up the code that deals with tag definitions in prototype
scope and expand the visibility warning to cover the case where an anonymous
enum is defined.
Differential Revision: http://llvm-reviews.chandlerc.com/D2742
llvm-svn: 201927
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
It was previously thought that Sema::InstantiateClass could not fail
from within this point in instantiate.
However, it can happen if the class is invalid some way (i.e. invalid
base specifier).
This fixes PR18907.
Differential Revision: http://llvm-reviews.chandlerc.com/D2850
llvm-svn: 201913
In particular, if we see an @property within the @interface of a class
conforming to a protocol with this attribute, we treat that as
if the implementation were available, per the rules of default
property synthesis.
llvm-svn: 201911
CGRecordLayoutBuilder was aging, complex, multi-pass, and shows signs of
existing before ASTRecordLayoutBuilder. It redundantly performed many
layout operations that are now performed by ASTRecordLayoutBuilder and
asserted that the results were the same. With the addition of support
for the MS-ABI, such as placement of vbptrs, vtordisps, different
bitfield layout and a variety of other features, CGRecordLayoutBuilder
was growing unwieldy in its redundancy.
This patch re-architects CGRecordLayoutBuilder to not perform any
redundant layout but rather, as directly as possible, lower an
ASTRecordLayout to an llvm::type. The new architecture is significantly
smaller and simpler than the CGRecordLayoutBuilder and contains fewer
ABI-specific code paths. It's also one pass.
The architecture of the new system is described in the comments. For the
most part, the new system simply takes all of the fields and bases from
an ASTRecordLayout, sorts them, inserts padding and dumps a record.
Bitfields, unions and primary virtual bases make this process a bit more
complicated. See the inline comments.
In addition, this patch updates a few lit tests due to the fact that the
new system computes more accurate llvm types than CGRecordLayoutBuilder.
Each change is commented individually in the review.
Differential Revision: http://llvm-reviews.chandlerc.com/D2795
llvm-svn: 201907
Provides a way to create a virtual file system using a YAML file that
supports mapping a file to a path on an 'external' file system. The
external file system will typically be the 'real' file system, but for
testing it can be changed.
A future patch will add a clang option to allow the user to specify such
a file and overlay it, but for now this code is only exercised by the
unit tests.
Differential Revision: http://llvm-reviews.chandlerc.com/D2835
llvm-svn: 201905
Because GCC incorrectly defines _mm_prefetch to take anything that casts
to void*, people have started using that behavior. The previous patch
that made _mm_prefetch actually take a const char * broke compatibility
with existing code. This update to the patch leaves the macro that
defines _mm_prefetch with the (void*) cast when _MSC_VER is not defined.
llvm-svn: 201901
We're going to extend DiagnoseUnimplementedProperties shortly to look for more cases
that aren't handled by default property synthesis.
llvm-svn: 201878
Ben Langmuir