VarargExpansionExpr shows up in call argument lists in synthesized
initializers and modify accessors when we need to forward arguments
to a call taking varargs.
Previously we would say that the type of VarargExpansionExpr is
$T when its subexpression type is [$T]. matchCallArguments() would
then 'collect' the single VarargExpansionExpr into a variadic
argument list with a single element, and build an ArgumentShuffleExpr
for the argument list.
In turn, SILGen would peephole vararg emission of a variadic
argument list with a single entry that happens to be a
VarargExpansionExpr, by returning the subexpression's value,
which happened to be an array of the right element type,
instead of building a new array containing the elements of the
variadic argument list.
This was all too complicated. Instead, let's say that the type of
a VarargExpansionExpr is [$T], except that when it appears in a
TupleExpr, the variadic bit of the corresponding element is set.
Then, matchCallArguments() needs to support a case where both
the parameter and argument list have a matching vararg element.
In this case, instead of collecting multiple arguments into a
single variadic argument list, we treat the variadic argument like
an ordinary parameter, bypassing construction of the
ArgumentShuffleExpr altogether.
Finally, SILGen now needs to be able to emit a VarargExpansionExpr
in ordinary rvalue position, since it now appears as a child of a
TupleExpr; it can do this by simply emitting the sub-expression
to produce an array value.
TupleShuffleExpr could not express the full range of tuple conversions that
were accepted by the constraint solver; in particular, while it could re-order
elements or introduce and eliminate labels, it could not convert the tuple
element types to their supertypes.
This was the source of the annoying "cannot express tuple conversion"
diagnostic.
Replace TupleShuffleExpr with DestructureTupleExpr, which evaluates a
source expression of tuple type and binds its elements to OpaqueValueExprs.
The DestructureTupleExpr's result expression can then produce an arbitrary
value written in terms of these OpaqueValueExprs, as long as each
OpaqueValueExpr is used exactly once.
This is sufficient to express conversions such as (Int, Float) => (Int?, Any),
as well as the various cases that were already supported, such as
(x: Int, y: Float) => (y: Float, x: Int).
https://bugs.swift.org/browse/SR-2672, rdar://problem/12340004
Before extending TupleShuffleExpr to represent all tuple
conversions allowed by the constraint solver, remove the
parts of TupleShuffleExpr that are no longer needed; this is
support for default arguments, varargs, and scalar-to-tuple and
tuple-to-scalar conversions.
Right now we use TupleShuffleExpr for two completely different things:
- Tuple conversions, where elements can be re-ordered and labels can be
introduced/eliminated
- Complex argument lists, involving default arguments or varargs
The first case does not allow default arguments or varargs, and the
second case does not allow re-ordering or introduction/elimination
of labels. Furthermore, the first case has a representation limitation
that prevents us from expressing tuple conversions that change the
type of tuple elements.
For all these reasons, it is better if we use two separate Expr kinds
for these purposes. For now, just make an identical copy of
TupleShuffleExpr and call it ArgumentShuffleExpr. In CSApply, use
ArgumentShuffleExpr when forming the arguments to a call, and keep
using TupleShuffleExpr for tuple conversions. Each usage of
TupleShuffleExpr has been audited to see if it should instead look at
ArgumentShuffleExpr.
In sequent commits I plan on redesigning TupleShuffleExpr to correctly
represent all tuple conversions without any unnecessary baggage.
Longer term, we actually want to change the representation of CallExpr
to directly store an argument list; then instead of a single child
expression that must be a ParenExpr, TupleExpr or ArgumentShuffleExpr,
all CallExprs will have a uniform representation and ArgumentShuffleExpr
will go away altogether. This should reduce memory usage and radically
simplify parts of SILGen.
Introduce stored property default argument kind
Fix indent
Assign nil to optionals with no initializers
Don't emit generator for stored property default arg
Fix problem with rebase
Indentation
Serialize stored property default arg text
Fix some tests
Add missing constructor in test
Print stored property's initializer expression
cleanups
preserve switch
complete_constructor
formatting
fix conflict
For context, String, Nil, Bool, and Int already behave this way.
Note: Swift can compile against 80 or 64 bit floats as the builtin
literal type. Thus, it was necessary to capture this bit somehow in the
FloatLiteralExpr. This was done as another Type field capturing this
info.
While attempting to form a call of an unresolved member, the fact
that argument application could fail has to be accounted for.
Resolves: rdar://problem/48114578
The current series of "unrelated" `if` statements makes understanding
and updating this function harder than necessary. By using two `switch`
statements, we can avoid these problems and as a bonus, generate more
efficient code gen.
For context, String, Nil, and Bool already behave this way.
Note: Before it used to construct (call, ... (integer_literal)), and the
call would be made explicit / implicit based on if you did eg: Int(3) or
just 3. This however did not translate to the new world so this PR adds
a IsExplicitConversion bit to NumberLiteralExpr. Some side results of
all this are that some warnings changed a little and some instructions are
emitted in a different order.
Situations like:
```swift
struct S {}
func foo(_ s: S.Type) {
_ = s()
}
```
Used to be diagnosed in solution application phase, which means that
solver was allowed to formed an incorrect solution.
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
