This structure serves multiple purposes:
a. Allow migrator to speak in the same language with swift-api-digester in terms of API changes.
b. Serialize/Deserialize detected API change items in JSON format.
c. Manage memory after deserializing API change items.
d. Facilitate look up by USRs of APIs under migration.
The structure is tested by round-trip serialization and deserialization.
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.
Replace VariadicTuple and NonVariadicTuple with a single Tuple node.
The variadic property is now part of the tuple element and not of the whole tuple.
Previously, we ignoring 'let', so you would get ridiculous completions:
let var foo: Int
override let func bar() {}
Now, will complete protocol requirements after 'let' the same way we do
for 'var'. For instance property overrides, we only show them if the
'override' keyword is specified. You can't actually override using a
'let', but if the keyword is present then the intention is clear and we
can let the user fix it afterwards when the compiler diagnoses it.
rdar://problem/31091172
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.
Previously it was part of swiftBasic.
The demangler library does not depend on llvm (except some header-only utilities like StringRef). Putting it into its own library makes sure that no llvm stuff will be linked into clients which use the demangler library.
This change also contains other refactoring, like moving demangler code into different files. This makes it easier to remove the old demangler from the runtime library when we switch to the new symbol mangling.
Also in this commit: remove some unused API functions from the demangler Context.
fixes rdar://problem/30503344
When we are getting completions for an initializer at the open
parenthesis, as in:
class C {
func foo<S: Sequence>(x: S) {
String(#^A^#
}
}
after getting all of the overloads for String.init or other applicable
completions for the expression, we leave the stateful expression type
set when performing the last part of code completion, which is getting
other visible declarations at that point.
In this example, C.foo is available to call. However, if the expression
type is left around, we will mistakenly try to use it to substitute
generics of the found declaration, which doesn't make sense, because
foo is a method on C, not String in this case.
We really need to make this part of the compiler less stateful in
the future, or at least formalize the state changes more. It might
also make sense to further separate different kinds of completions
and the mechanisms for getting types, as we reuse the same machinery
for methods and module functions, making a lot of fallback assumptions.
rdar://problem/30137466
This makes the demangler about 10 times faster.
It also changes the lifetimes of nodes. Previously nodes were reference-counted.
Now the returned demangle node-tree is owned by the Demangler class and it’s lifetime ends with the lifetime of the Demangler.
Therefore the old (and already deprecated) global functions demangleSymbolAsNode and demangleTypeAsNode are no longer available.
Another change is that the demangling for reflection now only supports the new mangling (which should be no problem because
we are generating only new mangled names for reflection).
