I needed this for materializeForSet remission, but it makes inherited
variadic initializers work, too.
I tried to make this a reasonable starting point for a real language
feature. Here's what's still missing:
- syntax
- semantic restrictions to ensure that the expression isn't written in
invalid places or arbitrarily converted
- SILGen support for expansions that aren't the only variadic argument
rdar://16331406
This looks like a subtle issue. It was broken in 4.1 and got fixed in
4.2, perhaps by the decl checker cleanups or some other change.
I don't see many occurrences of 'required convenience' in the
non-executable tests, period, so it's good to have a bit more
coverage for this corner of the language.
This builds on initial commit which added `RelabelArguments` fix
to the solver that only supported `missingLabels` at that moment,
but now it supports all three posibilities - missing/extraneous and
incorrect labels.
Follow-up to my earlier changes to drop 'inout' types when cloning parameter
lists, we also need to deal with substitutions into those parameter types.
This is an artifact of us having mostly---but not entirely---removed
InOutType from the AST. Fixes rdar://problem/34818336.
The code in recordTypeWitness() seemed to be completely bogus;
it already receives a type written in terms of the archetypes
of the adoptee's context, so mapTypeOutOfContext() did nothing
here, because it was using the wrong substitutions.
The logic for synthesizing designated initializers was also
slightly wrong if the class was nested inside a generic
function.
Finally, interface and contextual types of a derived rawValue
were flipped around.
Initializers are inherited by synthesizing an implicit decl which
delegates to super.init(). Previously this was only done if the
class and superclass were concrete.
The only thing missing was that we weren't computing an interface
type for the synthesized constructor. There are two steps to this:
- First, we must map the contextual types of the superclass
initializer's ParamDecls to the subclass generic context.
- Second, we must set the interface type by calling the new
configureInterfaceType() method, extracted from from
validateGenericSignature().
Note that configureInterfaceType() now uses the new
AbstractFunctionDecl::hasThrows() flag to set the 'throws' bit on
the function type. Previously, validateGenericFuncSignature()
would look at getThrowsLoc().isValid(), which is not correct for
imported, implicitly-generated or de-serialized decls that 'throw',
because none of those have source location information.
We still don't allow inheriting initializers which have their
own generic parameter list, like 'init<T>(t: T) {...}'. That
requires a little bit more refactoring.
Progress on <rdar://problem/23376955>.
The issue here is that the constraint solver was deciding on
FixKind::RelabelCallTuple as the fix for the problem and emitting the
diagnostic, even though there were two different fixes possible.
CSDiags has the infrastructure to support doing doing the right thing
here, but is only being used for ApplyExprs, not SubscriptExprs.
The solution is to fix both problems: remove FixKind::RelabelCallTuple,
to let CSDiags handle the problem, and enhance CSDiags to treat
SubscriptExpr more commonly with ApplyExpr. This improves several cases
where the solver was picking one solution randomly and suggesting that
as a fix, instead of listing that there are multiple different solutions.
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
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
Rather than just saying "'Foo' is not constructible with '()'", say
"'Foo' cannot be constructed because it has no accessible initializers",
which would help framework authors realize what they did wrong.
<rdar://problem/17717714>
Swift SVN r20232
If a subclass defines no subobject initializers and all of its stored
properties have initial values, "inherit" all of the subobject
initializers of its superclass by creating a new initializer with the
same signature that overrides (and chains to) the corresponding
subobject initializer of its parent. Do this instead of blindly
creating a default initializer.
Note that we aren't yet doing this for generic initializers. That will
be a separate step.
Swift SVN r14995
