* [stdlib] String : RangeReplaceableCollection & BidirectionalCollection
* Add source compatibility hack for Swift.max
* Add source compatibility hack for Swift.min
* Remove redundant conformance in benchmarks
* Fix stupid typo I thought I'd already pushed
* XFAIL testing now-redundant conformance
* XFAIL an IDE test for now
If the -enable-experimental-subclass-existentials staging flag
is on, resolveType() now allows protocol compositions to contain
class types. It also diagnoses if a composition has more than one
superclass requirement.
Also, change diagnostics that talked about 'protocol composition'
to 'protocol-constrained type'.
Since such types can now contain a superclass constraint, it's not
correct to call them protocol composition.
"Protocol-constrained type" isn't quite accurate either because
'Any' has no protocols, and 'AnyObject' will have no protocols but
a general class constraint; but those are edge cases which won't
come up in these diagnostics.
1. Make sure the actions taken by fixits are reflected in diagnostics messages.
2. Issue missing cases diagnostics at the start of the switch statement instead of its end.
3. Use <#code#> instead of <#Code#> in the stub.
`1 { }` was parsed as a call expression with a trailing closure. This made the diagnostics for `var x = 1 { get { ... } }` extremely bad. Resolves SR-3671.
Add diagnostics to fix decls with consecutive identifiers. This applies to
types, properties, variables, and enum cases. The diagnostic adds a camel-cased option if it is different than the first option.
https://bugs.swift.org/browse/SR-3599
Add a diagnostic to remove the name of an initializer, deinitializer, or subscript. The identifier token is consumed and skipped to prevent the parser from emitting additional error messages.
Add tests to verify that the name is removed from initializers, deinitializers, and subscripts declared with a name.
If we found any error in a list, in most cases, we cannot expect that the
following tokens could construct a valid element. Skip them, instead of trying
to parse them as the next element. This significally reduces bogus diagnostics.
Bailout if seeing tok::eof or token that can never start a element, after
parsing an element. This silences superfluous "expected ',' separator" error,
or misleading expected declaration error. What we should emit is
"expected ')' in expression list, or "expected '}' in struct".
Rather than parsing the call arguments (or similar, e.g., subscript)
as a parenthesized expression or tuple, then later reworking that
ParenExpr/TupleExpr if a trailing closure comes along, then digging
through that ParenExpr/TupleExpr to pull out the arguments and
trailing closure... just parse the expression list and trailing
closure together, then directly form the appropriate AST node with
arguments/labels/label locations/trailing closure.
Fixes rdar://problem/19804707, which is an issue where trailing
closures weren't working with unresolved member expressions (e.g.,
".foo {... }"), and is a stepping-stone to SE-0111.
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
Also adds:
- Any is caught before doing an unconstrained lookup, and the
protocol<> type is emitted
- composition expressions can be handled by
`PreCheckExpression::simplifyTypeExpr` to so you can do lookups like (P
& Q).self
- Fixits corrected & new tests added
- Typeref lowering cases should have been optional
- This fixes a failing test case.
This commit defines the ‘Any’ keyword, implements parsing for composing
types with an infix ‘&’, and provides a fixit to convert ‘protocol<>’
- Updated tests & stdlib for new composition syntax
- Provide errors when compositions used in inheritance.
Any is treated as a contextual keyword. The name ‘Any’
is used emit the empty composition type. We have to
stop user declaring top level types spelled ‘Any’ too.
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 { ... }
~^
( )
silently, have the lexer return it as an unknown token. Enhance the expr parser to
detect these things and squash any expression in progress into an ErrorExpr. This
allows us to silence really bad downstream errors. For example, on:
struct S { func f() {} }
func f() {
_ = S.
}
we formerly produced:
x.swift:5:8: error: expected member name following '.'
x.swift:5:7: error: expected member name or constructor call after type name
x.swift:5:7: note: add arguments after the type to construct a value of the type
x.swift:5:7: note: use '.self' to reference the type object
we now emit just the first one. This fixes:
<rdar://problem/22290244> QoI: "UIColor." gives two issues, should only give one
along with recent policy changes:
- For expression types that are not specifically handled, make sure to
produce a general "unused value" warning, catching a bunch of unused
values in the testsuite.
- For unused operator results, diagnose them as uses of the operator
instead of "calls".
- For calls, mutter the type of the result for greater specificity.
- For initializers, mutter the type of the initialized value.
- Look through OpenExistentialExpr's so we can handle protocol member
references propertly.
- Look through several other expressions so we handle @discardableResult
better.
as a failure to convert the individual operand, since the operator
is likely conceptually generic in some way and the choice of any
specific overload is probably arbitrary.
Since we now fall back to a better-informed diagnostics point, take
advantage of this to generate a specialized diagnostic when trying to
compare values of function type with ===.
Fixes rdar://25666129.
This reverts commit 073f427942,
i.e. it reapplies 35ba809fd0 with a
test fix to expect an extra note in one place.
as a failure to convert the individual operand, since the operator
is likely conceptually generic in some way and the choice of any
specific overload is probably arbitrary.
Since we now fall back to a better-informed diagnostics point, take
advantage of this to generate a specialized diagnostic when trying to
compare values of function type with ===.
Fixes rdar://25666129.
It is a common problem that people use a call to a function with a
trailing closure in a if condition, foreach loop, etc. These don't allow
trailing closures, because they are ambiguous with the brace-enclosed body
of the conditional statement.
In an effort to improve QoI on this, perform lookahead to disambiguate the most common
form of this, in a very narrow situation. This allows us to produce a nice error
with fixit hints like:
t.swift:26:25: error: trailing closure requires parentheses for disambiguation in this context
for _ in numbers.filter {$0 > 4} {
^
instead of spewing out this garbage:
t.swift:26:26: error: anonymous closure argument not contained in a closure
for _ in numbers.filter {$0 > 4} {
^
t.swift:26:33: error: consecutive statements on a line must be separated by ';'
for _ in numbers.filter {$0 > 4} {
^
;
t.swift:26:34: error: statement cannot begin with a closure expression
for _ in numbers.filter {$0 > 4} {
^
t.swift:26:34: note: explicitly discard the result of the closure by assigning to '_'
for _ in numbers.filter {$0 > 4} {
^
_ =
t.swift:26:34: error: braced block of statements is an unused closure
for _ in numbers.filter {$0 > 4} {
^
t.swift:26:18: error: type '(@noescape (Int) throws -> Bool) throws -> [Int]' does not conform to protocol 'Sequence'
for _ in numbers.filter {$0 > 4} {
^
t.swift:26:34: error: expression resolves to an unused function
for _ in numbers.filter {$0 > 4} {
^
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.
