This is part of rdar://16323038. Because this hasn't been fully design reviewed and
implemented, I'm naming it as __nocapture for now. It is blocking finishing off the
"improved let model" work.
Swift SVN r24079
everything the type attribute does (notably, doesn't work on parameters),
but this includes the infrastructure to apply it in all the sordid places
that need to be touched for type-adjusting declattributes on variables.
Swift SVN r24044
This lets us remove a few special cases for @NSManaged, and also fixes
some of the special cases that we didn't handle, like rdar://problem/18801796.
Swift SVN r24037
teach SILGenLValue that let values guarantee the lifetime of their value for at least
the duration of whatever expression references the let value. This allows us to eliminate
retains/release pairs in a lot of cases, and provides more value for people to use let
instead of var. This combines particularly well with +0 self arguments (currently just
protocol/archetype dispatches, but perhaps someday soon all method dispatches).
Thanks to John for suggesting this.
Swift SVN r24004
"private" is a very overloaded term already. "Cascading" instead of
"non-private" is a bit more clear about what will happen with this sort
of lookup.
No functionality change. There are some double negatives I plan to clean
up in the next commit, but this one was supposed to be very mechanical.
Swift SVN r23969
... now that we have an exquisitely shaved yak.
This provides a simple and uniform model for "let" constants: they are always either
immediately initialized in their declaration, or they are initialized dynamically
exactly once before any use.
This is a simple generalization of our current model for initializers, but enables
the use of let constants in more cases in local context, e.g. patterns like this:
let x : SomeThing
if condition {
x = foo()
} else {
x = bar()
}
use(x)
Previously this would have to be declared a "var" for no good reason: the value is
only ever initialized, never actually mutated.
The implementation of this is reasonably straight-forward now that the infrastructure
is in place: Sema treats 'let' constants as "settable" if they lack an initializer
(either in the declaration or in a non-PBD binding). This exposes them as an lvalue
at the AST level. SILGen then lowers these things to an alloc_stack, and DI enforces
the "initialization only" requirement that it already enforces for uninitialized 'let'
properties in structs/classes.
Swift SVN r23916
isn't used yet, but will be for modeling the self argument passed to an
address-only witness implementation. NFC since all this code is dead :-)
Swift SVN r23857
This code is trying to avoid emitting multiple diagnostics on the same line:
before it was using a vector to keep track of exprs already emitted, I changed
it to clear the isImplicit() bit. Clearing isImplicit introduces problems
because various things (in this case, SourceRange validation) are keyed off
whether an expression is implicit or not.
Instead of solving it either of those ways, fix our walk to just not recursively
descend into the 'self' argument of a self.foo expression when doing the walk.
While we're here, make it so that ChrisW's example doesn't even produce the
diagnostic in question: the DRE is in a closure, but only because the entire
class is defined in the closure. Stop the walker from descending recursively
into decls at all.
Swift SVN r23793
This is a hidden frontend-only option intended for debugging purposes,
mainly for identifying where in a file the type checker is spending most
of its time. Use with "sort -g" to get the top problem functions.
Swift SVN r23789
These changes make the following improvements to how we generate diagnostics for expression typecheck failure:
- Customizing a diagnostic for a specific expression kind is as easy as adding a new method to the FailureDiagnosis class,
and does not require intimate knowledge of the constraint solver’s inner workings.
- As part of this patch, I’ve introduced specialized diagnostics for call, binop, unop, subscript, assignment and inout
expressions, but we can go pretty far with this.
- This also opens up the possibility to customize diagnostics not just for the expression kind, but for the specific types
involved as well.
- For the purpose of presenting accurate type info, partially-specialized subexpressions are individually re-typechecked
free of any contextual types. This allows us to:
- Properly surface subexpression errors.
- Almost completely avoid any type variables in our diagnostics. In cases where they could not be eliminated, we now
substitute in "_".
- More accurately indicate the sources of errors.
- We do a much better job of diagnosing disjunction failures. (So no more nonsensical ‘UInt8’ error messages.)
- We now present reasonable error messages for overload resolution failures, informing the user of partially-matching
parameter lists when possible.
At the very least, these changes address the following bugs:
<rdar://problem/15863738> More information needed in type-checking error messages
<rdar://problem/16306600> QoI: passing a 'let' value as an inout results in an unfriendly diagnostic
<rdar://problem/16449805> Wrong error for struct-to-protocol downcast
<rdar://problem/16699932> improve type checker diagnostic when passing Double to function taking a Float
<rdar://problem/16707914> fatal error: Can't unwrap Optional.None…Optional.swift, line 75 running Master-Detail Swift app built from template
<rdar://problem/16785829> Inout parameter fixit
<rdar://problem/16900438> We shouldn't leak the internal type placeholder
<rdar://problem/16909379> confusing type check diagnostics
<rdar://problem/16951521> Extra arguments to functions result in an unhelpful error
<rdar://problem/16971025> Two Terrible Diagnostics
<rdar://problem/17007804> $T2 in compiler error string
<rdar://problem/17027483> Terrible diagnostic
<rdar://problem/17083239> Mysterious error using find() with Foundation types
<rdar://problem/17149771> Diagnostic for closure with no inferred return value leaks type variables
<rdar://problem/17212371> Swift poorly-worded error message when overload resolution fails on return type
<rdar://problem/17236976> QoI: Swift error for incorrectly typed parameter is confusing/misleading
<rdar://problem/17304200> Wrong error for non-self-conforming protocols
<rdar://problem/17321369> better error message for inout protocols
<rdar://problem/17539380> Swift error seems wrong
<rdar://problem/17559593> Bogus locationless "treating a forced downcast to 'NSData' as optional will never produce 'nil'" warning
<rdar://problem/17567973> 32-bit error message is really far from the mark: error: missing argument for parameter 'withFont' in call
<rdar://problem/17671058> Wrong error message: "Missing argument for parameter 'completion' in call"
<rdar://problem/17704609> Float is not convertible to UInt8
<rdar://problem/17705424> Poor error reporting for passing Doubles to NSColor: extra argument 'red' in call
<rdar://problem/17743603> Swift compiler gives misleading error message in "NSLayoutConstraint.constraintsWithVisualFormat("x", options: 123, metrics: nil, views: views)"
<rdar://problem/17784167> application of operator to generic type results in odd diagnostic
<rdar://problem/17801696> Awful diagnostic trying to construct an Int when .Int is around
<rdar://problem/17863882> cannot convert the expression's type '()' to type 'Seq'
<rdar://problem/17865869> "has different argument names" diagnostic when parameter defaulted-ness differs
<rdar://problem/17937593> Unclear error message for empty array literal without type context
<rdar://problem/17943023> QoI: compiler displays wrong error when a float is provided to a Int16 parameter in init method
<rdar://problem/17951148> Improve error messages for expressions inside if statements by pre-evaluating outside the 'if'
<rdar://problem/18057815> Unhelpful Swift error message
<rdar://problem/18077468> Incorrect argument label for insertSubview(...)
<rdar://problem/18079213> 'T1' is not identical to 'T2' lacks directionality
<rdar://problem/18086470> Confusing Swift error message: error: 'T' is not convertible to 'MirrorDisposition'
<rdar://problem/18098995> QoI: Unhelpful compiler error when leaving off an & on an inout parameter
<rdar://problem/18104379> Terrible error message
<rdar://problem/18121897> unexpected low-level error on assignment to immutable value through array writeback
<rdar://problem/18123596> unexpected error on self. capture inside class method
<rdar://problem/18152074> QoI: Improve diagnostic for type mismatch in dictionary subscripting
<rdar://problem/18242160> There could be a better error message when using [] instead of [:]
<rdar://problem/18242812> 6A1021a : Type variable leaked
<rdar://problem/18331819> Unclear error message when trying to set an element of an array constant (Swift)
<rdar://problem/18414834> Bad diagnostics example
<rdar://problem/18422468> Calculation of constant value yields unexplainable error
<rdar://problem/18427217> Misleading error message makes debugging difficult
<rdar://problem/18439742> Misleading error: "cannot invoke" mentions completely unrelated types as arguments
<rdar://problem/18535804> Wrong compiler error from swift compiler
<rdar://problem/18567914> Xcode 6.1. GM, Swift, assignment from Int64 to NSNumber. Warning shown as problem with UInt8
<rdar://problem/18784027> Negating Int? Yields Float
<rdar://problem/17691565> attempt to modify a 'let' variable with ++ results in typecheck error about @lvalue Float
<rdar://problem/17164001> "++" on let value could give a better error message
Swift SVN r23782
- We switch to a model where let properties may be "initialized", but never
reassigned. Specifically, immutable properties in structs/classes may have
an init value specified in their declaration (but can then never be reset
in any init implementation) or not (in which case they must be initialized
exactly once on all paths through every init. This makes a lot more sense
for immutability, defines several problems away, and provides a path to
supporting things like (rdar://16181314)
- We now *never* default initialize an immutable property. Formerly
we would default initialize optional let properties to nil, but this
isn't actually useful, and allows an error of omission with let
properties.
This resolves: <rdar://problem/19035287> let properties should only be initializable, not reassignable
and possibly other radars.
Swift SVN r23779
The metatype's instance type is always an AST type. Fixes rdar://problem/19165906. Also fix a bug where we would incorrectly resolve the metatypes of existential metatypes. We resolved Any.Type.Type to the concrete-meta-existential-meta-type (exists T. (T.Type)).Type, instead of the existential-meta-existential-meta-type exists T. (T.Type.Type), and rejected Any.Type.Protocol, which is the correct spelling of the concrete metatype.
Swift SVN r23759
a capture list hung off the CaptureExpr it was associated with. This made
sense lexically (since a capture list is nested inside of the closure) but
not semantically. Semantically, the capture list initializers are evaluated
outside the closure, the variables are bound to those values, then the closure
captures the newly bound values.
To directly represent this, represent captures with a new CaptureListExpr node,
which contains the ClosureExpr inside of it. This correctly models the semantic
relationship, and makes sure that AST walkers all process the initializers of the
capture list as being *outside* of the closure.
This fixes rdar://19146761 and probably others.
Swift SVN r23756
Add the following functionality to the Swift compiler:
* covariant subtyping of Set
* upcasting, downcasting of Set
* automatic bridging between Set and NSSet, including
* NSSet params/return values in ObjC are imported as Set<NSObject>
* Set params/return values in Swift are visible to ObjC as NSSet
<rdar://problem/18853078> Implement Set<T> up and downcasting
Swift SVN r23751
This reverts commit dc98e17d84b991b6be8b8feb5e0d05aad24f52a4.
I believe this commit was causing test failures on:
IRGen/c_layout.sil
IRGen/existentials.sil
It also recreates the file lib/Serialization/ModuleFormat.h,
which really can't have been intended.
Swift SVN r23732
Adding explicit constructors to Clang-imported structs in the previous commits exposes a latent phase ordering issue between the Clang importer and SIL deserialization. Deserializing the standard library SIL ends up pulling in additional Clang decls which never get type-checked before we attempt to emit their code. Work around this by bringing back the "EagerDeserializedDecls" block in the serialization format, and adding any cross-referenced decls that get referenced in SILSerializeAll mode to it, so that we ensure they're available before SILGen. We also have to type-check external decls after doing so, since when only importing a module, we wouldn't do any type-checking at all otherwise.
Swift SVN r23728
If a conformance is found for a type in another module, that conformance
will never change in response to what happens in this module, so we don't
need to treat it as a dependency at all.
Swift SVN r23702
Specifically, it's not when
- the conformance is being used within a function body (test included)
- the conformance is being used for or within a private type (test included)
- the conformance is being used to generate a diagnostic string
We're still a bit imprecise in some places (checking ObjC bridging), but
in general this means less of an issue for checking literals.
Swift SVN r23700
--This line, and those bel that ow, will be ignored--
M test/Parse/optional.swift
M test/ClangModules/Security_test.swift
M test/expr/expressions.swift
M include/swift/AST/DiagnosticsSema.def
M lib/Sema/CSApply.cpp
Swift SVN r23685
...and thus does not affect downstream files...
...and adopt it in several places:
- when looking up the default type for a literal (test included)
- when looking up the first component in an IdentTypeRepr (test included)
- when deciding which ~= to use in a switch (test forthcoming)
- when a protocol has an operator function requirement (test forthcoming)
- when validating @NSApplicationMain and @UIApplicationMain
- when an enum element shows up unqualified in a switch
- several places where it doesn't matter because we're looking something up
in the standard library.
Part of rdar://problem/15353101
Swift SVN r23670
This is not quite the same as ASTContext::getBoolDecl because it handles
-parse-stdlib source files that don't import the standard library, but it
still doesn't need to do a general lookup.
No functionality change.
Swift SVN r23667
