479 Commits

Author SHA1 Message Date
Rafael Espindola
fb9d4b4c3b Handle gnu_inline in c++ in a gcc compatible way. Original patch by Tobias
Grosser.

llvm-svn: 165720
2012-10-11 16:32:25 +00:00
Argyrios Kyrtzidis
e0d649789d In VarDecl::getSourceRange() make sure to check that the source location
of the initializer is valid before using it.

Fixes rdar://12455002&12449015 where local variables of objc objects in ARC mode
were not annotated because of the ImplicitValueInitExpr initializer having invalid
source range, resulting in the SourceRange of the VarDecl having invalid end location.

llvm-svn: 165456
2012-10-08 23:08:41 +00:00
Eli Friedman
b826a00857 Fix the AST representation for non-type template arguments to encode
enough information so we can mangle them correctly in cases involving
dependent parameter types. (This specifically impacts cases involving
null pointers and cases involving parameters of reference type.)
Fix the mangler to use this information instead of trying to scavenge
it out of the parameter declaration.

<rdar://problem/12296776>.

llvm-svn: 164656
2012-09-26 02:36:12 +00:00
Argyrios Kyrtzidis
f89a92702f [PCH] When loading fields from external storage make sure to also
load in the IndirectField declarations as well.

Field designators in initializer lists depend on traversing the fields
decl chain to find the indirect fields.

Fixes rdar://12239321

llvm-svn: 163552
2012-09-10 22:04:22 +00:00
Eli Friedman
5c27c4cef0 Switch a couple getAs uses to castAs.
llvm-svn: 162948
2012-08-30 22:22:09 +00:00
Rafael Espindola
fb4263f156 Consider the visibility of template template arguments. GCC doesn't, but it also
fails to consider the linkage, which we were already considering.

llvm-svn: 161070
2012-07-31 19:02:02 +00:00
Sylvestre Ledru
830885ca64 Fix a typo (the the => the)
llvm-svn: 160622
2012-07-23 08:59:39 +00:00
Rafael Espindola
5cc7890cac Move option test earlier in the function.
llvm-svn: 160202
2012-07-13 23:26:43 +00:00
Rafael Espindola
c7c7ad5f7e Use -fvisibility-inlines-hidden in inline functions too. This matches gcc
behavior since gcc pr30066. Thanks to Benjamin Kramer for pointing it out.

llvm-svn: 160174
2012-07-13 14:25:36 +00:00
Rafael Espindola
eca5cd20a1 Fix a bug in my previous commit. The problem is not that we were not using the
canonical decl for the template, but that we were not merging attributes for
templates at all!

llvm-svn: 160157
2012-07-13 01:19:08 +00:00
Rafael Espindola
6140847647 Use the canonical template decl when trying to find if it has a visibility
attribute.

llvm-svn: 160139
2012-07-12 20:05:04 +00:00
Abramo Bagnara
b1cdde7d21 Reintroduced FieldDecl public methods setBitWidth and removeBitWidth.
llvm-svn: 159579
2012-07-02 20:35:48 +00:00
Rafael Espindola
a486f48e5b We were computing the visibility and linkage of template parameters, but
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
2012-06-11 14:29:58 +00:00
Richard Smith
2b013185f8 PR13064: Store whether an in-class initializer uses direct or copy
initialization, and use that information to produce the right kind of
initialization during template instantiation.

llvm-svn: 158288
2012-06-10 03:12:00 +00:00
Richard Smith
12f247f43f PR13051: If a constructor is explicitly defaulted, it isn't marked as being
constexpr until we get to the end of the class definition. When that happens,
be sure to remember that the class actually does have a constexpr constructor.

This is a stopgap solution, which still doesn't cover the case of a class with
multiple copy constructors (only some of which are constexpr). We should be
performing constructor lookup when implicitly defining a constructor in order
to determine whether all constructors it invokes are constexpr.

llvm-svn: 158228
2012-06-08 21:09:22 +00:00
David Blaikie
40ed29730b Revert Decl's iterators back to pointer value_type rather than reference value_type
In addition, I've made the pointer and reference typedef 'void' rather than T*
just so they can't get misused. I would've omitted them entirely but
std::distance likes them to be there even if it doesn't use them.

This rolls back r155808 and r155869.

Review by Doug Gregor incorporating feedback from Chandler Carruth.

llvm-svn: 158104
2012-06-06 20:45:41 +00:00
Rafael Espindola
67a498cc5f Don't ignore linkage when ignoring visibility in the instantiation of a
method template.

llvm-svn: 157486
2012-05-25 17:22:33 +00:00
Rafael Espindola
340941dc16 Don't ignore linkage when ignoring visibility in the instantiation of a
function template.

llvm-svn: 157480
2012-05-25 16:41:35 +00:00
Rafael Espindola
a28bf63d9a Consider the linkage for member class templates even when we have to ignore
the visibility.

llvm-svn: 157475
2012-05-25 15:51:26 +00:00
Rafael Espindola
0cf10ac9ab When ignoring visibility in an instantiation, still consider the linkage.
Similar fixes for function and member template to follow as I write the
testcases.

