| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
iterator_range fields(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203355
|
|
|
|
|
|
| |
implemented in terms of iterator APIs.
llvm-svn: 203351
|
|
|
|
|
|
|
|
| |
sometimes have dangerous side-effects where the range temporary is destroyed, taking the underlying iterators out with it.
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
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 203289
|
|
|
|
|
|
| |
This compiles cleanly with lldb/lld/clang-tools-extra/llvm.
llvm-svn: 203279
|
|
|
|
|
|
| |
iterator_range decls(). The same is true for the noload versions of these APIs. Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203278
|
|
|
|
|
|
| |
Smith.
llvm-svn: 203262
|
|
|
|
|
|
| |
with iterator_range chains(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203261
|
|
|
|
|
|
| |
with iterator_range params(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203255
|
|
|
|
|
|
| |
iterator_range params(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203250
|
|
|
|
|
|
| |
iterator_range params(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203248
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 203241
|
|
|
|
|
|
| |
std::pair.
llvm-svn: 203239
|
|
|
|
|
|
| |
MSVC bots.
llvm-svn: 203237
|
|
|
|
|
|
| |
attrs(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203236
|
|
|
|
|
|
| |
inheritance hierarchy
llvm-svn: 203222
|
|
|
|
|
|
| |
iterator_range redecls(). Updating all of the usages of the iterators with range-based for loops, which allows the begin/end forms to be removed entirely.
llvm-svn: 203179
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
correct if MaxEditDistance were increased to something greater than 1).
llvm-svn: 203153
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
in TypePrinter::printObjCObjectPointerBefore.
Suggested by Jordan.
llvm-svn: 203124
|
|
|
|
| |
llvm-svn: 203087
|
|
|
|
|
|
|
| |
a white background is difficult to read. Also include a chart showing which
colors are used by which elements in the AST dump.
llvm-svn: 203050
|
|
|
|
|
|
| |
evaluating trivial default initialization of a literal class type.
llvm-svn: 203025
|
|
|
|
|
|
| |
Scope lives in Sema and cannot be used in AST. Shuffle things around.
llvm-svn: 202993
|
|
|
|
| |
llvm-svn: 202978
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
rdar://14309030
llvm-svn: 202941
|
|
|
|
|
|
|
| |
This simplifies my last patch a bit. No change in
functionality.
llvm-svn: 202906
|
|
|
|
|
|
| |
Copying isn't cheap as it contains a std::string.
llvm-svn: 202880
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
module import.
llvm-svn: 202771
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 202755
|
|
|
|
|
|
|
| |
Some files had CRLF line terminators, some only had a mixture of
CRLF and LF. Switch to LF.
llvm-svn: 202659
|
|
|
|
| |
llvm-svn: 202639
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 202590
|
|
|
|
| |
llvm-svn: 202558
|
|
|
|
| |
llvm-svn: 202458
|
|
|
|
|
|
| |
It makes our -fdump-record-layouts a little more sane.
llvm-svn: 202457
|
|
|
|
| |
llvm-svn: 202444
|
|
|
|
| |
llvm-svn: 202441
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 202360
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ASTUnit::getMainBufferWithPrecompiledPreamble().
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
|
|
|
|
|
|
|
|
|
|
|
| |
hierarchies (PR18967)
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
|