Parse 'var [behavior] x: T', and when we see it, try to instantiate the property's
implementation in terms of the given behavior. To start out, behaviors are modeled
as protocols. If the protocol follows this pattern:
```
protocol behavior {
associatedtype Value
}
extension behavior {
var value: Value { ... }
}
```
then the property is instantiated by forming a conformance to `behavior` where
`Self` is bound to the enclosing type and `Value` is bound to the property's
declared type, and invoking the accessors of the `value` implementation:
```
struct Foo {
var [behavior] foo: Int
}
/* behaves like */
extension Foo: private behavior {
@implements(behavior.Value)
private typealias `[behavior].Value` = Int
var foo: Int {
get { return value }
set { value = newValue }
}
}
```
If the protocol requires a `storage` member, and provides an `initStorage` method
to provide an initial value to the storage:
```
protocol storageBehavior {
associatedtype Value
var storage: Something<Value> { ... }
}
extension storageBehavior {
var value: Value { ... }
static func initStorage() -> Something<Value> { ... }
}
```
then a stored property of the appropriate type is instantiated to witness the
requirement, using `initStorage` to initialize:
```
struct Foo {
var [storageBehavior] foo: Int
}
/* behaves like */
extension Foo: private storageBehavior {
@implements(storageBehavior.Value)
private typealias `[storageBehavior].Value` = Int
@implements(storageBehavior.storage)
private var `[storageBehavior].storage`: Something<Int> = initStorage()
var foo: Int {
get { return value }
set { value = newValue }
}
}
```
In either case, the `value` and `storage` properties should support any combination
of get-only/settable and mutating/nonmutating modifiers. The instantiated property
follows the settability and mutating-ness of the `value` implementation. The
protocol can also impose requirements on the `Self` and `Value` types.
Bells and whistles such as initializer expressions, accessors,
out-of-line initialization, etc. are not implemented. Additionally, behaviors
that instantiate storage are currently only supported on instance properties.
This also hasn't been tested past sema yet; SIL and IRGen will likely expose
additional issues.
class or struct conforming to a protocol. Now we produce a single error
with a fixit hint (rewriting to typealias). Before we produced:
t.swift:7:3: error: associated types can only be defined in a protocol; define a type or introduce a 'typealias' to satisfy an associated type requirement
associatedtype T = Int
^
t.swift:7:17: error: consecutive declarations on a line must be separated by ';'
associatedtype T = Int
^
;
t.swift:7:18: error: expected declaration
associatedtype T = Int
^
t.swift:6:7: error: type 'C' does not conform to protocol 'P'
class C : P {
^
t.swift:3:18: note: protocol requires nested type 'T'
associatedtype T
^
Adds an associatedtype keyword to the parser tokens, and accepts either
typealias or associatedtype to create an AssociatedTypeDecl, warning
that the former is deprecated. The ASTPrinter now emits associatedtype
for AssociatedTypeDecls.
Separated AssociatedType from TypeAlias as two different kinds of
CodeCompletionDeclKinds. This part probably doesn’t turn out to be
absolutely necessary currently, but it is nice cleanup from formerly
specifically glomming the two together.
And then many, many changes to tests. The actual new tests for the fixits
is at the end of Generics/associated_types.swift.
member lookup for subscript instead of digging already-looked-up candidates
out of the constraint system. This allows us to produce more specific
diagnostics in failure cases and keeps subscripts inline with other decls
being looked up.
Swift SVN r31586
argument list mismatches, and diagnose them with a very specific error when
they occur in member lookups. This fixes
<rdar://problem/22356434> QoI: Missing diagnostic for invalid arguments passed to enum case constructor
where before we'd produce:
ee.swift:5:16: error: type of expression is ambiguous without more context
let list: E = .C(wrongLabel: 0)
~^~~~~~~~~~~~~~~~
now we produce:
ee.swift:1:17: error: incorrect argument label in call (have 'wrongLabel:', expected 'label:')
let list: E = .C(wrongLabel: 0)
^~~~~~~~~~~
label
I think that unresolved member exprs now get good diagnostics in all cases that they have
a contextual type, but of course there are lots more cases where we're not getting a
contextual type.
Swift SVN r31402
and diagnoseGeneralConversionFailure(). The previous approach of trying
to dig into anchors would often lead to complaining about types at
different levels in the same diagnostic, and the complexity of the former
code isn't needed now that other changes have landed.
Swift SVN r31036
fixing <rdar://problem/22020088> QoI: missing member diagnostic on optional gives worse error message than existential/bound generic/etc
Swift SVN r30844
- Produce more specific diagnostics relating to different kinds of invalid
- add a testcase, nfc
- Reimplement FailureDiagnosis::diagnoseGeneralMemberFailure in terms of
Not including r30787 means that we still generate bogus diagnostics like:
[1, 2, 3].doesntExist(0) // expected-error {{type 'Int2048' does not conform to protocol 'IntegerLiteralConvertible'}}
But it is an existing and separable problem from the issues addressed here.
Swift SVN r30819
"unavoidable failure" path, along with Failure::DoesNotHaveNonMutatingMember and
just doing some basic disambiguation in CSDiags.
This provides some benefits:
- Allows us to plug in much more specific diagnostics for the existing "only has
mutating members" diagnostic, including producing notes for why the base expr
isn't mutable (see e.g. test/Sema/immutability.swift diffs).
- Corrects issues where we'd drop full decl name info for selector references.
- Wordsmiths diagnostics to not complain about "values of type Foo.Type" instead
complaining about "type Foo"
- Where before we would diagnose all failures with "has no member named", we now
distinguish between when there is no member, and when you can't use it. When you
can't use it, you get a vauge "cannot use it" diagnostic, but...
- This provides an infrastructure for diagnosing other kinds of problems (e.g.
trying to use a private member or a static member from an instance).
- Improves a number of cases where failed type member constraints would produce uglier
diagnostics than a different constraint failure would.
- Resolves a number of rdars, e.g. (and probably others):
<rdar://problem/20294245> QoI: Error message mentions value rather than key for subscript
Swift SVN r30715
get the same wording, fixing <rdar://problem/21964599> Different diagnostics for the same issue
While I'm in the area, remove some dead code.
Swift SVN r30713
- Improve handling of if_expr in a couple of ways: teach constraint simplification
about IfThen/IfElse and teach CSDiags about the case when the cond expr doesn't match
BooleanType. This is rarely necessary, but CSDiags is all about cornercases, and this
does fix a problem in a testcase.
- Be a bit more specific about the constraint failure kind (e.g. say subtype) and when
we have a protocol conformance failure, emit a specific diagnostic about it, instead of
just saying that the types aren't convertible.
Swift SVN r30650
conversion failures, making a bunch of diagnostics more specific and useful.
UnavoidableFailures can be very helpful, but they can also be the first constraint
failure that the system happened to come across... which is not always the most
meaningful one. CSDiag's expr processing machinery has a generally better way of
narrowing down which ones make the most sense.
Swift SVN r30647
Eliminates _CollectionDefaultsType and _CollectionGeneratorDefaultsType
and creates sanity that should allow us to Protocol Extension-ize the
lazy operations, which have been blocked on inscrutable errors due in
part to the existing complexity.
Note: names beginning with "_prext_" are intended to be public after API
review and removal of the "_prext_" prefix.
Swift SVN r29689
this is neutral w.r.t. diagnostics quality, but deletes a ton
of code:
include/swift/AST/DiagnosticsSema.def | 21 ++---------
lib/Sema/CSDiag.cpp | 64 ++--------------------------------
2 files changed, 9 insertions(+), 76 deletions(-)
Swift SVN r28956
if it has already resolved a member binding of an UnresolvedDotExpr. This allows
us to give tailored diagnostics to indicate whether the destination is not an lvalue
because the property itself was immutable or when the base is immutable.
In addition to improved diagnostics, this allows us to fixit hint "let" to "var" on
property definitions, and we can even go so far as to fixit hint insert 'mutating' on
the enclosing func decl when self is the problem.
This fixes the non-subscript cases of:
<rdar://problem/17632908> QoI: Modifying struct member in non-mutating function produces difficult to understand error message
<rdar://problem/19370429> QoI: fixit to add "mutating" when assigning to a member of self in a struct
<rdar://problem/20234955> QoI: Error message for assigning to 'let' fields should say that the error is due to a 'let' binding
Subscript cases to follow.
Swift SVN r28854
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
The code would generate different diagnosics depending on
the cycle having length 1 or longer. The length 1 case
was broken if the path had a prefix that wasn't part
of the cycle, eg if we have C : A, A : A and visit C
first.
Swift SVN r28317
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
If you want to make the parameter and argument label the same in
places where you don't get the argument label for free (i.e., the
first parameter of a function or a parameter of a subscript),
double-up the identifier:
func translate(dx dx: Int, dy: Int) { }
Make this a warning with Fix-Its to ease migration. Part of
rdar://problem/17218256.
Swift SVN r27715
We're still not using these generated conformances as our primary
source of conformances, but now we can create them here and it doesn't
break anything.
Swift SVN r26297
Previously, a multi-pattern var/let decl like:
var x = 4, y = 17
would produce two pattern binding decls (one for x=4 one for y=17). This is convenient
in some ways, but is bad for source reproducibility from the ASTs (see, e.g. the improvements
in test/IDE/structure.swift and test/decl/inherit/initializer.swift).
The hardest part of this change was to get parseDeclVar to set up the AST in a way
compatible with our existing assumptions. I ended up with an approach that forms PBDs in
more erroneous cases than before. One downside of this is that we now produce a spurious
"type annotation missing in pattern"
diagnostic in some cases. I'll take care of that in a follow-on patch.
Swift SVN r26224
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
rdar://problem/17198298
- Allow 'static' in protocol property and func requirements, but not 'class'.
- Allow 'static' methods in classes - they are 'class final'.
- Only allow 'class' methods in classes (or extensions of classes)
- Remove now unneeded diagnostics related to finding 'static' in previously banned places.
- Update relevant diagnostics to make the new rules clear.
Swift SVN r24260
