maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Sema/attr-visibility.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

29 lines
1.7 KiB
C
Raw Normal View History

Complain about attempts to use 'protected' visibility on targets like Darwin that don't support it. We should also complain about invalid -fvisibility=protected, but that information doesn't seem to exist at the most appropriate time, so I've left a FIXME behind. llvm-svn: 149186
2012-01-29 09:20:30 +08:00
// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify %s
void test0() __attribute__((visibility("default")));
void test1() __attribute__((visibility("hidden")));
void test2() __attribute__((visibility("internal")));
// rdar://problem/10753392
void test3() __attribute__((visibility("protected"))); // expected-warning {{target does not support 'protected' visibility; using 'default'}}
Reject cases like struct __attribute__((visibility("hidden"))) a; struct __attribute__((visibility("default"))) b; which gcc already rejects. llvm-svn: 155603
2012-04-26 09:26:03 +08:00
struct __attribute__((visibility("hidden"))) test4; // expected-note {{previous attribute is here}}
Extend the error about incompatible visibility attributes in different decls to work on function templates specializations. llvm-svn: 155943
2012-05-02 04:58:29 +08:00
struct test4;
Reject cases like struct __attribute__((visibility("hidden"))) a; struct __attribute__((visibility("default"))) b; which gcc already rejects. llvm-svn: 155603
2012-04-26 09:26:03 +08:00
struct __attribute__((visibility("default"))) test4; // expected-error {{visibility does not match previous declaration}}
Walk the decls looking for the last one that has an attribute. We do have to walk them, otherwise we cannot produce an error for both struct HIDDEN test4; // canonical struct test4; struct DEFAULT test4; and struct test5; // canonical struct HIDDEN test5; struct DEFAULT test5; llvm-svn: 156016
2012-05-03 04:36:57 +08:00
struct test5;
struct __attribute__((visibility("hidden"))) test5; // expected-note {{previous attribute is here}}
struct __attribute__((visibility("default"))) test5; // expected-error {{visibility does not match previous declaration}}
Process attributes in the order they appear in the source code. This make clang match gcc behavior for two conflicting visibilities in the same decl. It also makes handling of dllimport/dllexport more natural. As a bonus we now warn on the dllimport in void __attribute__((dllimport)) foo13(); void __attribute__((dllexport)) foo13(); as does gcc. llvm-svn: 156343
2012-05-08 07:58:18 +08:00
Append new attributes to the end of an AttributeList. Recommit of r335084 after revert in r335516. ... instead of prepending it at the beginning (the original behavior since implemented in r122535 2010-12-23). This builds up an AttributeList in the the order in which the attributes appear in the source. The reverse order caused nodes for attributes in the AST (e.g. LoopHint) to be in the reverse order, and therefore printed in the wrong order in -ast-dump. Some TODO comments mention this. The order was explicitly reversed for enable_if attribute overload resolution and name mangling, which is not necessary anymore with this patch. The change unfortunately has some secondary effect, especially on diagnostic output. In the simplest cases, the CHECK lines or expected diagnostic were changed to the the new output. If the kind of error/warning changed, the attributes' order was changed instead. This unfortunately causes some 'previous occurrence here' hints to be textually after the main marker. This typically happens when attributes are merged, but are incompatible to each other. Interchanging the role of the the main and note SourceLocation will also cause the case where two different declaration's attributes (in contrast to multiple attributes of the same declaration) are merged to be reverse. There is no easy fix because sometimes previous attributes are merged into a new declaration's attribute list, sometimes new attributes are added to a previous declaration's attribute list. Since 'previous occurrence here' pointing to locations after the main marker is not rare, I left the markers as-is; it is only relevant when the attributes are declared in the same declaration anyway. Differential Revision: https://reviews.llvm.org/D48100 llvm-svn: 338800
2018-08-03 09:21:16 +08:00
void test6() __attribute__((visibility("default"), // expected-error {{visibility does not match previous declaration}}
visibility("hidden"))); // expected-note {{previous attribute is here}}
Fix an old (2009) FIXME: // FIXME: This needs to happen before we merge declarations. Then, // let attribute merging cope with attribute conflicts. This was already being done for variables, but for functions we were merging then first and then applying the attributes. To avoid duplicating merging logic, some of the helpers in SemaDeclAttr.cpp become methods that can handle merging two attributes in one decl or inheriting attributes from one decl to another. With this change we are now able to produce errors for variables with incompatible visibility attributes or warn about unused dllimports in variables. This changes the attribute list iteration back to being in reverse source code order, as that matches what decl merging does and avoids differentiating the two cases is the merge*Attr methods. llvm-svn: 156531
2012-05-10 10:50:16 +08:00
extern int test7 __attribute__((visibility("default"))); // expected-note {{previous attribute is here}}
extern int test7 __attribute__((visibility("hidden"))); // expected-error {{visibility does not match previous declaration}}
Warn about visibility attributes in typedefs. llvm-svn: 156534
2012-05-10 11:01:34 +08:00
Add a new 'type_visibility' attribute to allow users to 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
2013-02-20 09:54:26 +08:00
typedef int __attribute__((visibility("default"))) bar; // expected-warning {{'visibility' attribute ignored}}
int x __attribute__((type_visibility("default"))); // expected-error {{'type_visibility' attribute only applies to types and namespaces}}
Sema: Don't crash on visibility attributes with an identifier argument. PR17105. llvm-svn: 190312
2013-09-09 23:08:57 +08:00
int PR17105 __attribute__((visibility(hidden))); // expected-error {{'visibility' attribute requires a string}}