For now these are underscored attributes, i.e. compiler internal attributes:
@_optimize(speed)
@_optimize(size)
@_optimize(none)
Those attributes override the command-line specified optimization mode for a specific function.
The @_optimize(none) attribute is equivalent to the already existing @_semantics("optimize.sil.never") attribute
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
Rename AccessibilityAttr to AccessControlAttr and
SetterAccessibilityAttr to SetterAccessAttr, then track down the last
few uses of "accessibility" that don't have to do with
NSAccessibility. (I left the SourceKit XPC API alone because that's
supposed to be more stable.)
This also removes some dead code, where an early assert() ensures that
'strong' is never passed into the function, but then the function later
tries to handle 'strong'.
Finally, use a switch statement for future proofing.
Quiz: What does @_transparent on an extension actually *do*?
1) Make all members @_transparent?
2) Allow your members to be @_transparent?
3) Some other magical effect that has nothing to do with members?
The correct answer is 1), however a few places in the stdlib defined
a @_transparent extension and then proceeded to make some or all members
also @_transparent, and in a couple of places we defined a @_transparent
extension with no members at all.
To avoid cargo culting and confusion, remove the ability to make
@_transparent extensions altogether, and force usages to be explicit.
By consuming parens.
As for type attributes, handle `@unknownAttribute(Arg) -> Ret` case.
Improves diagnostic QoI. For example, on:
func foo(x: @unknown(x) Int) {}
Before:
test.swift:1:14: error: unknown attribute 'unknown'
test.swift:1:25: error: expected ',' separator
test.swift:1:25: error: unnamed parameters must be written with the empty name '_'
test.swift:1:22: error: use of undeclared type 'x'
Now, we just emit the first one:
test.swift:1:14: error: unknown attribute 'unknown'
func foo(x: @unknown(x) Int) {}
^
When declaring a nominal type:
struct Weak<T> {
weak var value: T
}
The diagnostic might mislead the developer to adding ': class' literally
to the 'T' in the generic parameters for `Weak`:
"'weak' may not be applied to non-class-bound protocol 'T'; consider
adding a class bound"
This is misleading in two ways: 1, 'T' isn't necessarily a protocol
(this patch generalizes that part of the message) and 2, you can't put
`: class` in the generic parameter list for `Weak`. In addition, the
stray class constraint causes diagnostic spew that also hides the issue.
Also provide a fix-it to constrain with 'AnyObject', which is probably
what the devloper means in this case.
rdar://problem/25481209
At some point I want to propose a revised model for exports, but for now
just mark that support for '@exported' is still experimental and subject
to change. (Thanks, Max.)
Enhance fixItRemove() to be a bit more careful about what whitespace it leaves around: if the thing it is removing has leading and trailing whitespace already, this nukes an extra space to avoid leaving double spaces or incorrectly indented results.
This includes an extra fix for looking off the start of a buffer, which extractText doesn't and can't handle.
This fixes <rdar://problem/21045509> Fixit deletes 'let' from non-binding 'if case let' statements, but leaves an extra space
Swift SVN r29449
if the thing it is removing has leading and trailing whitespace already, this nukes
an extra space to avoid leaving double spaces or incorrectly indented results. This
fixes <rdar://problem/21045509> Fixit deletes 'let' from non-binding 'if case let' statements, but leaves an extra space
Swift SVN r29419
var/let bindings to _ when they are never used, and use some values that
are only written. This is a testsuite cleanup, NFC. More to come.
Swift SVN r28406
If a generic parameter is not referred to from a function signature, it can never be inferred and thus such a function can never be invoked.
We now produce the following error:
generic parameter 'T' is not used in function signature
func f8<T> (x: Int) {}
This commit takes Jordan't comments on r28181 into account:
- it produces a shorter error message
- it does not change the compiler_crashers_fixed test and add a new expected error instead
Swift SVN r28194
If a generic parameter is not referred to from a function signature, it can never be inferred and thus such a function can never be invoked.
We now produce the following error:
There is no way to infer the generic parameter 'T' if it is not used in function signature
func f8<T> (x: Int) {}
^
Swift SVN r28181
We didn't have a consistent way to utter attributes in diagnostics, sometimes saying the
'foo' attribute is not allowed
@foo attribute is not allowed
'foo' is not allowed
@foo is not allowed
etc. Standardize on the last one, since it is clear (with the @ sign, with no quotes, with no
'attribute' word in the diagnostic) that we're talking about an attribute. Move a bunch of
diagnostics inline with this.
Swift SVN r25524
Per discussion with the IB team, a class can retroactively be marked as
designable via an extension (or if not retroactively, at least from elsewhere
in the module). This matches the documentation for Objective-C.
(The attribute still has no semantics in Swift itself. The only restriction
is that it must appear on a class or an extension of a class.)
rdar://problem/19654163
Swift SVN r24837
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
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
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
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
I am trying to enable a new ARC optimizer feature that is forcing me to
debug a test case that is affected by inlining of initializers. Plus, being
able to selectively disable inlining of the initializers is a useful
feature in general.
Swift SVN r20427
them to cover all declaration types.
This ensures that we reject attributes on declkinds where they don't make sense. I went so far
as to make the QoI decent when an attribute can only be applied to a single kind of declaration
to make sure the error message says "@IBAction is only valid on 'func' declarations" as well.
This resolves <rdar://problem/17681151> 'dynamic' accepted by the compiler where it shouldn't be
Swift SVN r19982
This only tackles the protocol case (<rdar://problem/17510790>); it
does not yet generalize to an arbitrary "class" requirement on either
existentials or generics.
Swift SVN r19896
