We still use the old layout for NameAliasType for builtin types, so
rename the Layout struct and corresponding code to describe its new
(more restricted) purpose.
Rather than relying on the NameAliasType we get by default for references
to non-generic typealiases, use BoundNameAliasType consistently to handle
references to typealiases that are formed by the type checker.
This doesn't have a specific effect now, because all of these places
are likely to only see NameAliasType, but it is refactoring with the
intent of eliminating NameAliasType entirely.
Introduce a new Type node, BoundNameAliasType, which describes a
reference to a typealias that requires substitutions to produce the
underlying type. This new type node is used both for references to
generic typealiases and for references to (non-generic) typealiases
that occur within generic contexts, e.g., Array<Int>.Element.
At present, the new type node is mainly useful in preserving type
sugar for diagnostics purposes, as well as being reflected in other
tools (indexing, code completion, etc.). The intent is to completely
replace NameAliasType in the future.
We have a predicate in ClassDecl, 'inheritsSuperclassInitializers',
that is used in a few places to decide if we need to do lookups into a
superclass to find all relevant initializers. That's useful, but the
actual work being computed in that function is almost identical to the
work done in figuring out whether the class has provided all its
superclass's /required/ initializers, which is part of the type
checker operation 'resolveImplicitConstructors'. Furthermore,
'inheritsSuperclassInitializers' is /already/ calling
'resolveImplicitConstructors' because those implicit constructors
might affect the result.
Simplify this whole mess and prevent further inconsistencies like the
previous commit by just making 'resolveImplicitConstructors' decide
whether superclass convenience initializers are inherited. It does
make that function more complicated, but with the benefit of not
having duplication anymore.
No intended user-visible change, except that this bit is now
serialized instead of being recomputed, which means the module format
changed.
A public subscript might have generic indexes that aren't unconditionally Hashable, or might use indexes that are retroactively made Hashable, so the property descriptor on the implementer's side can't always resiliently provide this information to the final instantiated KeyPath.
This turns all resilient types into fixed layouts thus allowing LLDB
to query their size. The long-term plan is to use remote mirrors for
this unformation instead of swift IRGen, but the library is not yet up
to the task.
rdar://problem/36663932
If a property or subscript is referenceable from other modules, we need to give it a descriptor so that we can reliably build an equivalent key path in or out of that module.
There are some cases that we should handle but don't yet:
- Global and static properties ought to be key-path-able someday, so we should make descriptors for them, but this might need a new key path component kind.
- Subscripts with indexes that aren't Hashable in the current module ought to get descriptors too, in case we ever support non-hashable key path components, and also because a generic subscript might be substituted with Hashable types by an external user, or an external module might post-hoc extend a type to be Hashable, so we really need to change things so that the client supplies the hashing and equality implementations for the indexes instead of the descriptor.
Will be used to verify that withoutActuallyEscaping's block does not
escape the closure.
``%escaping = is_escaping_closure %closure`` tests the reference count. If the
closure is not uniquely referenced it prints out and error message and
returns true. Otherwise, it returns false. The returned result can be
used with a ``cond_fail %escaping`` instruction to abort the program.
rdar://35525730
Previously this just relied on serialization::VarDeclSpecifier being
identical to swift::VarDecl::Specifier, which is presumably true, but
also fragile.
The obsolete llvm::HashString() was equivalent to
llvm::djbHash(seed=0) and was removed from llvm. This patch replaces
all occurences of llvm::HashString() with llvm::djbHash(seed=0), no
functional change.
The default seed of llvm::djbHash() is supposed to yield a higher
quality result that using seed=0, but changing it looks like it
affects the ordering of SIL serialization.
