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/internal_linkage.c

28 lines
2.0 KiB
C
Raw Normal View History

Add a C2x spelling for the external_source_symbol and internal_linkage attributes in the clang vendor namespace. Both of these attributes have existing meaning in C code, so there was no reason to exclude them from using the new spelling. llvm-svn: 326053
2018-02-25 22:43:45 +08:00
// RUN: %clang_cc1 -fsyntax-only -verify -fdouble-square-bracket-attributes %s
Implement __attribute__((internal_linkage)). The attrubite is applicable to functions and variables and changes the linkage of the subject to internal. This is the same functionality as C-style "static", but applicable to class methods; and the same as anonymouns namespaces, but can apply to individual methods of a class. Following the proposal in http://lists.llvm.org/pipermail/cfe-dev/2015-October/045580.html llvm-svn: 252648
2015-11-11 05:28:44 +08:00
int var __attribute__((internal_linkage));
Append new attributes to the end of an AttributeList. ... 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, and therefore printed in the wrong order by -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 effects, especially for 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 attribute's order was changed instead. It also causes some 'previous occurrence here' hints to be textually after the main marker. This typically happens when attributes are merged, but are incompatible. 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 reversed. 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, which often is on the same line. Differential Revision: https://reviews.llvm.org/D48100 llvm-svn: 335084
2018-06-20 07:46:52 +08:00
int var2 __attribute__((internal_linkage,common)); // expected-error{{'common' and 'internal_linkage' attributes are not compatible}} \
Implement __attribute__((internal_linkage)). The attrubite is applicable to functions and variables and changes the linkage of the subject to internal. This is the same functionality as C-style "static", but applicable to class methods; and the same as anonymouns namespaces, but can apply to individual methods of a class. Following the proposal in http://lists.llvm.org/pipermail/cfe-dev/2015-October/045580.html llvm-svn: 252648
2015-11-11 05:28:44 +08:00
// expected-note{{conflicting attribute is here}}
Append new attributes to the end of an AttributeList. ... 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, and therefore printed in the wrong order by -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 effects, especially for 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 attribute's order was changed instead. It also causes some 'previous occurrence here' hints to be textually after the main marker. This typically happens when attributes are merged, but are incompatible. 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 reversed. 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, which often is on the same line. Differential Revision: https://reviews.llvm.org/D48100 llvm-svn: 335084
2018-06-20 07:46:52 +08:00
int var3 __attribute__((common,internal_linkage)); // expected-error{{'internal_linkage' and 'common' attributes are not compatible}} \
Implement __attribute__((internal_linkage)). The attrubite is applicable to functions and variables and changes the linkage of the subject to internal. This is the same functionality as C-style "static", but applicable to class methods; and the same as anonymouns namespaces, but can apply to individual methods of a class. Following the proposal in http://lists.llvm.org/pipermail/cfe-dev/2015-October/045580.html llvm-svn: 252648
2015-11-11 05:28:44 +08:00
// expected-note{{conflicting attribute is here}}
int var4 __attribute__((common)); // expected-error{{'common' and 'internal_linkage' attributes are not compatible}} \
// expected-note{{previous definition is here}}
int var4 __attribute__((internal_linkage)); // expected-note{{conflicting attribute is here}} \
// expected-error{{'internal_linkage' attribute does not appear on the first declaration of 'var4'}}
int var5 __attribute__((internal_linkage)); // expected-error{{'internal_linkage' and 'common' attributes are not compatible}}
int var5 __attribute__((common)); // expected-note{{conflicting attribute is here}}
__attribute__((internal_linkage)) int f() {}
Determine the attribute subject for diagnostics based on declarative information in DeclNodes.td. This greatly reduces the number of enumerated values used for more complex diagnostics; these are now only required when the "attribute only applies to" diagnostic needs to be generated manually as part of semantic processing. This also clarifies some terminology used by the diagnostic (methods -> Objective-C methods, fields -> non-static data members, etc). Many of the tests needed to be updated in multiple places for the diagnostic wording tweaks. The first instance of the diagnostic for that attribute is fully specified and subsequent instances cut off the complete list (to make it easier if additional subjects are added in the future for the attribute). llvm-svn: 319002
2017-11-27 04:01:12 +08:00
struct __attribute__((internal_linkage)) S { // expected-warning{{'internal_linkage' attribute only applies to variables, functions, and classes}}
Implement __attribute__((internal_linkage)). The attrubite is applicable to functions and variables and changes the linkage of the subject to internal. This is the same functionality as C-style "static", but applicable to class methods; and the same as anonymouns namespaces, but can apply to individual methods of a class. Following the proposal in http://lists.llvm.org/pipermail/cfe-dev/2015-October/045580.html llvm-svn: 252648
2015-11-11 05:28:44 +08:00
};
__attribute__((internal_linkage("foo"))) int g() {} // expected-error{{'internal_linkage' attribute takes no arguments}}
Add a C2x spelling for the external_source_symbol and internal_linkage attributes in the clang vendor namespace. Both of these attributes have existing meaning in C code, so there was no reason to exclude them from using the new spelling. llvm-svn: 326053
2018-02-25 22:43:45 +08:00
int var6 [[clang::internal_linkage]];
int var7 [[clang::internal_linkage]] __attribute__((common)); // expected-error{{'internal_linkage' and 'common' attributes are not compatible}} \
// expected-note{{conflicting attribute is here}}
__attribute__((common)) int var8 [[clang::internal_linkage]]; // expected-error{{'internal_linkage' and 'common' attributes are not compatible}} \
// expected-note{{conflicting attribute is here}}