This non-user-facing attribute is used to denote pointer parameters
which do not accept pointers produced from temporary pointer conversions
such as array-to-pointer, string-to-pointer, and in some cases
inout-to-pointer.
Some diagnostics got worse, but I think the reduction in compiler complexity
is worth it, and copy-and-pasting Swift 2 code is not likely to produce great
results anyway.
Also, this corrects an oversight where we did not reject @pseudogeneric on
function types in AST parsing.
Unlike weak values of optional type, an unowned or unowned(unsafe)
value of optional type will not silently become 'nil' when the
referenced instance goes away: rather, the program will trap. Don't
reject unowned or unowned(unsafe) optional lets.
Fixes rdar://problem/45732251.
Previously we only permitted it on the accessor itself, but there is
no reason not to allow it on the storage declaration.
Fixes <https://bugs.swift.org/browse/SR-3624> / <rdar://problem/31865137>.
By formalizing ReferenceOwnership as a diagnostic argument kind, we get
less boilerplate, better type safety, better output consistency, and
last but not least: future proofing.
When performing a binding/assignment to a weak or unowned variable/property from an initialiser call, emit a warning that the instance will be immediately deallocated.
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
