Currently invalid initializer references are detected and
diagnosed in solution application phase, but that's too
late because solver wouldn't have required information while
attempting to determine the best solution, which might result
in viable solutions being ignored in favour of incorrect ones e.g.
```swift
protocol P {
init(value: Int)
}
class C {
init(value: Int, _: String = "") {}
}
func make<T: P & C>(type: T.Type) -> T {
return T.init(value: 0)
}
```
In this example `init` on `C` would be preferred since it
comes from the concrete type, but reference itself is invalid
because it's an attempt to construct class object using
metatype value via non-required initalizer.
Situations like these should be recognized early and invalid
use like in case of `C.init` should be ranked lower or diagnosed
if that is the only possible solution.
Resolves: rdar://problem/47787705
Instead of constructing calls to ExpressibleByBooleanLiteral.init(booleanLiteral: ...) in CSApply.cpp, just
annotate BooleanLiteralExpr with the selected constructor and do the actual construction during SILGen.
For context, StringLiteralExpr and NilLiteralExpr already behave this way.
Instead of constructing calls to
ExpressibleByNilLiteral.init(nilLiteral: ()) in CSApply.cpp, just
annotate NilLiteralExpr with the selected construtor and do the actual
construction during SILGen.
For context, StringLiteralExpr already behaves this way.
The intention here is to be able to detect warnings earlier and
move some of the logic from CSApply and MiscDiagnostics to solver.
Warning fixes still lead to solution being applied to AST.
Removes the _getBuiltinLogicValue intrinsic in favor of an open-coded
struct_extract in SIL. This removes Sema's last non-literal use of builtin
integer types and unblocks a bunch of cleanup.
This patch would be NFC, but it improves line information for conditional expression codegen.
Currently when `LazyInitializerExpr` is added to the AST it's not
given an explicit type. Because of that constraint solver silently
fails in contraint generator without diagnostic. But since
sub-expression associated with `LazyInitializerExpr` is already
type-checked it makes sense to set its type explicitly.
In Swift 5 mode, CSGen generates a conversion constraint from
the type of OptionalTryExpr's subexpression, call it T, and
Optional<$tv> for a new type variable $tv.
When applying the solution, we would coerce the sub-expression
to T? if T was not optional, or T otherwise. This was wrong
because there's no reason that $tv is actually equal to T.
Instead, we must coerce the sub-expression to Optional<$tv>,
which is the type of the overall OptionalTryExpr.
Fixes <rdar://problem/46742002>.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Instead of passing in a DeclContext, which we don't have when emitting a keypath
accessor, pass in a ModuleDecl and ResilienceExpansion.
Keypaths now work well enough in inlinable contexts that we can check in an
end-to-end resilience test.
* Gardening for `@dynamicMemberLookup`.
- Unify code style of `@dynamicMemberLookup` and `@dynamicCallable` implementations.
- Use consistent variable names, diagnostic messages, doc comments, etc.
- Move `@dynamicMemberLookup` test to `test/attr` directory.
Since it was allowed to pass function types to @autoclosure
parameters in Swift versions < 5, it has to be handled as
a regular function coversion by `coerceToType`.
`typeCheckParameterDefault` is used to type-check default value
expression associated with a given parameter. It makes it possible
to look-through `@autoclosure` function to use its result as
contextual type, and later build implicit autoclosure expression
if needed.
* Implement dynamically callable types (`@dynamicCallable`).
- Implement dynamically callable types as proposed in SE-0216.
- Dynamic calls are resolved based on call-site syntax.
- Use the `withArguments:` method if it's defined and there are no
keyword arguments.
- Otherwise, use the `withKeywordArguments:` method.
- Support multiple `dynamicallyCall` methods.
- This enables two scenarios:
- Overloaded `dynamicallyCall` methods on a single
`@dynamicCallable` type.
- Multiple `dynamicallyCall` methods from a `@dynamicCallable`
superclass or from `@dynamicCallable` protocols.
- Add `DynamicCallableApplicableFunction` constraint. This, used with
an overload set, is necessary to support multiple `dynamicallyCall`
methods.
If the sub-expression of the 'try?' is optional, the result will be the same level of optional-ness.
If the sub-expression is non-optional, the result is optional.
Thus, the following lines all end up with the same type of 'Int?'
- let x = try? 3 as Int
- let x = try? 3 as? Int
- let x = try? 3 as Int?
Since original implicit coercion expression is preserved in AST
it needs to have its simplified type cached in the constraint
system in order for AST to get the correct type when solution
is fully applied.
Resolves: rdar://problem/45415874
Arbitrary currying is no longer allowed so level could be switched
to a boolean flag for methods like `computeDefaultMap` to identify
if they need to look through curried self type or not.
When converting an initialization to a coercion like:
```swift
_ = Float(90)
```
the outer coercion is given the startLoc and endLoc of the CallExpr in
source.
However, once we unwrap it and pull the implicit CallExpr to
`init(_builtinIntegerLiteral:)`, we lose the original source range.
Instead, leave the outer CoerceExpr, as it's ignored in SILGen anyway.
Previously, the `__consuming` decl modifier failed to get propagated to the value ownership of the
method's `self` parameter, causing it to effectively be a no-op. Fix this, and address some of the
downstream issues this exposes:
- `coerceCallArguments` in the type checker failing to handle the single `__owned` parameter case
- Various places in SILGen and optimizer passes that made inappropriate assertions that `self`
was always passed guaranteed
It was useful when logic related to `BridgingConstraint` was part of
`Conversion` constraint, which could be generated as a result of implicit
conversion for an operator parameter.