llvm-svn: 157470
2012-05-25 14:47:05 +00:00
Rafael Espindola
4d71d0f9fa Whitespace fixes.
llvm-svn: 157469
2012-05-25 14:17:45 +00:00
Rafael Espindola
96dcb8d4bb Function template version of the previous patch.
llvm-svn: 157207
2012-05-21 20:31:27 +00:00
Rafael Espindola
93c289c28a Produce a hidden symbol for zed in
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
2012-05-21 20:15:56 +00:00
Rafael Espindola
96e6824c31 Fix the visibility of instantiations of static data members.
Fixes pr12835.

llvm-svn: 156897
2012-05-16 02:10:38 +00:00
Rafael Espindola
7f90b7d4c2 Fix our handling of visibility in explicit template instantiations.
* 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
2012-05-15 14:09:55 +00:00
Argyrios Kyrtzidis
a18347eddb Use raw_ostream in TypePrinter and eliminate uses of temporary std::strings.
Part of rdar://10796159

llvm-svn: 156228
2012-05-05 04:20:37 +00:00
David Blaikie
2d7c57ec1d Remove the ref/value inconsistency in filter_decl_iterator.
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
2012-04-30 02:36:29 +00:00
Rafael Espindola
b522a5f246 Fix visibility when we have two types with explicit visibility in a template
argument list.

llvm-svn: 155368
2012-04-23 17:51:55 +00:00
Rafael Espindola
d88f37b8be Inline helper function into only caller.
llvm-svn: 155352
2012-04-23 14:27:47 +00:00
Rafael Espindola
bbc5cbc410 An attribute in a explicit template installation should take precedence over
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
2012-04-22 15:31:59 +00:00
Rafael Espindola
8add48ec9e Fix handling of template parameters. Found by inspection. GCC 4.7 agrees
with this testcase.

llvm-svn: 155301
2012-04-22 00:43:48 +00:00
Rafael Espindola
46cb6f1b51 All the members of LVFlags always have the same value, replace the class with
a boolean.

llvm-svn: 155299
2012-04-21 23:28:21 +00:00
Rafael Espindola
53cf219367 In mergeVisibility, if we already have an explicit visibility, keep it.
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
2012-04-19 05:50:08 +00:00
Rafael Espindola
1f073336b7 Now that we check visibility attributes in an appropriate order,
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
2012-04-19 05:24:05 +00:00
Rafael Espindola
b660efd57a Check ConsiderGlobalVisibility before using -fvisibility.
llvm-svn: 155100
2012-04-19 04:37:16 +00:00
Rafael Espindola
3d3d339357 The explicit bit in LV already tracks exactly the same information as
DHasExplicitVisibility. Simplify the code a bit.

llvm-svn: 155099
2012-04-19 04:27:47 +00:00
Rafael Espindola
af690f509a Move the point in the code where we handle -fvisibility=hidden. With
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
2012-04-19 02:55:01 +00:00
Rafael Espindola
7a5543dbff Make setVisibility private and change users to mergeVisibility. This is
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
2012-04-19 02:22:07 +00:00
Rafael Espindola
12b785e8bb Calling setVisibility directly only makes (some) sense when the visibility is
explicit.

llvm-svn: 154969
2012-04-18 00:14:58 +00:00
Rafael Espindola
2dd5ed5e5f Simplify calls to mergeVisibility* by passing in the LinkageInfo. No
functionality change.

llvm-svn: 154940
2012-04-17 18:47:20 +00:00
Rafael Espindola
78158af59c Revert r154749 for now at John McCall's request.
llvm-svn: 154846
2012-04-16 18:46:26 +00:00
Rafael Espindola
505a7c818d Use ordering and the explicit visibility bit instead of modifying
ConsiderGlobalVisibility. No functionality change.

llvm-svn: 154843
2012-04-16 18:25:01 +00:00
Rafael Espindola
9d2874033d Add another constructor to LVFlags and use it to simplify the code a bit.
llvm-svn: 154814
2012-04-16 13:44:41 +00:00
Rafael Espindola
0aec8ece52 Consider visibility attributes last, so that they take precedence.
I am working on a cleaner fix, but this gets the case in PR12552 passing.

llvm-svn: 154749
2012-04-14 15:21:19 +00:00
Douglas Gregor
ce9978ff1f When we form a new function/class template specialization, we first
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
2012-03-28 14:34:23 +00:00
Douglas Gregor
78254c8880 Introduce a new libclang API to determine the parent context of a code
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
2012-03-27 23:34:16 +00:00
Richard Smith
7d137e3b98 Support for definitions of member enumerations of class templates outside the
class template's definition, and for explicit specializations of such enum
members.

llvm-svn: 153304
2012-03-23 03:33:32 +00:00
Richard Smith
4b38ded66a Instantiating a class template should not instantiate the definition of any
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
2012-03-14 23:13:10 +00:00
David Blaikie
bbafb8a745 Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".

Reviewed by Chris Lattner

llvm-svn: 152536
2012-03-11 07:00:24 +00:00
Rafael Espindola
1f71a23985 The type of a definition should not increase its visibility. Fixes PR12221.
llvm-svn: 152493
2012-03-10 13:01:40 +00:00