llvm-project/clang/test/SemaObjC/validate-attr-swift_attr.m

// RUN: %clang_cc1 -verify -fsyntax-only %s

// expected-error@+1 {{'swift_attr' attribute takes one argument}}
__attribute__((swift_attr))
@interface I
@end

// expected-error@+1 {{expected string literal as argument of 'swift_attr' attribute}}
__attribute__((swift_attr(1)))
@interface J
@end

@interface Error<T: __attribute__((swift_attr(1))) id>
// expected-error@-1 {{expected string literal as argument of 'swift_attr' attribute}}
@end
[clang] add a new `swift_attr` attribute The swift_attr attribute is a generic annotation attribute that's not used by clang, but is used by the Swift compiler. The Swift compiler can use these annotations to provide various syntactic and semantic sugars for the imported Objective-C API declarations. Differential Revision: https://reviews.llvm.org/D92354 2020-12-04 09:29:45 -08:00			`// RUN: %clang_cc1 -verify -fsyntax-only %s`

			`// expected-error@+1 {{'swift_attr' attribute takes one argument}}`
			`__attribute__((swift_attr))`
			`@interface I`
			`@end`

Complete the implementation of P2361 Unevaluated string literals The attributes changes were left out of Clang 17. Attributes that used to take a string literal now accept an unevaluated string literal instead, which means they reject numeric escape sequences and strings literal with an encoding prefix - but the later was already ill-formed in most cases. We need to know that we are going to parse an unevaluated string literal before we do - so we can reject numeric escape sequence, so we derive from Attrs.td which attributes parameters are expected to be string literals. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D156237 2021-07-10 15:52:54 +02:00			`// expected-error@+1 {{expected string literal as argument of 'swift_attr' attribute}}`
[clang] add a new `swift_attr` attribute The swift_attr attribute is a generic annotation attribute that's not used by clang, but is used by the Swift compiler. The Swift compiler can use these annotations to provide various syntactic and semantic sugars for the imported Objective-C API declarations. Differential Revision: https://reviews.llvm.org/D92354 2020-12-04 09:29:45 -08:00			`__attribute__((swift_attr(1)))`
			`@interface J`
			`@end`
[clang/AST] Make it possible to use SwiftAttr in type context (#108631) Swift ClangImporter now supports concurrency annotations on imported declarations and their parameters/results, to make it possible to use imported APIs in Swift safely there has to be a way to annotate individual parameters and result types with relevant attributes that indicate that e.g. a block is called on a particular actor or it accepts a `Sendable` parameter. To faciliate that `SwiftAttr` is switched from `InheritableAttr` which is a declaration attribute to `DeclOrTypeAttr`. To support this attribute in type context we need access to its "Attribute" argument which requires `AttributedType` to be extended to include `Attr *` when available instead of just `attr::Kind` otherwise it won't be possible to determine what attribute should be imported. 2024-10-31 04:15:22 -07:00
			`@interface Error<T: __attribute__((swift_attr(1))) id>`
			`// expected-error@-1 {{expected string literal as argument of 'swift_attr' attribute}}`
			`@end`