The id-as-Any work regressed cases where Swift code could specify
heterogeneous collection literals, e.g.,
var states: [String: Any] = [
"California": [
"population": 37_000_000,
"cities": ["Los Angeles", "San Diego", "San Jose"],
],
"Oregon": [
"population": 4_000_000,
"cities": ["Portland", "Salem", "Eugene"],
]
]
Prior to this, the code worked (when Foundation was imported) because
we'd end up with literals of type [NSObject : AnyObject].
The new defaulting rule says that the element type of an array literal
and the key/value types of a dictionary literal can be defaulted if no
stronger type can be inferred. The default type is:
Any, for the element type of an array literal or the value type of a
dictionary literal, or
AnyHashable, for the key type of a dictionary literal.
The latter is intended to compose with implicit conversions to
AnyHashable, so the most-general inferred dictionary type is
[AnyHashable : Any] and will work for any plausible dictionary
literal.
To prevent this inference from diluting types too greatly, we don't
allow this inference in "top-level" expressions, e.g.,
let d = ["a" : 1, "b" : "two"]
will produce an error because it's a heterogeneous dictionary literal
at the top level. One should annotate this with, e.g.,
let d = ["a" : 1, "b" : "two"] as [String : Any]
However, we do permit heterogeneous collections in nested positions,
to support cases like the original motivating example.
Fixes rdar://problem/27661580.
One minor revision: this lifts the proposed restriction against
overriding a non-open method with an open one. On reflection,
that was inconsistent with the existing rule permitting non-public
methods to be overridden with public ones. The restriction on
subclassing a non-open class with an open class remains, and is
in fact consistent with the existing access rule.
Changes diangostic messages from referring specifically to @noescape,
which is going away, to 'non-escaping'. Introduces better diagnostics
and fixits for adding @escaping to closures that escape.
String literal expressions, as well as the magic literals #file and
tuple value that is then fed into one or two call expressions. For
string literals, that tuple value was implicitly splatted, breaking
AST invariants.
Instead, keep string literals and these magic literals that produce a
string as a single expression node, but store the declarations that
will be used to transform the raw literal into the complete
literal. SILGen will form the appropriate calls. This representation
is far simpler---the AST no longer has a bunch of implicit nodes---and
doesn't break AST invariants.
'fileprivate' is considered a broader level of access than 'private',
but for now both of them are still available to the entire file. This
is intended as a migration aid.
One interesting fallout of the "access scope" model described in
758cf64 is that something declared 'private' at file scope is actually
treated as 'fileprivate' for diagnostic purposes. This is something
we can fix later, once the full model is in place. (It's not really
/wrong/ in that they have identical behavior, but diagnostics still
shouldn't refer to a type explicitly declared 'private' as
'fileprivate'.)
As a note, ValueDecl::getEffectiveAccess will always return 'FilePrivate'
rather than 'Private'; for purposes of optimization and code generation,
we should never try to distinguish these two cases.
This should have essentially no effect on code that's /not/ using
'fileprivate' other than altered diagnostics.
Progress on SE-0025 ('fileprivate' and 'private')
pattern matches. In the case of an 'if let' with an explicit type, produce a
Taylor'd diagnostic that rewrites the condition to the right type.
This wraps up:
<rdar://problem/27457457> [Type checker] Diagnose unsavory optional injections
common standard library operators. This is progress towards:
<rdar://problem/27457457> [Type checker] Diagnose unsavory optional injections
but there is more work to be done here.
change includes both the necessary protocol updates and the deprecation
warnings
suitable for migration. A future patch will remove the renamings and
make this
a hard error.
Fix-it suggests normal argument expression, instead of of enclosing whole
expression with parens.
* Moved diagnostic logic to Sema, because we have to add correct argument
label for the closure.
if arr.starts(with: IDs) { $0.id == $2 } { ... }
~~^
, isEquivalent: )
* We now accept trailing closures for each expressions and right before `where`
clause, as well as closures right before the body.
if let _ = maybeInt { 1 }, someOtherCondition { ... }
~^
( )
for let x in arr.map { $0 * 4 } where x != 0 { ... }
~^
( )
* [Fixit] Add a fixit for converting non-trailing closures to trailing closures.
* [test] Update test to reflect the added note about converting to trailing closures.
Reminded by Ben's last commit of code completion, I noticed that some users
do not use trailing closures when helping migrating their code. To enhance the discoverability
of this feature, this fix helps users to convert non-trailing closures to trailing
closures. To ensure disambiguity after conversion, we check name conflict before adding
the note.
In C++ we can't have nice things. The macro name 'defer' collided with
use of 'defer' in the Tokens.def file and we were already doing horrible
workarounds in a couple of places to allow them to be included into the
same file. So use a less awesome but more robust name (thanks to Joe for
suggesting SWIFT_DEFER).
Incidentally, sort a bunch of #inlcudes.
Due to a modeling error in the type checker's folding of type
references into type expressions, code such as "strideof(Int)" would
be accepted without the required ".self". Commit
4a60b6cbf4 fixes the modeling issue but
left the historical accepts-invalid; now, diagnose these cases with a
warning + Fix-It to ease the transition.
Fixes SR-899.
Whenever we have a call, retrieve the argument labels from the
argument structurally and associate them with the callee. We were
previously doing this as a separate AST walk (which was unnecessary),
so fold that into constraint generation for a CallExpr.
This is a slightly-pared-back version of
3753d779bc that isn't so rigid in its
interpretation of ASTs. I'll tighten up the semantics over time.
TypeExpr formation from expressions is eager, and was pulling in the
parentheses used to form a call argument, e.g.,
strideof(Int)
would end up being a CallExpr whose argument was a TypeExpr containing
the type "(Int)". This had the side effect of not requiring ".self"
where it should (as reported in SR-899), e.g., the correct code for
the above would be:
strideof(Int.self)
Don't pull the parentheses of a call argument into the TypeExpr, so we
get a more sane AST. This would fix SR-899, but because SE-0090 is in
limbo right now, we don't actually want to require the initial code to
be considered well-formed right now. Therefore, put a hack into the
checking for ".self" that ignores this specific case.
Whenever we have a call, retrieve the argument labels from the
argument structurally and associate them with the callee. We were
previously doing this as a separate AST walk (which was unnecessary),
so fold that into constraint generation for a CallExpr. We were also
allowing weird ASTs to effectively disable this information: tighten
that up and require that CallExprs always have a ParenExpr, TupleExpr,
or (as a temporary hack) a TypeExpr whose representation is a
TupleTypeRepr as their argument prior to type checking. This gives us
a more sane AST to work with, and guarantees that we aren't losing
label information.
From the user perspective, this should be NFC, because it's mostly AST
cleanup and staging.
This is the protocol version of 7bfdd4a2: if a protocol requirement
has a newly-bridged type (say, 'URL' instead of 'NSURL'), then any
conforming types will need to update their implementations of the
requirement. Reuse the override-checking mechanism to do so when
we're reasonably confident about it.
This slots the checking into the existing protocol diagnostics, which
doesn't result in the best user experience.
note: protocol requires property 'prop' with type 'Refrigerator?'
var prop: Refrigerator? { get }
^
note: candidate has non-matching type 'APPRefrigerator?'
var prop: APPRefrigerator? {
^ ~~~~~~~~~~~~~~~~
Refrigerator?
But we can come back and improve that later; right now this is better
than nothing.
rdar://problem/26237030
With the introduction of near-miss checking for optional @objc
protocol requirements, the omit-needless-words logic within the type
checker started being applied to arbitrary declarations that might not
have been type-checked, leading to crashes in various multi-file
scenarios that I wasn't able to reduce down to a sensible test
case. Make sure these declarations get type-checked, fixing
rdar://problem/26413181.
...or renaming to operators, unless we're sure the original thing was
an operator expression. There are just a lot of ways this can be
screwed up.
(Some cases of this can certainly be implemented. I may file a
StarterBug later.)
Fixes 797260939 to not crash when all argument labels match except
for the missing label of a trailing closure. (This is specifically
for the fix-it generated for calling an unavailable-and-renamed API,
not for just getting the argument labels wrong in a normal call.)
rdar://problem/26234493
When we see a string literal used to initializer a Selector, and that
string literal names the selector for the getter or setter of an
Objective-C property, suggest #selector(getter: ...) or
This completes SE-0064. Big thanks for Alex Hoppen (@ahoppen) for his
contributions here.
This was easy with a bit of refactoring, but eventually I'd love to
converge override checking and witness checking logic a bit more.
Fixes <rdar://26183366>.
This is the second half of the previous commit. The most common case
of this will be due to the new rules for imported Objective-C API,
but it will also catch things like "I forgot to make the first
parameter not have an argument label".
