This is dead code and can be re-added if it is needed. Right now though there
really isnt a ValueOwnershipKind that corresponds to deallocating and I do not
want to add a new ValueOwnershipKind for dead code.
Instead of creating an archetype builder with a module---which was
only used for protocol conformance lookups of concrete types
anyway---create it with a LookupConformanceFn. This is NFC for now,
but moves us closer to making archetype builders more canonicalizable
and reusable.
Piggybacks some resilience diagnostics onto the availability
checking code.
Public and versioned functions with inlineable bodies can only
reference other public and internal entities, since the SIL code
for the function body is serialized and stored as part of the
module.
This includes @_transparent functions, @_inlineable functions,
accessors for @_inlineable storage, @inline(__always) functions,
and in Swift 4 mode, default argument expressions.
The new checks are a source-breaking change, however we don't
guarantee source compatibility for underscored attributes.
The new ABI and tests for the default argument model will come in
subsequent commits.
The "representative" potential archetype chosen by the archetype
builder is essentially chosen at random, because this is a union-find
data structure. Therefore, it should never be used as the "archetype
anchor", which is the canonical representative of an equivalence class
that affects both semantics and ABI.
Decouple the computation of the archetype anchor from the
representative, and verify that the chosen archetype anchor no worse
than all other choices.
The "representative" potential archetype chosen by the archetype
builder is essentially chosen at random, because this is a union-find
data structure. Therefore, it should never be used as the "archetype
anchor", which is the canonical representative of an equivalence class
that affects both semantics and ABI.
Decouple the computation of the archetype anchor from the
representative, and verify that the chosen archetype anchor no worse
than all other choices.
The introduction of `llvm.memcpy.element.atomic` would cause an
ambiguity when we did the lookup with the trailing `.` for the type
parameters. The intrinsic itself is not necessarily suffixed with the
type in the identifier. Look up the identifier by explicit name.
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 reverts the contents of #5778 and replaces it with a far simpler
implementation of condition resolution along with canImport. When
combined with the optimizations in #6279 we get the best of both worlds
with a performance win and a simpler implementation.
Teach the serialized form of ArchetypeType about its owning generic
environment, so we can wire up the generic environment of (primary)
archetypes eagerly (at the point of deserialization) rather than when
we form the generic environment. This ensures that there is no point
at which we have a (non-opened-existential) archetype without a
generic environment.
... except that the type reconstruction code creates such archetypes.
Also rename ASTWalker::shouldWalkIntoFunctionGenericParams() to shouldWalkIntoGenericParams() since it's now used when walking NominalTypeDecl (not just AbstractFunctionDecl).
* Pack the bits for IfConfigDecls into Decl
* Don't open symbols into a module when evaluating canImport statements
The module loaders now have API to check whether a given module can be
imported without importing the referenced module. This provides a
significant speed boost to condition resolution and no longer
introduces symbols from the referenced module into the current context
without the user explicitly requesting it.
The definition of ‘canImport’ does not necessarily mean that a full
import without error is possible, merely that the path to the import is
visible to the compiler and the module is loadable in some form or
another.
Note that this means this check is insufficient to guarantee that you
are on one platform or another. For those kinds of checks, use
‘os(OSNAME)’.
These are used from within constraint system code, and for those uses we
need to be reading from the constraint system type map.
Add the parallel constraint system interfaces that call into the
Expr interfaces with the appropriate accessors.
Using `-dump-parse` on `func foo<T>(bar: T) {}` results in:
```
(source_file
(func_decl "foo(bar:)"<T>
(parameter_list
(parameter "bar" apiName=bar))
(brace_stmt)))
```
Notice there is no space between "foo(bar:)" and <T>.
Add a space to correct the formatting error.
Fixes assertion failures in SILGen and the optimizer with this
exotic setup:
protocol P {
associatedtype T : Q
}
protocol Q {
func requirement<U : P>(u: U) where U.T == Self
}
Here, we only have a U : P conformance, and not Self : Q,
because Self : Q is available as U.T : Q.
There were three problems here:
- The SIL verifier was too strict in verifying the generic signature.
All that matters is we can get the Self parameter conformance, not
that it's the first requirement, etc.
- GenericSignature::getSubstitutionMap() had a TODO concerning handling
of same-type constraints -- this is the first test-case I've found
that triggered the problem.
- GenericEnvironment::getSubstitutionMap() incorrectly ignored
same-type constraints where one of the two types was a generic
parameter.
Fixes <https://bugs.swift.org/browse/SR-3321>.
Previously all of the following would strip off varying amounts of
MetatypeType, LValueType, InOutType, DynamicSelfType, etc:
- ConstraintSystem::performMemberLookup()
- ConstraintSystem::lookupMember()
- TypeChecker::lookupMember()
- DeclContext::lookupQualified()
- Type::getContextSubstitutions()
The problem is that the higher level methods that took a lookup type
would call the lower level methods, and post-process the result using
the given lookup type. Since different levels of sugar were stripped,
it made the code hard to reason about and opened up edge cases, eg
if a DynamicSelfType or InOutType appears where we didn't expect it.
Since filtering out static/instance and mutating/nonmutating members
is done at higher levels, there's no reason for these name lookup
operations to accept anything other than nominal types, existentials
and archetypes.
Make this so with assertions, and deal with the fallout.
Not sure why but this was another "toxic utility method".
Most of the usages fell into one of three categories:
- The base value was always non-null, so we could just call
getCanonicalType() instead, making intent more explicit
- The result was being compared for equality, so we could
skip canonicalization and call isEqual() instead, removing
some boilerplate
- Utterly insane code that made no sense
There were only a couple of legitimate uses, and even there
open-coding the conditional null check made the code clearer.
Also while I'm at it, make the SIL open archetypes tracker
more typesafe by passing around ArchetypeType * instead of
Type and CanType.
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.
There's no need to walk up from a function or type context -- if
no generic signature (or environment) is set, the parent won't have
one, either, and if we're in the middle of validating the child
context, using the parent's signature or environment to resolve
dependent types is just wrong.
We might allow protocols inside non-generic class/struct/enum
declarations eventually; there's no conceptual difficulty, just
some IRGen and Serialization work that has to happen first.
Also, this fixes a crasher :-)
If one of the associated types is witnessed by a generic parameter
from the function's scope, make sure it maps down to an ErrorType
instead of leaving it as a type parameter, which triggers an
assertion.
Eventually we'll plumb it through properly.
We "fake" a conformance of UnresolvedType to any protocol.
Instead of returning a concrete conformance, return an
abstract conformance. The concrete conformance had several
problems leading to further crashes:
- The DC was set to a module, not a type declaration context,
since there is not type declaration context here.
- The conformance was marked complete even though it was missing
inherited conformances.
