For the moment, update the sole caller to not infer Any in cases where
neither argument was Any. This is in part because not all the cases are
handled here and the result of inferring Any will be to miss appropriate
bindings in certain cases. It is also in part because by inferring Any
we may end up deferring diagnostics until later in a function, which may
result in very hard to understand diagnostics for users.
This will be revisted once all the cases are properly handled here.
For enums, we now only call _mixInt on the computed hash value if
it has associated values; for enums without associated values, we
use the ordinal alone, as before.
Currently edge related to the parameter bindings is contracted
without properly checking if newly created equivalence class has
the same inout & l-value requirements. This patch improves the
situation by disallowing contraction of the edges related to parameter
binding constraint where left-hand side has `inout` attribute set.
Such guarantees that parameter can get `inout` type assigned when
argument gets `l-value` type.
Resolves: rdar://problem/33429010
Once we compute a generic signature from a generic signature builder,
all queries involving that generic signature will go through a separate
(canonicalized) builder, and the original builder can no longer be used.
The canonicalization process then creates a new, effectively identical
generic signature builder. How silly.
Once we’ve computed the signature of a generic signature builder, “register”
it with the ASTContext, allowing us to move the existing generic signature
builder into place as the canonical generic signature builder. The builder
requires minimal patching but is otherwise fully usable.
Thanks to Slava Pestov for the idea!
Funnel all places where we create a generic signature builder to compute
the generic signature through a single entry point in the GSB
(`computeGenericSignature()`), and make `finalize` and `getGenericSignature`
private so no new uses crop up.
Tighten up the signature of `computeGenericSignature()` so it only works on
GSB rvalues, and ensure that all clients consider the GSB dead after that
point by clearing out the internal representation of the GSB.
The full state of the GSB isn’t all that useful for testing, creates a ton of noise and gets in the way of some cleanups we’d like to make in the interface.
Stop dumping it as part of `-debug-generic-signatures`.
An unconstrained extension will always have the same generic signature as the
nominal type it extends. Rather can constructing a new generic signature
builder to tell us that, just re-use the generic signature. Improves
type-checking performance of the standard library by 15%.
When type-checking a function or subscript that itself does not have generic
parameters (but is within a generic context), we were creating a generic
signature builder which will always produce the same generic signature as
the enclosing context. Stop creating that generic signature builder.
Instead, teach the CompleteGenericTypeResolver to use the generic signature
+ the canonical generic signature builder for that signature to resolve
types, which also eliminates some extraneous re-type-checking.
Improves type-checking performance of the standard library by 36%.
- Use isWholeModuleCompilation in CompilerInstance::createSILModule
- Remove some unneeded timers
- Improve the comment in CompilerInstance::parseAndCheckTypes
- Remove needless const ref to an llvm::function_ref parameter in forEachSourceFileIn
- Remove "OfFile" from "finishTypeCheckingOfFile"
These will be used for unit-testing the Type::join functionality in the
type checker. The result of the join is replaced during constraint
generation with the actual type.
There is currently no checking for whether the arguments can be used to
statically compute the value, so bad things will likely happen if
e.g. they are type variables. Once more of the basic functionality of
Type::join is working I'll make this a bit more bullet-proof in that
regard.
They include:
// Compute the join of T and U and return the metatype of that type.
Builtin.type_join<T, U, V>(_: T.Type, _: U.Type) -> V.Type
// Compute the join of &T and U and return the metatype of that type.
Builtin.type_join_inout<T, U, V>(_: inout T, _: U.Type) -> V.Type
// Compute the join of T.Type and U.Type and return that type.
Builtin.type_join_meta<T, U, V>(_: T.Type, _: U.Type) -> V.Type
I've added a couple simple tests to start off, based on what currently
works (aka doesn't cause an assert, crash, etc.).
This hack was originally intended to distinguish between functions
of single arguments that were overloaded on AnyObject and AnyObject?.
Nowadays, CSRanking is capable of handling that itself, and the check
this function was using to detect AnyObject no longer works.
Fixes crashes on some invalid code that comes up with piles of recursive
constraints.
(cherry picked from commit 81355938761fcc2deec9c0330581263ac4a4dd5d)
When inferring associated type witnesses, we depend (too much) on the
identity of the associated types that show up in potential witnesses.
Rewrite dependent member types that refer to associate types of other
related protocols into dependent member types that refer into the protocol
for the conformance being checked (if it has a same-named associated type).
This isolates us somewhat from the effects of the canonicalization algorithm.
(cherry picked from commit f50183d5a4bc50a20b4afd7e6a882d63a15504ee)
Instead of inlining a series of string comparisons, we call a library function which does the string lookup on a table of static strings.
This reduces the code size of those initializers dramatically.
Performance wise it's slower than before, because the string comparisons are not inlined anymore.
Because of the way we modeled the 'class' constraint in Swift <= 4, we
allowed both 'class' and 'AnyObject' to be specified on a protocol,
even in Swift 4 when they became equivalent. Recent refactoring
started rejecting such code; allow it now.
Fixes rdar://problem/34496151.
The synthesized declarations should inherit the @_versioned attribute
from the type, just like they inherit access control.
Fixes <rdar://problem/34342955>.
We can wind up in a situation where the base of a keypath
application is concrete but is being applied to a keypath
with an existential source type. Coerce the base to the
intended type if necessary when building the final subscript
expression.
Resolves SR-5878.
* [SR-5856] Fix diagnostic message for static stored properties not supported in protocol extensions
* fix test failure in decl/var/properties.swift
this looks like a better place to test the new behavior, so removing changes to static_var.swift
If the best bindings we could get on the current step are bindings
to literal type without any other type variable involved, let's try
to attempt them right away, that should help to prune search space.
Change the potential binding ranking logic to prefer type variables
which don't have other type variables related to them, but have literal
bindings, over the ones that do have other type variables.
Previously we stored this inside each default argument
initializer context. This was overkill, because it is
the same for all default arguments in a single function,
and also insufficient, because initializer contexts are
not serialized and thus not available in SILGen when
the function is in a different module.
Instead store it directly inside the function and
serialize it.
NFC for now, since SILGen isn't using this yet.
- Remove dead `if !genericEnv` checks
- Do conformance checks for subscript indexes `InExpression`
- Use `GenericEnvironment::mapTypeOutOfContext` static method instead of null checking everywhere
