| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 157207
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
struct HIDDEN foo {
};
template <class P>
struct bar {
};
template <>
struct HIDDEN bar<foo> {
DEFAULT static void zed();
};
void bar<foo>::zed() {
}
Before we would produce a hidden symbol in
struct HIDDEN foo {
};
template <class P>
struct bar {
};
template <>
struct bar<foo> {
DEFAULT static void zed();
};
void bar<foo>::zed() {
}
But adding HIDDEN to the specialization would cause us to produce a default
symbol.
llvm-svn: 157206
|
|
|
|
|
|
| |
Fixes pr12835.
llvm-svn: 156897
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Don't copy the visibility attribute during instantiations. We have to be able
to distinguish
struct HIDDEN foo {};
template<class T>
DEFAULT void bar() {}
template DEFAULT void bar<foo>();
from
struct HIDDEN foo {};
template<class T>
DEFAULT void bar() {}
template void bar<foo>();
* If an instantiation has an attribute, it takes precedence over an attribute
in the template.
* With instantiation attributes handled with the above logic, we can now
select the minimum visibility when looking at template arguments.
llvm-svn: 156821
|
|
|
|
|
|
| |
Part of rdar://10796159
llvm-svn: 156228
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
filter_decl_iterator had a weird mismatch where both op* and op-> returned T*
making it difficult to generalize this filtering behavior into a reusable
library of any kind.
This change errs on the side of value, making op-> return T* and op* return
T&.
(reviewed by Richard Smith)
llvm-svn: 155808
|
|
|
|
|
|
| |
argument list.
llvm-svn: 155368
|
|
|
|
| |
llvm-svn: 155352
|
|
|
|
|
|
|
|
|
|
|
| |
the tempale arguments in deciding the visibility.
This agrees with gcc 4.7.
Found by trying to build chrome with component=shared_library with 155314
reverted.
llvm-svn: 155316
|
|
|
|
|
|
| |
with this testcase.
llvm-svn: 155301
|
|
|
|
|
|
| |
a boolean.
llvm-svn: 155299
|
|
|
|
|
|
|
|
| |
This fixes the included testcase and lets us simplify the code a bit. It
does require using mergeWithMin when merging class information to its
members. Expand the comments to explain why that works.
llvm-svn: 155103
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
there is no need for mergeVisibily to ever increase the visibility. Not
doing so lets us replace an incorrect use of mergeVisibilityWithMin. The
testcase
struct HIDDEN RECT {
int top;
};
DEFAULT RECT foo = {0};
shows that we should give preference to one of the attributes instead of
keeping the minimum. We still get this testcase wrong because mergeVisibily
handles two explicit visibilities incorrectly, but this is a step in the
right direction.
llvm-svn: 155101
|
|
|
|
| |
llvm-svn: 155100
|
|
|
|
|
|
| |
DHasExplicitVisibility. Simplify the code a bit.
llvm-svn: 155099
|
|
|
|
|
|
|
|
|
|
|
|
| |
the current implementation this should be a nop as explicit visibility
takes precedence in mergeVisibility.
The location chosen is such that attributes checked above it can force
a symbol to be default. For example, an attribute is the variable or function.
Attributes checked after this point, can only make the visibility more
restrictive. An attribute in a type for example.
llvm-svn: 155098
|
|
|
|
|
|
|
|
| |
currently a nop as those users are the first merge or are a merge
of a hidden explicit visibility, which always wins in the current
implementation.
llvm-svn: 155095
|
|
|
|
|
|
| |
explicit.
llvm-svn: 154969
|
|
|
|
|
|
| |
functionality change.
llvm-svn: 154940
|
|
|
|
| |
llvm-svn: 154846
|
|
|
|
|
|
| |
ConsiderGlobalVisibility. No functionality change.
llvm-svn: 154843
|
|
|
|
| |
llvm-svn: 154814
|
|
|
|
|
|
| |
I am working on a cleaner fix, but this gets the case in PR12552 passing.
llvm-svn: 154749
|
|
|
|
|
|
|
|
|
|
|
| |
search for the specialization (in a folding set) and, if not found
form a *Decl that is then inserted into that folding set. In rare
cases, the folding set may be reallocated between the search and the
insertion, causing a crash. No test case, because triggering rehashing
consistently in a small test case is not feasible. Fixes
<rdar://problem/11115071>.
llvm-svn: 153575
|
|
|
|
|
|
|
|
|
| |
completion item. For example, if the code completion itself represents
a declaration in a namespace (say, std::vector), then this API
retrieves the cursor kind and name of the namespace (std). Implements
<rdar://problem/11121951>.
llvm-svn: 153545
|
|
|
|
|
|
|
| |
class template's definition, and for explicit specializations of such enum
members.
llvm-svn: 153304
|
|
|
|
|
|
|
|
| |
scoped enumeration members. Later uses of an enumeration temploid as a nested
name specifier should cause its instantiation. Plus some groundwork for
explicit specialization of member enumerations of class templates.
llvm-svn: 152750
|
|
|
|
|
|
|
|
|
|
| |
(Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
llvm-svn: 152536
|
|
|
|
| |
llvm-svn: 152493
|
|
|
|
|
|
|
| |
- This function is not at all free; pass it around along some hot paths instead
of recomputing it deep inside various VarDecl methods.
llvm-svn: 152363
|
|
|
|
| |
llvm-svn: 152339
|
|
|
|
|
|
| |
incredibly common) path.
llvm-svn: 152321
|
|
|
|
|
|
| |
"false" for declarations that aren't members of classes. Fixes PR12106.
llvm-svn: 152284
|
|
|
|
| |
llvm-svn: 152166
|
|
|
|
|
|
| |
-- which is very much not free -- in the common case.
llvm-svn: 152165
|
|
|
|
|
|
|
|
|
| |
early, since their values can be used in constant expressions in C++11. For
odr-use checking, the opposite change is required, since references are
odr-used whether or not they satisfy the requirements for appearing in a
constant expression.
llvm-svn: 151881
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bug that was caught by Apple's internal buildbots was valid and also showed another bug in my implementation.
These are now fixed, with regression tests added to catch them both (not Darwin-specific).
Original log:
====================
Revert r151638 because it causes assertion hit on PCH creation for Cocoa.h
Original log:
---------------------
Correctly track tags and enum members defined in the prototype of a function, and ensure they are properly scoped.
This fixes code such as:
enum e {x, y};
int f(enum {y, x} n) {
return 0;
}
This finally fixes PR5464 and PR5477.
---------------------
I also reverted r151641 which was enhancement on top of r151638.
====================
llvm-svn: 151712
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Original log:
---------------------
Correctly track tags and enum members defined in the prototype of a function, and ensure they are properly scoped.
This fixes code such as:
enum e {x, y};
int f(enum {y, x} n) {
return 0;
}
This finally fixes PR5464 and PR5477.
---------------------
I also reverted r151641 which was enhancement on top of r151638.
llvm-svn: 151667
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function, and ensure they are properly scoped.
This fixes code such as:
enum e {x, y};
int f(enum {y, x} n) {
return 0;
}
This finally fixes PR5464 and PR5477.
llvm-svn: 151638
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Handle some situations where we should never make a decl more visible,
even when merging in an explicit visibility.
* Handle attributes in members of classes that are explicitly specialized.
Thanks Nico for the report and testing, Eric for the initial review, and dgregor
for the awesome test27 :-)
llvm-svn: 151236
|
|
|
|
|
|
|
|
|
| |
stable mangling, since these lambdas can end up in multiple
translation units. Sema is responsible for deciding when this is the
case, because it's already responsible for choosing the mangling
number.
llvm-svn: 151029
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
operator overloads out of line.
This seems to negatively affect compile time onsome ObjC tests
(which use a lot of partial diagnostics I assume). I have to come
up with a way to keep them inline without including Diagnostic.h
everywhere. Now adding a new diagnostic requires a full rebuild
of e.g. the static analyzer which doesn't even use those diagnostics.
This reverts commit 6496bd10dc3a6d5e3266348f08b6e35f8184bc99.
This reverts commit 7af19b817ba964ac560b50c1ed6183235f699789.
This reverts commit fdd15602a42bbe26185978ef1e17019f6d969aa7.
This reverts commit 00bd44d5677783527d7517c1ffe45e4d75a0f56f.
This reverts commit ef9b60ffed980864a8db26ad30344be429e58ff5.
llvm-svn: 150006
|
|
|
|
|
|
| |
same logic as FunctionDecl::isInlineDefinitionExternallyVisible to figure out whether to emit a definition. Based on work by Anton Yartsev.
llvm-svn: 149963
|
|
|
|
|
|
| |
C++11 mode. PR11928.
llvm-svn: 149908
|
|
|
|
|
|
|
|
|
| |
of Diagnostic.h.
Fix all the files that depended on transitive includes of Diagnostic.h.
With this patch in place changing a diagnostic no longer requires a full rebuild of the StaticAnalyzer.
llvm-svn: 149781
|
|
|
|
|
|
|
|
|
|
|
| |
argument in strncat.
The warning is ignored by default since it needs more qualification.
TODO: The warning message and the note are messy when
strncat is a builtin due to the macro expansion.
llvm-svn: 149524
|
|
|
|
| |
llvm-svn: 148577
|
|
|
|
| |
llvm-svn: 148369
|
|
|
|
|
|
|
|
|
|
| |
for FunctionDecl::getMemoryFunctionKind().
This is a follow up on the Chris's review for r148142: We don't want to
pollute FunctionDecl with an extra enum. (To make this work, added
memcmp and family to the library builtins.)
llvm-svn: 148267
|
|
|
|
|
|
|
|
| |
or VarDecl::isExternC, and instead queries what it actually cares about: whether the given declaration is inside an extern "C" context. Fundamentally, figuring out whether a function/variable uses C linkage requires knowing the linkage, and the logic in FunctionDecl::isExternC and VarDecl::isExternC was getting it wrong. Given that, fix FunctionDecl::isExternC and VarDecl::isExternC to use much simpler implementations that depend on the fixed linkage computation.
Fixes a regression to test/SemaCXX/linkage.cpp caused by a new warning exposing the fact that the internal state was wrong.
llvm-svn: 148207
|