maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Misc/pragma-attribute-supported-...

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

165 lines
12 KiB
Plaintext
Raw Normal View History

Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// RUN: clang-tblgen -gen-clang-test-pragma-attribute-supported-attributes -I%src_include_dir %src_include_dir/clang/Basic/Attr.td -o - | FileCheck %s
// The number of supported attributes should never go down!
NFC: Make this test kinder on downstream forks Downstream forks that have their own attributes often run into this test failing when a new attribute is added to clang because the number of supported attributes no longer match. This is redundant information for this test, so we can get by without it. rdar://46288577 llvm-svn: 348218
2018-12-04 08:31:31 +08:00
// CHECK: #pragma clang attribute supports the following attributes:
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: AMDGPUFlatWorkGroupSize (SubjectMatchRule_function)
// CHECK-NEXT: AMDGPUNumSGPR (SubjectMatchRule_function)
// CHECK-NEXT: AMDGPUNumVGPR (SubjectMatchRule_function)
// CHECK-NEXT: AMDGPUWavesPerEU (SubjectMatchRule_function)
// CHECK-NEXT: AVRSignal (SubjectMatchRule_function)
// CHECK-NEXT: AbiTag (SubjectMatchRule_record_not_is_union, SubjectMatchRule_variable, SubjectMatchRule_function, SubjectMatchRule_namespace)
[attributes][analyzer] Add annotations for handles. These annotations will be used in an upcomming static analyzer check that finds handle leaks, use after releases, and double releases. Differential Revision: https://reviews.llvm.org/D70469
2019-12-05 08:12:50 +08:00
// CHECK-NEXT: AcquireHandle (SubjectMatchRule_function, SubjectMatchRule_type_alias, SubjectMatchRule_variable_is_parameter)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: Alias (SubjectMatchRule_function, SubjectMatchRule_variable_is_global)
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: AlignValue (SubjectMatchRule_variable, SubjectMatchRule_type_alias)
// CHECK-NEXT: AllocSize (SubjectMatchRule_function)
Add a new flag and attributes to control static destructor registration This commit adds the flag -fno-c++-static-destructors and the attributes [[clang::no_destroy]] and [[clang::always_destroy]]. no_destroy specifies that a specific static or thread duration variable shouldn't have it's destructor registered, and is the default in -fno-c++-static-destructors mode. always_destroy is the opposite, and is the default in -fc++-static-destructors mode. A variable whose destructor is disabled (either because of -fno-c++-static-destructors or [[clang::no_destroy]]) doesn't count as a use of the destructor, so we don't do any access checking or mark it referenced. We also don't emit -Wexit-time-destructors for these variables. rdar://21734598 Differential revision: https://reviews.llvm.org/D50994 llvm-svn: 340306
2018-08-22 01:24:06 +08:00
// CHECK-NEXT: AlwaysDestroy (SubjectMatchRule_variable)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: AlwaysInline (SubjectMatchRule_function)
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: Annotate ()
Adding nocf_check attribute for cf-protection fine tuning The patch adds nocf_check target independent attribute for disabling checks that were enabled by cf-protection flag. The attribute can be appertained to functions and function pointers. Attribute name follows GCC's similar attribute name. Differential Revision: https://reviews.llvm.org/D41880 llvm-svn: 327768
2018-03-17 21:31:35 +08:00
// CHECK-NEXT: AnyX86NoCfCheck (SubjectMatchRule_hasType_functionType)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: ArcWeakrefUnavailable (SubjectMatchRule_objc_interface)
[ARM,CDE] Generalize MVE intrinsics infrastructure to support CDE Summary: This patch generalizes the existing code to support CDE intrinsics which will share some properties with existing MVE intrinsics (some of the intrinsics will be polymorphic and accept/return values of MVE vector types). Specifically the patch: * Adds new tablegen backends -gen-arm-cde-builtin-def, -gen-arm-cde-builtin-codegen, -gen-arm-cde-builtin-sema, -gen-arm-cde-builtin-aliases, -gen-arm-cde-builtin-header based on existing MVE backends. * Renames the '__clang_arm_mve_alias' attribute into '__clang_arm_builtin_alias' (it will be used with CDE intrinsics as well as MVE intrinsics) * Implements semantic checks for the coprocessor argument of the CDE intrinsics as well as the existing coprocessor intrinsics. * Adds one CDE intrinsic __arm_cx1 to test the above changes Reviewers: simon_tatham, MarkMurrayARM, ostannard, dmgreen Reviewed By: simon_tatham Subscribers: sdesmalen, mgorny, kristof.beyls, danielkiss, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D75850
2020-03-10 22:01:42 +08:00
// CHECK-NEXT: ArmBuiltinAlias (SubjectMatchRule_function)
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: AssumeAligned (SubjectMatchRule_objc_method, SubjectMatchRule_function)
Add support for attributes on @implementations in Objective-C We want to make objc_nonlazy_class apply to implementations, but ran into this. There doesn't seem to be any reason that this isn't supported. Differential revision: https://reviews.llvm.org/D60542 llvm-svn: 358200
2019-04-12 01:55:30 +08:00
// CHECK-NEXT: Availability ((SubjectMatchRule_record, SubjectMatchRule_enum, SubjectMatchRule_enum_constant, SubjectMatchRule_field, SubjectMatchRule_function, SubjectMatchRule_namespace, SubjectMatchRule_objc_category, SubjectMatchRule_objc_implementation, SubjectMatchRule_objc_interface, SubjectMatchRule_objc_method, SubjectMatchRule_objc_property, SubjectMatchRule_objc_protocol, SubjectMatchRule_record, SubjectMatchRule_type_alias, SubjectMatchRule_variable))
[BPF] add missing attribute in pragma-attribute-supported-attributes-list.test Add the newly supported BPF specific __attribute__((preserve_access_index) in the pragma-attribute-supported-attributes-list.test.
2019-11-14 00:50:42 +08:00
// CHECK-NEXT: BPFPreserveAccessIndex (SubjectMatchRule_record)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: CFAuditedTransfer (SubjectMatchRule_function)
// CHECK-NEXT: CFConsumed (SubjectMatchRule_variable_is_parameter)
cfi-icall: Allow the jump table to be optionally made non-canonical. The default behavior of Clang's indirect function call checker will replace the address of each CFI-checked function in the output file's symbol table with the address of a jump table entry which will pass CFI checks. We refer to this as making the jump table `canonical`. This property allows code that was not compiled with ``-fsanitize=cfi-icall`` to take a CFI-valid address of a function, but it comes with a couple of caveats that are especially relevant for users of cross-DSO CFI: - There is a performance and code size overhead associated with each exported function, because each such function must have an associated jump table entry, which must be emitted even in the common case where the function is never address-taken anywhere in the program, and must be used even for direct calls between DSOs, in addition to the PLT overhead. - There is no good way to take a CFI-valid address of a function written in assembly or a language not supported by Clang. The reason is that the code generator would need to insert a jump table in order to form a CFI-valid address for assembly functions, but there is no way in general for the code generator to determine the language of the function. This may be possible with LTO in the intra-DSO case, but in the cross-DSO case the only information available is the function declaration. One possible solution is to add a C wrapper for each assembly function, but these wrappers can present a significant maintenance burden for heavy users of assembly in addition to adding runtime overhead. For these reasons, we provide the option of making the jump table non-canonical with the flag ``-fno-sanitize-cfi-canonical-jump-tables``. When the jump table is made non-canonical, symbol table entries point directly to the function body. Any instances of a function's address being taken in C will be replaced with a jump table address. This scheme does have its own caveats, however. It does end up breaking function address equality more aggressively than the default behavior, especially in cross-DSO mode which normally preserves function address equality entirely. Furthermore, it is occasionally necessary for code not compiled with ``-fsanitize=cfi-icall`` to take a function address that is valid for CFI. For example, this is necessary when a function's address is taken by assembly code and then called by CFI-checking C code. The ``__attribute__((cfi_jump_table_canonical))`` attribute may be used to make the jump table entry of a specific function canonical so that the external code will end up taking a address for the function that will pass CFI checks. Fixes PR41972. Differential Revision: https://reviews.llvm.org/D65629 llvm-svn: 368495
2019-08-10 06:31:59 +08:00
// CHECK-NEXT: CFICanonicalJumpTable (SubjectMatchRule_function)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: CFUnknownTransfer (SubjectMatchRule_function)
Implement cpu_dispatch/cpu_specific Multiversioning As documented here: https://software.intel.com/en-us/node/682969 and https://software.intel.com/en-us/node/523346. cpu_dispatch multiversioning is an ICC feature that provides for function multiversioning. This feature is implemented with two attributes: First, cpu_specific, which specifies the individual function versions. Second, cpu_dispatch, which specifies the location of the resolver function and the list of resolvable functions. This is valuable since it provides a mechanism where the resolver's TU can be specified in one location, and the individual implementions each in their own translation units. The goal of this patch is to be source-compatible with ICC, so this implementation diverges from the ICC implementation in a few ways: 1- Linux x86/64 only: This implementation uses ifuncs in order to properly dispatch functions. This is is a valuable performance benefit over the ICC implementation. A future patch will be provided to enable this feature on Windows, but it will obviously more closely fit ICC's implementation. 2- CPU Identification functions: ICC uses a set of custom functions to identify the feature list of the host processor. This patch uses the cpu_supports functionality in order to better align with 'target' multiversioning. 1- cpu_dispatch function def/decl: ICC's cpu_dispatch requires that the function marked cpu_dispatch be an empty definition. This patch supports that as well, however declarations are also permitted, since the linker will solve the issue of multiple emissions. Differential Revision: https://reviews.llvm.org/D47474 llvm-svn: 337552
2018-07-20 22:13:28 +08:00
// CHECK-NEXT: CPUDispatch (SubjectMatchRule_function)
// CHECK-NEXT: CPUSpecific (SubjectMatchRule_function)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: CUDAConstant (SubjectMatchRule_variable)
// CHECK-NEXT: CUDADevice (SubjectMatchRule_function, SubjectMatchRule_variable)
// CHECK-NEXT: CUDAGlobal (SubjectMatchRule_function)
// CHECK-NEXT: CUDAHost (SubjectMatchRule_function)
// CHECK-NEXT: CUDALaunchBounds (SubjectMatchRule_objc_method, SubjectMatchRule_hasType_functionType)
// CHECK-NEXT: CUDAShared (SubjectMatchRule_variable)
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: CXX11NoReturn (SubjectMatchRule_function)
// CHECK-NEXT: CallableWhen (SubjectMatchRule_function_is_member)
Emit !callback metadata and introduce the callback attribute With commit r351627, LLVM gained the ability to apply (existing) IPO optimizations on indirections through callbacks, or transitive calls. The general idea is that we use an abstraction to hide the middle man and represent the callback call in the context of the initial caller. It is described in more detail in the commit message of the LLVM patch r351627, the llvm::AbstractCallSite class description, and the language reference section on callback-metadata. This commit enables clang to emit !callback metadata that is understood by LLVM. It does so in three different cases: 1) For known broker functions declarations that are directly generated, e.g., __kmpc_fork_call for the OpenMP pragma parallel. 2) For known broker functions that are identified by their name and source location through the builtin detection, e.g., pthread_create from the POSIX thread API. 3) For user annotated functions that carry the "callback(callee, ...)" attribute. The attribute has to include the name, or index, of the callback callee and how the passed arguments can be identified (as many as the callback callee has). See the callback attribute documentation for detailed information. Differential Revision: https://reviews.llvm.org/D55483 llvm-svn: 351629
2019-01-19 13:36:54 +08:00
// CHECK-NEXT: Callback (SubjectMatchRule_function)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: Capability (SubjectMatchRule_record, SubjectMatchRule_type_alias)
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: CarriesDependency (SubjectMatchRule_variable_is_parameter, SubjectMatchRule_objc_method, SubjectMatchRule_function)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: Cold (SubjectMatchRule_function)
// CHECK-NEXT: Common (SubjectMatchRule_variable)
[c++20] P1143R2: Add support for the C++20 'constinit' keyword. This is mostly the same as the [[clang::require_constant_initialization]] attribute, but has a couple of additional syntactic and semantic restrictions. In passing, I added a warning for the attribute form being added after we have already seen the initialization of the variable (but before we see the definition); that case previously slipped between the cracks and the attribute was silently ignored. llvm-svn: 370972
2019-09-05 04:30:37 +08:00
// CHECK-NEXT: ConstInit (SubjectMatchRule_variable_is_global)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: Constructor (SubjectMatchRule_function)
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: Consumable (SubjectMatchRule_record)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: ConsumableAutoCast (SubjectMatchRule_record)
// CHECK-NEXT: ConsumableSetOnRead (SubjectMatchRule_record)
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: Convergent (SubjectMatchRule_function)
// CHECK-NEXT: DLLExport (SubjectMatchRule_function, SubjectMatchRule_variable, SubjectMatchRule_record, SubjectMatchRule_objc_interface)
// CHECK-NEXT: DLLImport (SubjectMatchRule_function, SubjectMatchRule_variable, SubjectMatchRule_record, SubjectMatchRule_objc_interface)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: Destructor (SubjectMatchRule_function)
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: DisableTailCalls (SubjectMatchRule_function, SubjectMatchRule_objc_method)
// CHECK-NEXT: EnableIf (SubjectMatchRule_function)
// CHECK-NEXT: EnumExtensibility (SubjectMatchRule_enum)
[clang] Add the exclude_from_explicit_instantiation attribute Summary: This attribute allows excluding a member of a class template from being part of an explicit template instantiation of that class template. This also makes sure that code using such a member will not take for granted that an external instantiation exists in another translation unit. The attribute was discussed on cfe-dev at [1] and is primarily motivated by the removal of always_inline in libc++ to control what's part of the ABI (see links in [1]). [1]: http://lists.llvm.org/pipermail/cfe-dev/2018-August/059024.html rdar://problem/43428125 Reviewers: rsmith Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D51789 llvm-svn: 343790
2018-10-04 23:49:42 +08:00
// CHECK-NEXT: ExcludeFromExplicitInstantiation (SubjectMatchRule_variable, SubjectMatchRule_function, SubjectMatchRule_record)
Add support for attributes on @implementations in Objective-C We want to make objc_nonlazy_class apply to implementations, but ran into this. There doesn't seem to be any reason that this isn't supported. Differential revision: https://reviews.llvm.org/D60542 llvm-svn: 358200
2019-04-12 01:55:30 +08:00
// CHECK-NEXT: ExternalSourceSymbol ((SubjectMatchRule_record, SubjectMatchRule_enum, SubjectMatchRule_enum_constant, SubjectMatchRule_field, SubjectMatchRule_function, SubjectMatchRule_namespace, SubjectMatchRule_objc_category, SubjectMatchRule_objc_implementation, SubjectMatchRule_objc_interface, SubjectMatchRule_objc_method, SubjectMatchRule_objc_property, SubjectMatchRule_objc_protocol, SubjectMatchRule_record, SubjectMatchRule_type_alias, SubjectMatchRule_variable))
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: FlagEnum (SubjectMatchRule_enum)
// CHECK-NEXT: Flatten (SubjectMatchRule_function)
[AttrDocs] Fix build bots: add missing GNUInline pragma to test. llvm-svn: 341002
2018-08-30 08:04:34 +08:00
// CHECK-NEXT: GNUInline (SubjectMatchRule_function)
[HIP] Support attribute hip_pinned_shadow This patch introduces support of hip_pinned_shadow variable for HIP. A hip_pinned_shadow variable is a global variable with attribute hip_pinned_shadow. It has external linkage on device side and has no initializer. It has internal linkage on host side and has initializer or static constructor. It can be accessed in both device code and host code. This allows HIP runtime to implement support of HIP texture reference. Differential Revision: https://reviews.llvm.org/D62738 llvm-svn: 364381
2019-06-26 11:47:37 +08:00
// CHECK-NEXT: HIPPinnedShadow (SubjectMatchRule_variable)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: Hot (SubjectMatchRule_function)
// CHECK-NEXT: IBAction (SubjectMatchRule_objc_method_is_instance)
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: IFunc (SubjectMatchRule_function)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: InitPriority (SubjectMatchRule_variable)
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: InternalLinkage (SubjectMatchRule_variable, SubjectMatchRule_function, SubjectMatchRule_record)
// CHECK-NEXT: LTOVisibilityPublic (SubjectMatchRule_record)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: Lockable (SubjectMatchRule_record)
[attributes] Fix buildbot after r354530. Update the test after adding more attribute subjects. Differential Revision: https://reviews.llvm.org/D58365 llvm-svn: 354531
2019-02-21 08:19:24 +08:00
// CHECK-NEXT: MIGServerRoutine (SubjectMatchRule_function, SubjectMatchRule_objc_method, SubjectMatchRule_block)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: MSStruct (SubjectMatchRule_record)
[mips] Support `micromips` attribute This patch adds support for the `micromips` and `nomicromips` attributes for MIPS targets. Differential revision: https://reviews.llvm.org/D33363 llvm-svn: 303546
2017-05-22 20:47:43 +08:00
// CHECK-NEXT: MicroMips (SubjectMatchRule_function)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: MinSize (SubjectMatchRule_function, SubjectMatchRule_objc_method)
[Builtins][Attributes][X86] Tag all X86 builtins with their required vector width. Add a min_vector_width function attribute and tag all x86 instrinsics with it This is part of an ongoing attempt at making 512 bit vectors illegal in the X86 backend type legalizer due to CPU frequency penalties associated with wide vectors on Skylake Server CPUs. We want the loop vectorizer to be able to emit IR containing wide vectors as intermediate operations in vectorized code and allow these wide vectors to be legalized to 256 bits by the X86 backend even though we are targetting a CPU that supports 512 bit vectors. This is similar to what happens with an AVX2 CPU, the vectorizer can emit wide vectors and the backend will split them. We want this splitting behavior, but still be able to use new Skylake instructions that work on 256-bit vectors and support things like masking and gather/scatter. Of course if the user uses explicit vector code in their source code we need to not split those operations. Especially if they have used any of the 512-bit vector intrinsics from immintrin.h. And we need to make it so that merely using the intrinsics produces the expected code in order to be backwards compatible. To support this goal, this patch adds a new IR function attribute "min-legal-vector-width" that can indicate the need for a minimum vector width to be legal in the backend. We need to ensure this attribute is set to the largest vector width needed by any intrinsics from immintrin.h that the function uses. The inliner will be reponsible for merging this attribute when a function is inlined. We may also need a way to limit inlining in the future as well, but we can discuss that in the future. To make things more complicated, there are two different ways intrinsics are implemented in immintrin.h. Either as an always_inline function containing calls to builtins(can be target specific or target independent) or vector extension code. Or as a macro wrapper around a taget specific builtin. I believe I've removed all cases where the macro was around a target independent builtin. To support the always_inline function case this patch adds attribute((min_vector_width(128))) that can be used to tag these functions with their vector width. All x86 intrinsic functions that operate on vectors have been tagged with this attribute. To support the macro case, all x86 specific builtins have also been tagged with the vector width that they require. Use of any builtin with this property will implicitly increase the min_vector_width of the function that calls it. I've done this as a new property in the attribute string for the builtin rather than basing it on the type string so that we can opt into it on a per builtin basis and avoid any impact to target independent builtins. There will be future work to support vectors passed as function arguments and supporting inline assembly. And whatever else we can find that isn't covered by this patch. Special thanks to Chandler who suggested this direction and reviewed a preview version of this patch. And thanks to Eric Christopher who has had many conversations with me about this issue. Differential Revision: https://reviews.llvm.org/D48617 llvm-svn: 336583
2018-07-10 03:00:16 +08:00
// CHECK-NEXT: MinVectorWidth (SubjectMatchRule_function)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: Mips16 (SubjectMatchRule_function)
[CodeGen][mips] Support `long_call/far/near` attributes This patch adds support for the `long_call`, `far`, and `near` attributes for MIPS targets. The `long_call` and `far` attributes are synonyms. All these attributes override `-mlong-calls` / `-mno-long-calls` command line options for particular function. Differential revision: https://reviews.llvm.org/D35479 llvm-svn: 308667
2017-07-21 04:34:18 +08:00
// CHECK-NEXT: MipsLongCall (SubjectMatchRule_function)
// CHECK-NEXT: MipsShortCall (SubjectMatchRule_function)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: NSConsumed (SubjectMatchRule_variable_is_parameter)
// CHECK-NEXT: NSConsumesSelf (SubjectMatchRule_objc_method)
// CHECK-NEXT: Naked (SubjectMatchRule_function)
[clang] Add no_builtin attribute Summary: This is a follow up on https://reviews.llvm.org/D61634 This patch is simpler and only adds the no_builtin attribute. Reviewers: tejohnson, courbet, theraven, t.p.northover, jdoerfert Subscribers: mgrang, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68028 This is a re-submit after it got reverted in https://reviews.llvm.org/rGbd8791610948 since the breakage doesn't seem to come from this patch.
2019-09-25 17:31:28 +08:00
// CHECK-NEXT: NoBuiltin (SubjectMatchRule_function)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: NoCommon (SubjectMatchRule_variable)
DebugInfo: Add support for 'nodebug' attribute on typedefs and alias templates Seems like a logical extension to me - and of interest because it might help reduce the debug info size of libc++ by applying this attribute to type traits that have a disproportionate debug info cost compared to the benefit (& possibly harm/confusion) they cause users. llvm-svn: 362856
2019-06-08 08:01:21 +08:00
// CHECK-NEXT: NoDebug (SubjectMatchRule_type_alias, SubjectMatchRule_hasType_functionType, SubjectMatchRule_objc_method, SubjectMatchRule_variable_not_is_parameter)
Add a new flag and attributes to control static destructor registration This commit adds the flag -fno-c++-static-destructors and the attributes [[clang::no_destroy]] and [[clang::always_destroy]]. no_destroy specifies that a specific static or thread duration variable shouldn't have it's destructor registered, and is the default in -fno-c++-static-destructors mode. always_destroy is the opposite, and is the default in -fc++-static-destructors mode. A variable whose destructor is disabled (either because of -fno-c++-static-destructors or [[clang::no_destroy]]) doesn't count as a use of the destructor, so we don't do any access checking or mark it referenced. We also don't emit -Wexit-time-destructors for these variables. rdar://21734598 Differential revision: https://reviews.llvm.org/D50994 llvm-svn: 340306
2018-08-22 01:24:06 +08:00
// CHECK-NEXT: NoDestroy (SubjectMatchRule_variable)
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: NoDuplicate (SubjectMatchRule_function)
Add support for attribute 'noescape'. The attribute informs the compiler that the annotated pointer parameter of a function cannot escape and enables IRGen to attach attribute 'nocapture' to parameters that are annotated with the attribute. That is the only optimization that currently takes advantage of 'noescape', but there are other optimizations that will be added later that improves IRGen for ObjC blocks. This recommits r313722, which was reverted in r313725 because clang couldn't build compiler-rt. It failed to build because there were function declarations that were missing 'noescape'. That has been fixed in r313929. rdar://problem/19886775 Differential Revision: https://reviews.llvm.org/D32210 llvm-svn: 313945
2017-09-22 08:41:05 +08:00
// CHECK-NEXT: NoEscape (SubjectMatchRule_variable_is_parameter)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: NoInline (SubjectMatchRule_function)
// CHECK-NEXT: NoInstrumentFunction (SubjectMatchRule_function)
[mips] Support `micromips` attribute This patch adds support for the `micromips` and `nomicromips` attributes for MIPS targets. Differential revision: https://reviews.llvm.org/D33363 llvm-svn: 303546
2017-05-22 20:47:43 +08:00
// CHECK-NEXT: NoMicroMips (SubjectMatchRule_function)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: NoMips16 (SubjectMatchRule_function)
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: NoSanitize (SubjectMatchRule_function, SubjectMatchRule_objc_method, SubjectMatchRule_variable_is_global)
// CHECK-NEXT: NoSanitizeSpecific (SubjectMatchRule_function, SubjectMatchRule_variable_is_global)
[clang][slh] add Clang attr no_speculative_load_hardening Summary: This attribute will allow users to opt specific functions out of speculative load hardening. This compliments the Clang attribute named speculative_load_hardening. When this attribute or the attribute speculative_load_hardening is used in combination with the flags -mno-speculative-load-hardening or -mspeculative-load-hardening, the function level attribute will override the default during LLVM IR generation. For example, in the case, where the flag opposes the function attribute, the function attribute will take precendence. The sticky inlining behavior of the speculative_load_hardening attribute may cause a function with the no_speculative_load_hardening attribute to be tagged with the speculative_load_hardening tag in subsequent compiler phases which is desired behavior since the speculative_load_hardening LLVM attribute is designed to be maximally conservative. If both attributes are specified for a function, then an error will be thrown. Reviewers: chandlerc, echristo, kristof.beyls, aaron.ballman Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D54909 llvm-svn: 351565
2019-01-19 01:20:46 +08:00
// CHECK-NEXT: NoSpeculativeLoadHardening (SubjectMatchRule_function, SubjectMatchRule_objc_method)
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: NoSplitStack (SubjectMatchRule_function)
Update pragma-attribute-supported-attributes-list.test. Update the test to include the new attribute NoStackProtector to fix the build fails. llvm-svn: 331928
2018-05-10 06:05:53 +08:00
// CHECK-NEXT: NoStackProtector (SubjectMatchRule_function)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: NoThreadSafetyAnalysis (SubjectMatchRule_function)
Make NoThrow FunctionLike, make FunctionLike include references, fix prettyprint __declspec(nothrow) should work on function pointers as well as function references, so this changes it to FunctionLike. Additionally, FunctionLike needed to be modified to permit function references. Finally, the TypePrinter didn't properly print the NoThrow exception specifier, so make sure we get that right as well. llvm-svn: 362435
2019-06-04 02:36:33 +08:00
// CHECK-NEXT: NoThrow (SubjectMatchRule_hasType_functionType)
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: NotTailCalled (SubjectMatchRule_function)
[attributes] Add a family of OS_CONSUMED, OS_RETURNS and OS_RETURNS_RETAINED attributes The addition adds three attributes for communicating ownership, analogous to existing NS_ and CF_ attributes. The attributes are meant to be used for communicating ownership of all objects in XNU (Darwin kernel) and all of the kernel modules. The ownership model there is very similar, but still different from the Foundation model, so we think that introducing a new family of attributes is appropriate. The addition required a sizeable refactoring of the existing code for CF_ and NS_ ownership attributes, due to tight coupling and the fact that differentiating between the types was previously done using a boolean. Differential Revision: https://reviews.llvm.org/D54912 llvm-svn: 347947
2018-11-30 10:18:37 +08:00
// CHECK-NEXT: OSConsumed (SubjectMatchRule_variable_is_parameter)
[attributes] Extend os_returns_(not_?)_retained attributes to parameters When applied to out-parameters, the attributes specify the expected lifetime of the written-into object. Additionally, introduce OSReturnsRetainedOn(Non)Zero attributes, which specify that an ownership transfer happens depending on a return code. Differential Revision: https://reviews.llvm.org/D56292 llvm-svn: 350942
2019-01-12 02:02:08 +08:00
// CHECK-NEXT: OSReturnsNotRetained (SubjectMatchRule_function, SubjectMatchRule_objc_method, SubjectMatchRule_objc_property, SubjectMatchRule_variable_is_parameter)
// CHECK-NEXT: OSReturnsRetained (SubjectMatchRule_function, SubjectMatchRule_objc_method, SubjectMatchRule_objc_property, SubjectMatchRule_variable_is_parameter)
// CHECK-NEXT: OSReturnsRetainedOnNonZero (SubjectMatchRule_variable_is_parameter)
// CHECK-NEXT: OSReturnsRetainedOnZero (SubjectMatchRule_variable_is_parameter)
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: ObjCBoxable (SubjectMatchRule_record)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: ObjCBridge (SubjectMatchRule_record, SubjectMatchRule_type_alias)
// CHECK-NEXT: ObjCBridgeMutable (SubjectMatchRule_record)
// CHECK-NEXT: ObjCBridgeRelated (SubjectMatchRule_record)
Add the `objc_class_stub` attribute. Swift requires certain classes to be not just initialized lazily on first use, but actually allocated lazily using information that is only available at runtime. This is incompatible with ObjC class initialization, or at least not efficiently compatible, because there is no meaningful class symbol that can be put in a class-ref variable at load time. This leaves ObjC code unable to access such classes, which is undesirable. objc_class_stub says that class references should be resolved by calling a new ObjC runtime function with a pointer to a new "class stub" structure. Non-ObjC compilers (like Swift) can simply emit this structure when ObjC interop is required for a class that cannot be statically allocated, then apply this attribute to the `@interface` in the generated ObjC header for the class. This attribute can be thought of as a generalization of the existing `objc_runtime_visible` attribute which permits more efficient class resolution as well as supporting the additon of categories to the class. Subclassing these classes from ObjC is currently not allowed. Patch by Slava Pestov! llvm-svn: 362054
2019-05-30 12:09:01 +08:00
// CHECK-NEXT: ObjCClassStub (SubjectMatchRule_objc_interface)
[Sema] Delay checking whether objc_designated_initializer is being applied to an init method This fixes a regression that was caused by r335084, which reversed the order that attributes are applied. objc_method_family can change whether a method is an init method, so the order that these attributes are applied matters. The commit fixes this by delaying the init check until after all attributes have been applied. rdar://47829358 Differential revision: https://reviews.llvm.org/D58152 llvm-svn: 353976
2019-02-14 04:32:37 +08:00
// CHECK-NEXT: ObjCDesignatedInitializer (SubjectMatchRule_objc_method)
Implement __attribute__((objc_direct)), __attribute__((objc_direct_members)) __attribute__((objc_direct)) is an attribute on methods declaration, and __attribute__((objc_direct_members)) on implementation, categories or extensions. A `direct` property specifier is added (@property(direct) type name) These attributes / specifiers cause the method to have no associated Objective-C metadata (for the property or the method itself), and the calling convention to be a direct C function call. The symbol for the method has enforced hidden visibility and such direct calls are hence unreachable cross image. An explicit C function must be made if so desired to wrap them. The implicit `self` and `_cmd` arguments are preserved, however to maintain compatibility with the usual `objc_msgSend` semantics, 3 fundamental precautions are taken: 1) for instance methods, `self` is nil-checked. On arm64 backends this typically adds a single instruction (cbz x0, <closest-ret>) to the codegen, for the vast majority of the cases when the return type is a scalar. 2) for class methods, because the class may not be realized/initialized yet, a call to `[self self]` is emitted. When the proper deployment target is used, this is optimized to `objc_opt_self(self)`. However, long term we might want to emit something better that the optimizer can reason about. When inlining kicks in, these calls aren't optimized away as the optimizer has no idea that a single call is really necessary. 3) the calling convention for the `_cmd` argument is changed: the caller leaves the second argument to the call undefined, and the selector is loaded inside the body when it's referenced only. As far as error reporting goes, the compiler refuses: - making any overloads direct, - making an overload of a direct method, - implementations marked as direct when the declaration in the interface isn't (the other way around is allowed, as the direct attribute is inherited from the declaration), - marking methods required for protocol conformance as direct, - messaging an unqualified `id` with a direct method, - forming any @selector() expression with only direct selectors. As warnings: - any inconsistency of direct-related calling convention when @selector() or messaging is used, - forming any @selector() expression with a possibly direct selector. Lastly an `objc_direct_members` attribute is added that can decorate `@implementation` blocks and causes methods only declared there (and in no `@interface`) to be automatically direct. When decorating an `@interface` then all methods and properties declared in this block are marked direct. Radar-ID: rdar://problem/2684889 Differential Revision: https://reviews.llvm.org/D69991 Reviewed-By: John McCall
2019-11-08 15:14:58 +08:00
// CHECK-NEXT: ObjCDirect (SubjectMatchRule_objc_method)
[objc_direct] Small updates to help with adoption. Add fixits for messaging self in MRR or using super, as the intent is clear, and it turns out people do that a lot more than expected. Allow for objc_direct_members on main interfaces, it's extremely useful for internal only classes, and proves to be quite annoying for adoption. Add some better warnings around properties direct/non-direct clashes (it was done for methods but properties were a miss). Add some errors when direct properties are marked @dynamic. Radar-Id: rdar://problem/58355212 Signed-off-by: Pierre Habouzit <phabouzit@apple.com> Differential Revision: https://reviews.llvm.org/D73755
2020-01-31 08:48:11 +08:00
// CHECK-NEXT: ObjCDirectMembers (SubjectMatchRule_objc_implementation, SubjectMatchRule_objc_interface, SubjectMatchRule_objc_category)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: ObjCException (SubjectMatchRule_objc_interface)
// CHECK-NEXT: ObjCExplicitProtocolImpl (SubjectMatchRule_objc_protocol)
[ObjCARC] Add an new attribute, objc_externally_retained This attribute, called "objc_externally_retained", exposes clang's notion of pseudo-__strong variables in ARC. Pseudo-strong variables "borrow" their initializer, meaning that they don't retain/release it, instead assuming that someone else is keeping their value alive. If a function is annotated with this attribute, implicitly strong parameters of that function aren't implicitly retained/released in the function body, and are implicitly const. This is useful to expose for performance reasons, most functions don't need the extra safety of the retain/release, so programmers can opt out as needed. This attribute can also apply to declarations of local variables, with similar effect. Differential revision: https://reviews.llvm.org/D55865 llvm-svn: 350422
2019-01-05 02:33:06 +08:00
// CHECK-NEXT: ObjCExternallyRetained (SubjectMatchRule_variable_not_is_parameter, SubjectMatchRule_function, SubjectMatchRule_block, SubjectMatchRule_objc_method)
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: ObjCMethodFamily (SubjectMatchRule_objc_method)
Support objc_nonlazy_class attribute on Objective-C implementations Fixes rdar://49523079 Differential revision: https://reviews.llvm.org/D60544 llvm-svn: 358201
2019-04-12 01:55:34 +08:00
// CHECK-NEXT: ObjCNonLazyClass (SubjectMatchRule_objc_interface, SubjectMatchRule_objc_implementation)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: ObjCPreciseLifetime (SubjectMatchRule_variable)
// CHECK-NEXT: ObjCRequiresPropertyDefs (SubjectMatchRule_objc_interface)
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: ObjCRequiresSuper (SubjectMatchRule_objc_method)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: ObjCReturnsInnerPointer (SubjectMatchRule_objc_method, SubjectMatchRule_objc_property)
// CHECK-NEXT: ObjCRootClass (SubjectMatchRule_objc_interface)
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: ObjCRuntimeName (SubjectMatchRule_objc_interface, SubjectMatchRule_objc_protocol)
// CHECK-NEXT: ObjCRuntimeVisible (SubjectMatchRule_objc_interface)
// CHECK-NEXT: ObjCSubclassingRestricted (SubjectMatchRule_objc_interface)
[OpenCL] Add intel_reqd_sub_group_size attribute support Summary: Add intel_reqd_sub_group_size attribute support as intel extension cl_intel_required_subgroup_size from https://www.khronos.org/registry/OpenCL/extensions/intel/cl_intel_required_subgroup_size.txt Reviewers: Anastasia, bader, hfinkel, pxli168 Reviewed By: Anastasia, bader, pxli168 Subscribers: cfe-commits, yaxunl Differential Revision: https://reviews.llvm.org/D30805 llvm-svn: 302125
2017-05-04 15:31:20 +08:00
// CHECK-NEXT: OpenCLIntelReqdSubGroupSize (SubjectMatchRule_function)
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: OpenCLNoSVM (SubjectMatchRule_variable)
// CHECK-NEXT: OptimizeNone (SubjectMatchRule_function, SubjectMatchRule_objc_method)
// CHECK-NEXT: Overloadable (SubjectMatchRule_function)
Add lifetime categories attributes Summary: This is the first part of work announced in "[RFC] Adding lifetime analysis to clang" [0], i.e. the addition of the [[gsl::Owner(T)]] and [[gsl::Pointer(T)]] attributes, which will enable user-defined types to participate in the lifetime analysis (which will be part of the next PR). The type `T` here is called "DerefType" in the paper, and denotes the type that an Owner owns and a Pointer points to. E.g. `std::vector<int>` should be annotated with `[[gsl::Owner(int)]]` and a `std::vector<int>::iterator` with `[[gsl::Pointer(int)]]`. [0] http://lists.llvm.org/pipermail/cfe-dev/2018-November/060355.html Reviewers: gribozavr Subscribers: xazax.hun, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63954 llvm-svn: 367040
2019-07-26 01:50:51 +08:00
// CHECK-NEXT: Owner (SubjectMatchRule_record_not_is_union)
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: ParamTypestate (SubjectMatchRule_variable_is_parameter)
// CHECK-NEXT: PassObjectSize (SubjectMatchRule_variable_is_parameter)
Support function attribute patchable_function_entry This feature is generic. Make it applicable for AArch64 and X86 because the backend has only implemented NOP insertion for AArch64 and X86. Reviewed By: nickdesaulniers, aaron.ballman Differential Revision: https://reviews.llvm.org/D72221
2020-01-05 07:39:19 +08:00
// CHECK-NEXT: PatchableFunctionEntry (SubjectMatchRule_function, SubjectMatchRule_objc_method)
Add lifetime categories attributes Summary: This is the first part of work announced in "[RFC] Adding lifetime analysis to clang" [0], i.e. the addition of the [[gsl::Owner(T)]] and [[gsl::Pointer(T)]] attributes, which will enable user-defined types to participate in the lifetime analysis (which will be part of the next PR). The type `T` here is called "DerefType" in the paper, and denotes the type that an Owner owns and a Pointer points to. E.g. `std::vector<int>` should be annotated with `[[gsl::Owner(int)]]` and a `std::vector<int>::iterator` with `[[gsl::Pointer(int)]]`. [0] http://lists.llvm.org/pipermail/cfe-dev/2018-November/060355.html Reviewers: gribozavr Subscribers: xazax.hun, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63954 llvm-svn: 367040
2019-07-26 01:50:51 +08:00
// CHECK-NEXT: Pointer (SubjectMatchRule_record_not_is_union)
[attributes][analyzer] Add annotations for handles. These annotations will be used in an upcomming static analyzer check that finds handle leaks, use after releases, and double releases. Differential Revision: https://reviews.llvm.org/D70469
2019-12-05 08:12:50 +08:00
// CHECK-NEXT: ReleaseHandle (SubjectMatchRule_variable_is_parameter)
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: RenderScriptKernel (SubjectMatchRule_function)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: ReqdWorkGroupSize (SubjectMatchRule_function)
// CHECK-NEXT: Restrict (SubjectMatchRule_function)
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: ReturnTypestate (SubjectMatchRule_function, SubjectMatchRule_variable_is_parameter)
// CHECK-NEXT: ReturnsNonNull (SubjectMatchRule_objc_method, SubjectMatchRule_function)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: ReturnsTwice (SubjectMatchRule_function)
// CHECK-NEXT: ScopedLockable (SubjectMatchRule_record)
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: Section (SubjectMatchRule_function, SubjectMatchRule_variable_is_global, SubjectMatchRule_objc_method, SubjectMatchRule_objc_property)
// CHECK-NEXT: SetTypestate (SubjectMatchRule_function_is_member)
[clang][slh] add attribute for speculative load hardening Summary: Resubmit this with no changes because I think the build was broken by a different diff. ----- The prior diff had to be reverted because there were two tests that failed. I updated the two tests in this diff clang/test/Misc/pragma-attribute-supported-attributes-list.test clang/test/SemaCXX/attr-speculative-load-hardening.cpp ----- Summary from Previous Diff (Still Accurate) ----- LLVM IR already has an attribute for speculative_load_hardening. Before this commit, when a user passed the -mspeculative-load-hardening flag to Clang, every function would have this attribute added to it. This Clang attribute will allow users to opt into SLH on a function by function basis. This can be applied to functions and Objective C methods. Reviewers: chandlerc, echristo, kristof.beyls, aaron.ballman Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D54915 llvm-svn: 347701
2018-11-28 03:56:46 +08:00
// CHECK-NEXT: SpeculativeLoadHardening (SubjectMatchRule_function, SubjectMatchRule_objc_method)
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: SwiftContext (SubjectMatchRule_variable_is_parameter)
// CHECK-NEXT: SwiftErrorResult (SubjectMatchRule_variable_is_parameter)
// CHECK-NEXT: SwiftIndirectResult (SubjectMatchRule_variable_is_parameter)
// CHECK-NEXT: TLSModel (SubjectMatchRule_variable_is_thread_local)
// CHECK-NEXT: Target (SubjectMatchRule_function)
// CHECK-NEXT: TestTypestate (SubjectMatchRule_function_is_member)
Add support for attribute 'trivial_abi'. The 'trivial_abi' attribute can be applied to a C++ class, struct, or union. It makes special functions of the annotated class (the destructor and copy/move constructors) to be trivial for the purpose of calls and, as a result, enables the annotated class or containing classes to be passed or returned using the C ABI for the underlying type. When a type that is considered trivial for the purpose of calls despite having a non-trivial destructor (which happens only when the class type or one of its subobjects is a 'trivial_abi' class) is passed to a function, the callee is responsible for destroying the object. For more background, see the discussions that took place on the mailing list: http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043 rdar://problem/35204524 Differential Revision: https://reviews.llvm.org/D41039 llvm-svn: 324269
2018-02-06 04:23:22 +08:00
// CHECK-NEXT: TrivialABI (SubjectMatchRule_record)
[attributes][analyzer] Add annotations for handles. These annotations will be used in an upcomming static analyzer check that finds handle leaks, use after releases, and double releases. Differential Revision: https://reviews.llvm.org/D70469
2019-12-05 08:12:50 +08:00
// CHECK-NEXT: UseHandle (SubjectMatchRule_variable_is_parameter)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: VecReturn (SubjectMatchRule_record)
// CHECK-NEXT: VecTypeHint (SubjectMatchRule_function)
// CHECK-NEXT: WarnUnused (SubjectMatchRule_record)
Add #pragma clang attribute This is a recommit of r300539 that was reverted in r300543 due to test failures. The original commit message is displayed below: The new '#pragma clang attribute' directive can be used to apply attributes to multiple declarations. An attribute must satisfy the following conditions to be supported by the pragma: - It must have a subject list that's defined in the TableGen file. - It must be documented. - It must not be late parsed. - It must have a GNU/C++11 spelling. Differential Revision: https://reviews.llvm.org/D30009 llvm-svn: 300556
2017-04-18 22:33:39 +08:00
// CHECK-NEXT: WarnUnusedResult (SubjectMatchRule_objc_method, SubjectMatchRule_enum, SubjectMatchRule_record, SubjectMatchRule_hasType_functionType)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: Weak (SubjectMatchRule_variable, SubjectMatchRule_function, SubjectMatchRule_record)
// CHECK-NEXT: WeakRef (SubjectMatchRule_variable, SubjectMatchRule_function)
[WebAssembly] Add new `export_name` clang attribute for controlling wasm export names This is equivalent to the existing `import_name` and `import_module` attributes which control the import names in the final wasm binary produced by lld. This maps the existing This attribute currently requires a string rather than using the symbol name for a couple of reasons: 1. Avoid confusion with static and dynamic linking which is based on symbol name. Exporting a function from a wasm module using this directive is orthogonal to both static and dynamic linking. 2. Avoids name mangling. Differential Revision: https://reviews.llvm.org/D70520
2019-11-06 02:15:56 +08:00
// CHECK-NEXT: WebAssemblyExportName (SubjectMatchRule_function)
[WebAssembly] Add WebAssemblyImportModule to pragma-attribute-supported-attributes-list.test llvm-svn: 352108
2019-01-25 05:20:03 +08:00
// CHECK-NEXT: WebAssemblyImportModule (SubjectMatchRule_function)
[WebAssembly] Fix ImportName's position in this test. This is a follow-up to r352930. llvm-svn: 352936
2019-02-02 06:52:29 +08:00
// CHECK-NEXT: WebAssemblyImportName (SubjectMatchRule_function)
Allow all supportable non-type attributes to be used with #pragma clang attribute. Summary: We previously disallowed use of undocumented attributes with #pragma clang attribute, but the justification for doing so was weak and it prevented many reasonable use cases. Reviewers: aaron.ballman, arphaman Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington Differential Revision: https://reviews.llvm.org/D51507 llvm-svn: 341437
2018-09-05 08:28:57 +08:00
// CHECK-NEXT: WorkGroupSizeHint (SubjectMatchRule_function)
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
// CHECK-NEXT: XRayInstrument (SubjectMatchRule_function, SubjectMatchRule_objc_method)
// CHECK-NEXT: XRayLogArgs (SubjectMatchRule_function, SubjectMatchRule_objc_method)
NFC: Make this test kinder on downstream forks Downstream forks that have their own attributes often run into this test failing when a new attribute is added to clang because the number of supported attributes no longer match. This is redundant information for this test, so we can get by without it. rdar://46288577 llvm-svn: 348218
2018-12-04 08:31:31 +08:00
// CHECK-NEXT: End of supported attributes.