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.
We can get partially-validated ASTs when they are created by the Clang
importer, but not otherwise needed or after new code can be
introduced. Avoid doing the "checked" verification on such ASTs, to
make assertions-enabled builds more useful for testing.
This is the wrong long-term solution: the AST verifier should tolerate
partially-type-checked ASTs at a finer granularity, but doing so is a
larger project than I can take on at the moment.
Add a 'hasExplicitAnyObject()' bit to ProtocolCompositionType
to represent canonical composition types containing '& AnyObject'.
Serialize this bit and take it into account when building
ExistentialLayouts.
Rename ProtocolCompositionType::getProtocols() to getMembers()
since it can contain classes now, and update a few usages that
need further attention with FIXMEs or asserts.
For now, nothing actually constructs these types, and they will
trigger arounds asserts. Upcoming patches will introduce support
for this.
Specifically we only allow it as an argument to a TupleExpr and a ParenExpr and
can have the following forms:
(inject_into_optional (*_to_pointer ...))
or
(*_to_pointer ...)
This will allow for inout_to_pointer and array_to_pointer to be pattern matched
robustly and then special cased in SILGenApply.
The reason why these expressions need to be special cased is that they can
perform inout_expr accesses while going through code paths in SILGenApply where
it is expected that inout accesses do not occur.
rdar://29870610
Make sure that a variable or subscript overrides something iff
the accessors are marked as overrides also. This would have saved
me some debugging time earlier.
I’m not sure if this check makes sense with the new mangler.
I removed it because I could not trivially translate this check to the new mangler.
If it turns out that the check makes sense, we can re-add it.
A lot of files transitively include Expr.h, because it was
included from SILInstruction.h, SILLocation.h and SILDeclRef.h.
However in reality most of these files don't do anything
with Exprs, especially not anything in IRGen or the SILOptimizer.
Now we're down to 171 files in the frontend which depend on
Expr.h, which is still a lot but much better than before.
This is a bit of a hack to dodge an assertion. In essence, it's a
harmless hack, but we'd like to make the handling of optional and
unavailable requirements more rigorous.
The protocol conformance checker verifies that all of the requirements
in the protocol's requirement signature are fulfilled. Save the
conformances from that check into the NormalProtocolConformance,
because this is the record of how that concrete type satisfies the
protocol requirements.
Compute, deserialize, and verify this information, but don't use it
for anything just yet. We'll use this to eliminate the "inherited
protocol map" and possibility some redundant type-witness
information.
...which don't need to have witnesses.
I can't seem to come up with a reduced test case for this one, but it
does fix a verifier failure in the larger project that triggered this.
rdar://problem/29744313
The typedef `swift::Module` was a temporary solution that allowed
`swift::Module` to be renamed to `swift::ModuleDecl` without requiring
every single callsite to be modified.
Modify all the callsites, and get rid of the typedef.
This is intended to have no functional effect, but there was a
minor change to a diagnostic in invalid code in the tests for the
unfinished ASTScope code; I hope I didn't break anything more
fundamental there.
If the 'override' attribute appears on an invalid decl,
it is removed at the start of typeCheckDecl(). However if
the decl is nested inside a multi-statement closure which
is invalid for other reasons, we may have validated it
but not type checked it, in which case we don't want to
crash in the verifier.
withoutActuallyEscaping has a signature like `<T..., U, V, W> (@nonescaping (T...) throws<U> -> V, (@escaping (T...) throws<U> -> V) -> W) -> W, but our type system for functions unfortunately isn't quite that expressive yet, so we need to special-case it. Set up the necessary type system when resolving an overload set to reference withoutActuallyEscaping, and if a type check succeeds, build a MakeTemporarilyEscapableExpr to represent it in the type-checked AST.
The AST verifier is causing late deserialization of generic
environments, which in turn is causing the Clang importer to import
more classes, which don't end up getting proper destructors... causing
an AST verification error. For now, disable this AST verifier check,
because it's causing lots of brokenness rdar://problem/29741827.
A proper fix will take a bit more work.
- The DeclContext versions of these methods have equivalents
on the DeclContext class; use them instead.
- The GenericEnvironment versions of these methods are now
static methods on the GenericEnvironment class. Note that
these are not made redundant by the instance methods on
GenericEnvironment, since the static methods can also be
called with a null GenericEnvironment, in which case they
just assert that the type is fully concrete.
- Remove some unnecessary #includes of ArchetypeBuilder.h
and GenericEnvironment.h. Now changes to these files
result in a lot less recompilation.
That is, a property in a protocol with type 'Self' doesn't promise
that the result type always matches the type of 'self', just the type
of the conforming type. (For a method, a result type of 'Self' /does/
mean you get back a type based on the dynamic 'self', like
Objective-C's 'instancetype'.) This applies even to get-only
properties, and so their accessors should be treated consistently.
With this change, we can have the AST verifier check that getter and
setter types always match up with their property.
While not strictly needed for type checking, it's extremely useful for
debugging and verification to know what context a particular generic
environment is associated with. This information was in a kludgy side
table, but it's worth a pointer in GenericEnvironment to always have
it available.
First, ensure all ParamDecls that are synthesized from scratch are given
both a contextual type and an interface type.
For ParamDecls written in source, add a new recordParamType() method to
GenericTypeResolver. This calls setType() or setInterfaceType() as
appropriate.
Interestingly enough a handful of diagnostics in the test suite have
improved. I'm not sure why, but I'll take it.
The ParamDecl::createUnboundSelf() method is now only used in the parser,
and no longer sets the type of the self parameter to the unbound generic
type. This was wrong anyway, since the type was always being overwritten.
This allows us to remove DeclContext::getSelfTypeOfContext().
Also, ensure that FuncDecl::getBodyResultTypeLoc() always has an interface
type for synthesized declarations, eliminating a mapTypeOutOfContext()
call when computing the function interface type in configureInterfaceType().
Finally, clean up the logic for resolving the DynamicSelfType. We now
get the interface or contextual type of 'Self' via the resolver, instead
of always getting the contextual type and patching it up inside
configureInterfaceType().
After recent changes, this asserts on all decls that are not VarDecls,
so we can just enforce that statically now. Interestingly, this turns
up some dead code which would have asserted immediately if called.
Also, replace AnyFunctionRef::getType() with
AnyFunctionRef::getInterfaceType(), since the old
AnyFunctionRef::getType() would just assert when called on
a Decl.
This handles situation when overload for the subscript hasn't been resolved
by constraint solver, such might happen, for example, if solver was allowed to
produce solutions with free or unresolved type variables (e.g. when running diagnostics).
Resolves: <rdar://problem/27329076>, <rdar://problem/28619118>, <rdar://problem/2778734>.
