summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST/Decl.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* In Sema::MergeVarDecl we handle merging of storage classes and visibilityRafael Espindola2012-11-121-25/+6
| | | | | | | | | | | | | | attributes. In cases where the merged declaration is fully equivalent to the two original ones, some of the code was getLVForDecl was duplicated. Cases that are still handled in getLVForDecl are things like __private_extern__ int N; int N; For which we cannot produce a single merged decl with all the information. llvm-svn: 167703
* Fix indentation.Eli Friedman2012-10-261-2/+2
| | | | llvm-svn: 166830
* DR1511: A const volatile global does not implicitly get internal linkage like aRichard Smith2012-10-191-5/+5
| | | | | | const non-volatile global does. llvm-svn: 166269
* Make -mms-bitfields behave consistently.Eli Friedman2012-10-121-1/+8
| | | | | | Patch by Jeremiah Zanin. llvm-svn: 165849
* Handle gnu_inline in c++ in a gcc compatible way. Original patch by TobiasRafael Espindola2012-10-111-1/+1
| | | | | | Grosser. llvm-svn: 165720
* In VarDecl::getSourceRange() make sure to check that the source locationArgyrios Kyrtzidis2012-10-081-2/+5
| | | | | | | | | | 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
* Fix the AST representation for non-type template arguments to encodeEli Friedman2012-09-261-6/+6
| | | | | | | | | | | | 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
* [PCH] When loading fields from external storage make sure to alsoArgyrios Kyrtzidis2012-09-101-2/+7
| | | | | | | | | | | 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
* Switch a couple getAs uses to castAs.Eli Friedman2012-08-301-2/+2
| | | | llvm-svn: 162948
* Consider the visibility of template template arguments. GCC doesn't, but it alsoRafael Espindola2012-07-311-0/+4
| | | | | | fails to consider the linkage, which we were already considering. llvm-svn: 161070
* Fix a typo (the the => the)Sylvestre Ledru2012-07-231-1/+1
| | | | llvm-svn: 160622
* Move option test earlier in the function.Rafael Espindola2012-07-131-3/+2
| | | | llvm-svn: 160202
* Use -fvisibility-inlines-hidden in inline functions too. This matches gccRafael Espindola2012-07-131-29/+42
| | | | | | behavior since gcc pr30066. Thanks to Benjamin Kramer for pointing it out. llvm-svn: 160174
* Fix a bug in my previous commit. The problem is not that we were not using theRafael Espindola2012-07-131-4/+2
| | | | | | | canonical decl for the template, but that we were not merging attributes for templates at all! llvm-svn: 160157
* Use the canonical template decl when trying to find if it has a visibilityRafael Espindola2012-07-121-2/+4
| | | | | | attribute. llvm-svn: 160139
* Reintroduced FieldDecl public methods setBitWidth and removeBitWidth.Abramo Bagnara2012-07-021-0/+6
| | | | llvm-svn: 159579
* We were computing the visibility and linkage of template parameters, butRafael Espindola2012-06-111-4/+4
| | | | | | | | | 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
* PR13064: Store whether an in-class initializer uses direct or copyRichard Smith2012-06-101-5/+4
| | | | | | | initialization, and use that information to produce the right kind of initialization during template instantiation. llvm-svn: 158288
* PR13051: If a constructor is explicitly defaulted, it isn't marked as beingRichard Smith2012-06-081-0/+7
| | | | | | | | | | | | 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
* Revert Decl's iterators back to pointer value_type rather than reference ↵David Blaikie2012-06-061-2/+2
| | | | | | | | | | | | | | 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
* Don't ignore linkage when ignoring visibility in the instantiation of aRafael Espindola2012-05-251-4/+12
| | | | | | method template. llvm-svn: 157486
* Don't ignore linkage when ignoring visibility in the instantiation of aRafael Espindola2012-05-251-8/+12
| | | | | | function template. llvm-svn: 157480
* Consider the linkage for member class templates even when we have to ignoreRafael Espindola2012-05-251-6/+14
| | | | | | the visibility. llvm-svn: 157475
* When ignoring visibility in an instantiation, still consider the linkage.Rafael Espindola2012-05-251-10/+16
| | | | | | | Similar fixes for function and member template to follow as I write the testcases. llvm-svn: 157470
* Whitespace fixes.Rafael Espindola2012-05-251-5/+4
| | | | llvm-svn: 157469
* Function template version of the previous patch.Rafael Espindola2012-05-211-4/+5
| | | | llvm-svn: 157207
* Produce a hidden symbol for zed inRafael Espindola2012-05-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix the visibility of instantiations of static data members.Rafael Espindola2012-05-161-2/+12
| | | | | | Fixes pr12835. llvm-svn: 156897
* Fix our handling of visibility in explicit template instantiations.Rafael Espindola2012-05-151-9/+7
| | | | | | | | | | | | | | | | | | | | | | | | | * 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
* Use raw_ostream in TypePrinter and eliminate uses of temporary std::strings.Argyrios Kyrtzidis2012-05-051-3/+1
| | | | | | Part of rdar://10796159 llvm-svn: 156228
* Remove the ref/value inconsistency in filter_decl_iterator.David Blaikie2012-04-301-3/+3
| | | | | | | | | | | | | 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
* Fix visibility when we have two types with explicit visibility in a templateRafael Espindola2012-04-231-3/+3
| | | | | | argument list. llvm-svn: 155368
* Inline helper function into only caller.Rafael Espindola2012-04-231-1/+1
| | | | llvm-svn: 155352
* An attribute in a explicit template installation should take precedence overRafael Espindola2012-04-221-2/+2
| | | | | | | | | | | 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
* Fix handling of template parameters. Found by inspection. GCC 4.7 agreesRafael Espindola2012-04-221-3/+1
| | | | | | with this testcase. llvm-svn: 155301
* All the members of LVFlags always have the same value, replace the class withRafael Espindola2012-04-211-68/+46
| | | | | | a boolean. llvm-svn: 155299
* In mergeVisibility, if we already have an explicit visibility, keep it.Rafael Espindola2012-04-191-7/+11
| | | | | | | | 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
* Now that we check visibility attributes in an appropriate order,Rafael Espindola2012-04-191-1/+1
| | | | | | | | | | | | | | | | | | 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
* Check ConsiderGlobalVisibility before using -fvisibility.Rafael Espindola2012-04-191-2/+4
| | | | llvm-svn: 155100
* The explicit bit in LV already tracks exactly the same information asRafael Espindola2012-04-191-6/+2
| | | | | | DHasExplicitVisibility. Simplify the code a bit. llvm-svn: 155099
* Move the point in the code where we handle -fvisibility=hidden. WithRafael Espindola2012-04-191-2/+4
| | | | | | | | | | | | 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
* Make setVisibility private and change users to mergeVisibility. This isRafael Espindola2012-04-191-7/+7
| | | | | | | | 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
* Calling setVisibility directly only makes (some) sense when the visibility isRafael Espindola2012-04-181-3/+3
| | | | | | explicit. llvm-svn: 154969
* Simplify calls to mergeVisibility* by passing in the LinkageInfo. NoRafael Espindola2012-04-171-3/+2
| | | | | | functionality change. llvm-svn: 154940
* Revert r154749 for now at John McCall's request.Rafael Espindola2012-04-161-19/+19
| | | | llvm-svn: 154846
* Use ordering and the explicit visibility bit instead of modifyingRafael Espindola2012-04-161-44/+36
| | | | | | ConsiderGlobalVisibility. No functionality change. llvm-svn: 154843
* Add another constructor to LVFlags and use it to simplify the code a bit.Rafael Espindola2012-04-161-18/+10
| | | | llvm-svn: 154814
* Consider visibility attributes last, so that they take precedence.Rafael Espindola2012-04-141-21/+21
| | | | | | I am working on a cleaner fix, but this gets the case in PR12552 passing. llvm-svn: 154749
* When we form a new function/class template specialization, we firstDouglas Gregor2012-03-281-16/+1
| | | | | | | | | | | 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
* Introduce a new libclang API to determine the parent context of a codeDouglas Gregor2012-03-271-1/+1
| | | | | | | | | 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
OpenPOWER on IntegriCloud