| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang outputs LLVM one top level decl at a time. This combined with the
visibility computation code looking for the newest NamespaceDecl would cause
it to produce different results for nested namespaces.
The two options for producing consistent results are
* Delay codegen of anything inside a namespace until the end of the file.
* Don't look for the newest NamespaceDecl.
This patch implements the second option.
This matches the gcc behavior too.
llvm-svn: 196712
|
|
|
|
|
|
| |
tests fail.
llvm-svn: 188447
|
|
|
|
| |
llvm-svn: 184137
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since r175326 an implicitly hidden template argument can cause a template
installation to become hidden, even if the template itself has an explicit
default visibility. This requires that we keep track of "late" additions
of the visibility attribute.
This is hopefully the last followup change. It just removes the caching of
visibilities from types so that we can see new attributes even after a type has
been used.
llvm-svn: 176164
|
|
|
|
| |
llvm-svn: 176138
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that implicitly hidden template arguments can make an instantiation hidden,
it is important to look at more than just the canonical decl of the argument
in order to see if an attribute is available in a more recent decl.
This has the disadvantage of exposing when getExplicitVisibility is called,
but lets us handle cases like
template <typename T>
struct __attribute__((visibility("default"))) barT {
static void zed() {}
};
class foo;
class __attribute__((visibility("default"))) foo;
template struct barT<foo>;
llvm-svn: 176112
|
|
|
|
|
|
| |
for explicit member specializations.
llvm-svn: 175827
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
control the visibility of a type for the purposes of RTTI
and template argument restrictions independently of how
visibility propagates to its non-type member declarations.
Also fix r175326 to not ignore template argument visibility
on a template explicit instantiation when a member has
an explicit attribute but the instantiation does not.
The type_visibility work is rdar://11880378
llvm-svn: 175587
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for distinguishing type vs. value visibility.
The changes to the visibility of explicit specializations
are intentional. The change to the "ugly" test case is
a consequence of a sensible implementation, and I am happy
to argue that this is better behavior. Other changes may
or may not be intended; it is quite difficult to divine
intent from some of the code I altered.
I've left behind a comment which I hope explains the
philosophy behind visibility computation.
llvm-svn: 175326
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The testcase in pr14929 shows that this is extremely hard to do. If we choose
to apply the attribute, that causes the visibility of some decls to change and
that can happen really late (during codegen).
Current gcc warns and ignores the attribute in this testcase with a warning.
This suggest that the correct solution is to find a point in the compilation
where we can compute the visibility and
* assert it was never computed before
* reject any attempts to compute it again in the future (with warnings).
llvm-svn: 172305
|
|
|
|
|
|
| |
fails to consider the linkage, which we were already considering.
llvm-svn: 161070
|
|
|
|
|
|
| |
as arguments of a template.
llvm-svn: 160911
|
|
|
|
|
|
| |
to build a type before seeing the definition.
llvm-svn: 160339
|
|
|
|
|
|
| |
we might use the declaration to build a type before seeing the definition.
llvm-svn: 160176
|
|
|
|
|
|
|
| |
canonical decl for the template, but that we were not merging attributes for
templates at all!
llvm-svn: 160157
|
|
|
|
|
|
| |
attribute.
llvm-svn: 160139
|
|
|
|
|
|
| |
pr13338.
llvm-svn: 160105
|
|
|
|
| |
llvm-svn: 160057
|
|
|
|
|
|
|
| |
instantiation depends on the template, its arguments and parameters, but not
where it is instantiated.
llvm-svn: 160034
|
|
|
|
|
|
|
|
|
| |
only using the linkage.
Use and test both, documenting that considering the visibility and linkage
of template parameters is a difference from gcc.
llvm-svn: 158309
|
|
|
|
|
|
| |
method template.
llvm-svn: 157486
|
|
|
|
|
|
| |
function template.
llvm-svn: 157480
|
|
|
|
|
|
| |
the visibility.
llvm-svn: 157475
|
|
|
|
|
|
|
| |
Similar fixes for function and member template to follow as I write the
testcases.
llvm-svn: 157470
|
|
|
|
| |
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
|
|
|
|
|
|
| |
attributes.
llvm-svn: 157186
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
argument list.
llvm-svn: 155368
|
|
|
|
| |
llvm-svn: 155351
|
|
|
|
|
|
|
| |
by a chrome build on OS X. Thanks to Nico Weber for testing a patch and
providing the .ii file.
llvm-svn: 155326
|
|
|
|
| |
llvm-svn: 155317
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
components build.
llvm-svn: 155314
|
|
|
|
| |
llvm-svn: 155304
|
|
|
|
| |
llvm-svn: 155302
|
|
|
|
|
|
| |
with this testcase.
llvm-svn: 155301
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
an explicit default one. This means that with -fvisibility hidden we
now produce a hidden symbol for
template <typename T>
class DEFAULT foo {
void bar() {}
};
class zed {};
template class foo<zed>;
This matches the behaviour of gcc 4.7.
llvm-svn: 155102
|
|
|
|
| |
llvm-svn: 154846
|
|
|
|
|
|
| |
I am working on a cleaner fix, but this gets the case in PR12552 passing.
llvm-svn: 154749
|
|
|
|
| |
llvm-svn: 152493
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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
|
|
|
|
|
|
|
|
| |
With that, centralize the way we merge visibility, always preferring explicit over
implicit and then picking the most restrictive one.
Fixes pr10113 and pr11690.
llvm-svn: 148163
|
|
|
|
|
|
| |
PR11690.
llvm-svn: 147523
|
|
|
|
| |
llvm-svn: 147441
|
|
|
|
| |
llvm-svn: 147424
|
|
|
|
|
|
| |
take precedence over command line options. Fixes PR10113.
llvm-svn: 147405
|
|
|
|
|
|
| |
declarations without a declarator to structs. Add a warning for ignored attributes. Patch by Michael Han.
llvm-svn: 146796
|