| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
whether it's part of a module.
llvm-svn: 203005
|
|
|
|
|
|
| |
Scope lives in Sema and cannot be used in AST. Shuffle things around.
llvm-svn: 202993
|
|
|
|
| |
llvm-svn: 202978
|
|
|
|
|
|
| |
MSVC2013's standard library is too broken to understand this pattern.
llvm-svn: 202971
|
|
|
|
| |
llvm-svn: 202968
|
|
|
|
| |
llvm-svn: 202964
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inherited protocols and protocols already conformed in the class hierarchy.
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
|
|
|
|
| |
llvm-svn: 202942
|
|
|
|
|
|
| |
rdar://14309030
llvm-svn: 202941
|
|
|
|
| |
llvm-svn: 202940
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
value".
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
|
|
|
|
| |
llvm-svn: 202909
|
|
|
|
|
|
|
| |
This simplifies my last patch a bit. No change in
functionality.
llvm-svn: 202906
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
types aren't needlessly built during -gmlt
llvm-svn: 202900
|
|
|
|
| |
llvm-svn: 202898
|
|
|
|
| |
llvm-svn: 202897
|
|
|
|
|
|
|
|
| |
predecessor.
Fies PR19040.
llvm-svn: 202892
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Copying isn't cheap as it contains a std::string.
llvm-svn: 202880
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 202870
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
r202827.
llvm-svn: 202828
|
|
|
|
|
|
| |
r202821.
llvm-svn: 202822
|
|
|
|
|
|
| |
LLVM r202816.
llvm-svn: 202817
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 202792
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
(renamed res to __res)
llvm-svn: 202784
|
|
|
|
|
|
|
|
|
| |
explicit template instantiation declarations
* detect out of line definitions correctly
* detect member function explicit specializations correctly
llvm-svn: 202779
|
|
|
|
| |
llvm-svn: 202778
|
|
|
|
|
|
| |
module import.
llvm-svn: 202771
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
explicit instantiation declaration (& always emit such a type when there's an explicit instantiation definition)
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
|
|
|
|
|
|
|
| |
for metadata symbols for forward referenced protocols which
are never defined. // rdar://16203115
llvm-svn: 202761
|
|
|
|
|
|
| |
the type of the first parameter fails, and it is the only, unnamed, parameter).
llvm-svn: 202759
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 202755
|
|
|
|
|
|
|
| |
This needs to modify a line table test to account for the new lexical
block created to hold the new discriminator value.
llvm-svn: 202754
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Create lexical blocks with discriminator value 0 by default.
llvm-svn: 202737
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 202711
|
|
|
|
|
|
|
|
|
|
| |
a user workspace build.
This is used to avoid conflicts with user modules with the same name from different workspaces.
rdar://16042513
llvm-svn: 202683
|
|
|
|
|
|
| |
Allows removing #include's in LLVM while switching to std::unique_ptr.
llvm-svn: 202677
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|