More updates to read and write types from a side table in the constraint
solver and only write back into expressions when we've finished type
checking an expression.
We still write directly into expressions, and will continue to do so
until all of the code has been updated.
With the introduction of special decl names, `Identifier getName()` on
`ValueDecl` will be removed and pushed down to nominal declarations
whose name is guaranteed not to be special. Prepare for this by calling
to `DeclBaseName getBaseName()` instead where appropriate.
If a lazy var has no declared type, we have to type check the
initializer to get a type before we can build the getter.
Then, the initializer is type checked as part of the getter
again.
Use the new SkipApplyingSolution flag when type checking for
the first time. We still end up doing redundant work, but by
not applying the solution we avoid feeding invalid AST nodes
back into the constraint solver.
This fixes some bad diagnostics and crashes.
Fixes <https://bugs.swift.org/browse/SR-2616> and
<rdar://problem/28313602>.
And make an attempt to use the constraint system's contextualType to bind type information; this makes things better but doesn't seem to be a complete solution for contextually typing key paths.
None of the clients of this care about distinguishing between immediate
failures in getWitnessType() vs. earlier errors that result in
getWitnessType() returning ErrorType, so simplify the interface by
having it always return Type() if there is a problem.
Update the clients that were not already checking for null result to do
so.
Fixes rdar://problem/32215763.
It's particularly likely someone will try to type `\(foo)`, which looks like a string interpolation segment, outside of a string literal, so give that case a special diagnostic. Fixes rdar://problem/32315365.
We need to strip inout/lvalue before casting the second parameter's type
to FunctionType.
There were also some verification issues and the fact that we weren't
allowing already-escaping closures to be passed to it (which is not
useful, but shouldn't result in an error and really awful
diagnostic). We can potentially look at diagnosing this with a warning
at some point in the future.
Fixes rdar://problem/32239354.
Now that SILGen can correctly lower lvalue accesses of
class existential payloads, remove a hack in Sema that
was simply doing the wrong thing.
Fixes <rdar://problem/31858378>.
This is a bit more robust and user-friendly than hoping more brittle recovery in SILGen or IRGen for unsupported components kicks in. rdar://problem/32200714
Replace `NameOfType foo = dyn_cast<NameOfType>(bar)` with DRY version `auto foo = dyn_cast<NameOfType>(bar)`.
The DRY auto version is by far the dominant form already used in the repo, so this PR merely brings the exceptional cases (redundant repetition form) in line with the dominant form (auto form).
See the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es11-use-auto-to-avoid-redundant-repetition-of-type-names) for a general discussion on why to use `auto` to avoid redundant repetition of type names.
The warnings about deprecated @objc inference in Swift 3 mode can be a
bit annoying; and are mostly relevant to the migration workflow. Make
the warning emission a three-state switch:
* None (the default): don't warn about these issues.
* Minimal (-warn-swift3-objc-inference-minimal): warn about direct
uses of @objc entrypoints and provide "@objc" Fix-Its for them.
* Complete (-warn-swift3-objc-inference-complete): warn about all
cases where Swift 3 infers @objc but Swift 4 will not.
Fixes rdar://problem/31922278.
This introduces a few unfortunate things because the syntax is awkward.
In particular, the period and following token in \.[a], \.? and \.! are
token sequences that don't appear anywhere else in Swift, and so need
special handling. This is somewhat compounded by \foo.bar.baz possibly
being \(foo).bar.baz or \(foo.bar).baz (parens around the type), and,
furthermore, needing to distinguish \Foo?.bar from \Foo.?bar.
rdar://problem/31724243
This is tested in the next commit. This code path is about to
get more cleanup shortly to fix a miscompile with class
existentials (not just subclass existentials; an old problem),
so I'm not too concerned with adding the new conditinals here.
conversions and extend lifetimes over the call.
Apply this logic to string-to-pointer conversions as well as
array-to-pointer conversions.
Fix the AST verifier to not blow up on optional pointer conversions,
and make sure we SILGen them correctly. There's still an AST bug
here, but I'll fix that in a follow-up patch.
NormalProtocolConformance has the only correct implementation of this
functionality. Instead, providing a safer getWitnessDecl() that
doesn't promise substitutions that are incorrect (and not actually
used by any clients).
Make sure we use the right 'self' type in various places. When
calling a Self-returning class method on a subclass existential,
the following has to happen correctly:
- The existential is opened to produce an archetype with a superclass
constraint.
- The archetype is upcast to a class type to produce the 'self'
parameter for the call.
- The method call returns a value with the same type as the 'self'
parameter.
- The return value is downcast to the opened archetype.
- The opened archetype is converted back to an existential.
Some SILGen tests in an upcoming patch exercise this code path.
An earlier patch fixed the case where some tuple elements
were lvalue types. However this only looked into tuples
nested one level deep, when a more correct fix checks the
lvalue recursive property of the type.
This consolidates calculations which need to look at every
protocol in an existential type. Soon we will also have to
deal with superclass constrained existentials, so start
updating call sites that look at all protocols to use the
new ExistentialLayout and correctly handle a class constraint
as well.
Also, eventually I will kill off the AnyObject protocol and
model it as a protocol composition with no protocols or
superclass, but the requiresClass() flag set.
This is not quite modeled this way yet and AnyObject still
exists, but the new abstraction is a step in the right
direction.
Don't pass in the opened type; instead have the caller call
simplifyType() if needed. Also, make computeSubstitutions()
bail out if there's no generic signature, which allowed
unifying several generic vs non-generic code paths.
Hopefully there is enough short circuiting in there now that
we're not doing any extra work in the non-generic case.
