This reflects the fact that the attribute's only for compiler-internal use, and isn't really equivalent to C's asm attribute, since it doesn't change the calling convention to be C-compatible.
This came out of today's language review meeting.
The intent is to match #available with the attribute
that describes availability.
This is a divergence from Objective-C.
Swift SVN r28484
Modules occupy a weird space in the AST now: they can be treated like
types (Swift.Int), which is captured by ModuleType. They can be
treated like values for disambiguation (Swift.print), which is
captured by ModuleExpr. And we jump through hoops in various places to
store "either a module or a decl".
Start cleaning this up by transforming Module into ModuleDecl, a
TypeDecl that's implicitly created to describe a module. Subsequent
changes will start folding away the special cases (ModuleExpr ->
DeclRefExpr, name lookup results stop having a separate Module case,
etc.).
Note that the Module -> ModuleDecl typedef is there to limit the
changes needed. Much of this patch is actually dealing with the fact
that Module used to have Ctx and Name public members that now need to
be accessed via getASTContext() and getName(), respectively.
Swift SVN r28284
Rather than swizzle the superclass of these bridging classes at +load time, have the compiler set their ObjC runtime base classes, using a "@_swift_native_objc_runtime_base" attribute that tells the compiler to use a different implicit base class from SwiftObject. This lets the runtime shed its last lingering +loads, and should overall be more robust, since it doesn't rely on static initialization order or deprecated ObjC runtime calls.
Swift SVN r28219
@warn_unused_result can be attached to function declarations to
produce a warning if the function is called but its result is not
used. It has two optional parameters that can be placed in
parentheses:
message="some message": a message to include with the warning.
mutable_variant="somedecl": the name of the mutable variant of the
method that should be suggested when the subject method is called on
a mutable value.
The specific use we're implementing this for now is for the mutating
and in-place operations. For example:
@warn_unused_result(mutable_variant="sortInPlace") func sort() -> [Generator.Element] { ... }
mutating func sortInPlace() { ... }
Translate Clang's __attribute__((warn_unused_result)) into
@warn_unused_result.
Implements rdar://problem/18165189.
Swift SVN r28019
Allow an unversioned 'deprecated' attribute to specify unconditional
deprecation of an API, e.g.,
@availability(*, deprecated, message="sorry")
func foo() { }
Also support platform-specific deprecation, e.g.,
@availability(iOS, deprecated, message="don't use this on iOS")
func bar() { }
Addresses rdar://problem/20562871.
Swift SVN r27355
Allow an unversioned 'deprecated' attribute to specify unconditional
deprecation of an API, e.g.,
@availability(*, deprecated, message="sorry")
func foo() { }
Also support platform-specific deprecation, e.g.,
@availability(iOS, deprecated, message="don't use this on iOS")
func bar() { }
Addresses rdar://problem/20562871.
Swift SVN r27339
This is an internal-only affordance for the numerics team to be able to work on SIMD-compatible types. For now, it can only increase alignment of fixed-layout structs and enums; dynamic layout, classes, and other obvious extensions are left to another day when we can design a proper layout control design.
Swift SVN r27323
This is new attribute we're using to coalesce @thin, @objc_block, and @cc, and to extend to new uses like C function pointer types. Parse the new attribute, but preserve support for the old attributes, and print with the old attributes for now to separate out test changes. Migration fixits and test updates to come. I did take the opportunity here to kill off the '@cc(cdecl)' hack for AST-level function pointer types, which are now only spelt with @convention(c).
Swift SVN r27247
These aren't really orthogonal concerns--you'll never have a @thick @cc(objc_method), or an @objc_block @cc(witness_method)--and we have gross decision trees all over the codebase that try to hopscotch between the subset of combinations that make sense. Stop the madness by eliminating AbstractCC and folding its states into SILFunctionTypeRepresentation. This cleans up a ton of code across the compiler.
I couldn't quite eliminate AbstractCC's information from AST function types, since SIL type lowering transiently created AnyFunctionTypes with AbstractCCs set, even though these never occur at the source level. To accommodate type lowering, allow AnyFunctionType::ExtInfo to carry a SILFunctionTypeRepresentation, and arrange for the overlapping representations to share raw values.
In order to avoid disturbing test output, AST and SILFunctionTypes are still printed and parsed using the existing @thin/@thick/@objc_block and @cc() attributes, which is kind of gross, but lets me stage in the real source-breaking change separately.
Swift SVN r27095
This is the new and improved version of
__attribute__((annotate("swift1_unavailable"))), with the "improved" being
specifically that the 'availability' attribute supports a message.
This requires a corresponding Clang commit.
Swift side of rdar://problem/18768673.
Swift SVN r27053
Rename 'assignment' attribute of infix operators to 'mutating'. Add
'has_assignment' attribute, which results in an implicit declaration of
the assignment version of the same operator. Parse "func =foo"
declaration and "foo.=bar" expression. Validate some basic properties of
in-place methods.
Not yet implemented: automatic generation of wrapper for =foo() if foo()
is implemented, or vice versa; likewise for operators.
Swift SVN r26508
This lets us tag imported declarations with arbitrary synthesized
protocols. Use it to handle imported raw option sets as well as the
RawRepresentable conformances of enums that come in as structs.
Swift SVN r26298
necessary. Wrap forced optional fixit in parens if necessary.
<rdar://problem/20029786> Swift compiler sometimes suggests changing "as!" to "as?!"
Swift SVN r26189
auto-completing @attributes. By delaying the handling of code completion token after the entire decl being parsed, we know
what are the targets of the attribute to finishe, thus, only suggesting those applicable attributes.
Swift SVN r25938
context-sensitive. The first step is to recommend parameter-applicable
attributes only when the code completion token is found inside a
param decl.
Swift SVN r25810
Emit a warning when the developer uses an API that has been marked deprecated with an
availability attribute. Following the Clang behavior, we will only warn if the API is
deprecated on all deployment targets. For example, if an API is deprecated as of
OS X 10.11 but the minimum deployment target is 10.10 then no warning will be emitted.
rdar://problem/17406050
Swift SVN r25288
If appending 'as T' to an expression in a fixit, also suggest
parentheses around the resulting expression if it would otherwise be
parsed incorrectly.
Swift SVN r25168
Attributes @__objc_bridged, @__raw_doc_comment and @__accessibility are not supposed to be
coming from input file and actually crash parseNewDeclAttribute(…) when they are.
Swift SVN r24697
@objc methods, initializers, deinitializers, properties, and
subscripts all produce Objective-C methods. Diagnose cases where two
such entities (which may be of different kinds) produce the same
Objective-C method in the same class.
As a special exception, one can have an Objective-C method in an
extension that conflicts with an Objective-C method in the original
class definition, so long as the original class definition is from a
different model. This reflects the reality in Objective-C that the
category definition wins over the original definition, and is used in
at least one overlay (SpriteKit).
This is the first part of rdar://problem/18391046; the second part
involves checking that overrides are sane.
Swift SVN r23147
llvm::Optional lives in "llvm/ADT/Optional.h". Like Clang, we can get
Optional in the 'swift' namespace by including "swift/Basic/LLVM.h".
We're now fully switched over to llvm::Optional!
Swift SVN r22477
This lets us reliably print and parse opened archetypes across different compiler invocations. Using a source-related locator would be ideal, but that's complicated by the need to manufacture, print, and parse these things during SIL passes, so cop out and burn a UUID for now.
Swift SVN r22385
This will let the performance inliner inline a function even if the costs are too high.
This attribute is only a hint to the inliner.
If the inliner has other good reasons not to inline a function,
it will ignore this attribute. For example if it is a recursive function (which is
currently not supported by the inliner).
Note that setting the inline threshold to 0 does disable performance inlining at all and in
this case also the @inline(__always) has no effect.
Swift SVN r21452
Introduce an attribute that describes when a given CF type is
toll-free-bridged to an Objective-C class, and which class that
is. Use that information in the type checker to provide the CF <->
Objective-C toll-free-bridged conversions directly, rather than using
the user-defined conversion machinery.
Swift SVN r21376
This disables inlining at the SIL level. LLVM inlining is still enabled. We can
use this to expose one function at the SIL level - which can participate in
dominance based optimizations but which is implemented in terms of a cheap check
and an expensive check (function call) that benefits from LLVM's inlining.
Example:
The inline(late) in the example below prevents inlining of the two checks. We
can now perform dominance based optimizations on isClassOrObjExistential.
Without blocking inlining the optimizations would apply to the sizeof check
only and we would have multiple expensive function calls.
@inline(late)
func isClassOrObjExistential(t: Type) -> Bool{
return sizeof(t) == sizeof(AnyObject) &&
swift_isClassOrObjExistential(t)
}
We do want inlining of this function to happen at the LLVM level because the
first check is constant folded away - IRGen replaces sizeof by constants.
rdar://17961249
Swift SVN r21286
