Wire up the request-evaluator with an instance in ASTContext, and
introduce two request kinds: one to retrieve the superclass of a class
declaration, and one to compute the type of an entry in the
inheritance clause.
Teach ClassDecl::getSuperclass() to go through the request-evaluator,
centralizing the logic to compute and extract the superclass
type.
Fixes the crasher from rdar://problem/26498438.
Introduce some metaprogramming of accessors and generally prepare
for storing less-structured accessor lists.
NFC except for a change to the serialization format.
Ideally `UnboundGenericType` should never be serialized but it is
currently allowed to make generic `typealias` declarations without
specifying generic parameters, so it should be allowed to cross
reference typealias decls in such types as well because `NameAliasType`
can't be used until generic parameters are resolved.
This is only a temporary fix and more comprehensive solution is still
pending here, most likely such declarations should not produce
`UnboundGenericType` but instead should copy generic parameters from
underlying type and produce proper `NameAliasType`.
Resolves: rdar://problem/37384120
This reverts commit bb16ee049d,
reversing changes made to a8d831f5f5.
It's not sufficient to solve the problem, and the choices were to do
something more complicated, or just take a simple brute force
approach. We're going with the latter.
Replace two prominent uses of SubstitutionList, in ConcreteDeclRef and
Witness, with SubstitutionMap. Deal with the myriad places where we
now have substitution maps and need substitution lists (or vice versa)
caused by this change.
Overall, removes ~50 explicit uses of SubstitutionList (of ~400).
Convert NameAliasType’s internal representation from tail-allocating an
array of Substitutions (to be treated as a SubstitutionList) to store a
single SubstitutionMap. Serialize using that SubstitutionMap.
Allow substitution maps to be serialized directly (via an ID), writing out
the replacement types and conformances as appropriate. This is a more
efficient form of serialization than the current SubstitutionList approach,
because it maintains uniqueness of substitution maps within a module file,
and is a step toward eliminating SubstitutionList entirely.
Absence of synthetic generic environment should not affect
serialization of the required substitutions because they can
come from outer requirement context for static members.
Resolves: rdar://problem/36497404
We should always go through the Clang importer to reinstantiate them. Serializing them leads to the possibility of us ending up with multiple conformances with different identities that ought to be equivalent.
We should always go through the Clang importer to reinstantiate them. Serializing them leads to the possibility of us ending up with multiple conformances with different identities that ought to be equivalent.
Add serialization layouts for rare instructions that take extra attributes. We
can continue adding bits to these layout without affecting the layout of the
vast majority of instructions.
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.
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.
We can encounter these when the compiler modifies an inlinable
function to break apart a struct and the struct uses a private
type for one of its fields. It's questionable whether we /should/
handle this, but meanwhile this /is/ a non-intrusive fix that
preserves the performance of non-resilient libraries.
(That is, it appears this worked in Swift 4.0, though perhaps
not all of the same optimizations kicked in.)
https://bugs.swift.org/browse/SR-6874
* Implement #warning and #error
* Fix #warning/#error in switch statements
* Fix AST printing for #warning/#error
* Add to test case
* Add extra handling to ParseDeclPoundDiagnostic
* fix dumping
* Consume the right paren even in the failure case
* Diagnose extra tokens on the same line after a diagnostic directive
Also remove the decl from the known decls and remove a
bunch of code referencing that decl as well as a bunch of other
random things including deserialization support.
This includes removing some specialized diagnostics code that
matched the identifier ImplicitlyUnwrappedOptional, and tweaking
diagnostics for various modes and various issues.
Fixes most of rdar://problem/37121121, among other things.
...rather than the ad hoc CustomTypeNameManglingAttr I was using
before. As John pointed out, the AST should be semantic wherever
possible.
We may someday want to get out of this being an attribute altogether,
or duplicating information that's available in the original Clang
node, by actually storing a reference to that node somewhere. This is
tricky and mixed up with deciding what hasClangNode() or
getClangDecl() would mean, though, so for now the attribute just
carries the information we need.
