This can trigger recursive conformance checking, which can change
how associated type inference behaves due to ordering issues, as
well as cause crashes.
Dumping should be idempotent.
Replace `NameOfType foo = dyn_cast<NameOfType>(bar)` with DRY version `auto foo = dyn_cast<NameOfType>(bar)`.
The DRY auto version is by far the dominant form already used in the repo, so this PR merely brings the exceptional cases (redundant repetition form) in line with the dominant form (auto form).
See the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es11-use-auto-to-avoid-redundant-repetition-of-type-names) for a general discussion on why to use `auto` to avoid redundant repetition of type names.
Currently inactive, this attribute indicates that a static initializer should be emitted to register the Objective-C metadata when the image is loaded, rather than on first use of the Objective-C metadata. Infer this attribute for NSCoding classes that won’t have static Objective-C metadata or have an @NSKeyedArchiveLegacy attributed.
This introduces a few unfortunate things because the syntax is awkward.
In particular, the period and following token in \.[a], \.? and \.! are
token sequences that don't appear anywhere else in Swift, and so need
special handling. This is somewhat compounded by \foo.bar.baz possibly
being \(foo).bar.baz or \(foo.bar).baz (parens around the type), and,
furthermore, needing to distinguish \Foo?.bar from \Foo.?bar.
rdar://problem/31724243
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.
TODO:
- Select the KeyPath subclass corresponding to the write capability of the key path components
- Figure out an issue with unresolved solutions being chosen with contextually-typed keypaths
- Diagnostic QoI
Fixes:
https://bugs.swift.org/browse/SR-3455https://bugs.swift.org/browse/SR-3663https://bugs.swift.org/browse/SR-4032https://bugs.swift.org/browse/SR-4031
Now, compilation conditions are validated at first, then evaluated. Also,
in non-Swift3 mode, '&&' now has higher precedence than '||'.
'A || B && C || D' are evaluated as 'A || (B && C) || D'.
Swift3 source breaking changes:
* [SR-3663] This used to be accepted and evaluate to 'true' because of short
circuit without any validation.
#if true || true * 12 = try Anything is OK?
print("foo")
#endif
In this change, remaining expressions are properly validated and
diagnosed if it's invalid.
* [SR-4031] Compound name references are now diagnosed as errors.
e.g. `#if os(foo:bar:)(macOS)` or `#if FLAG(x:y:)`
Swift3 compatibility:
* [SR-3663] The precedence of '||' and '&&' are still the same and the
following code evaluates to 'true'.
#if false || true && false
print("foo")
#endif
In the general case, this is done by reverse engineering the "best"
places for requirements to go from the requirement signature.
Conformance/superclass requirements like Self: Foo and Self.T: Bar defer
to the inheritance clause if they appear there, or are attached to the
protocol where clause or T (respectively) if not. A conformance
requirement like Self.T.U: Baz will go on T (if T is declared in the
protocol being printed).
Same-type requirements always go in where clauses, and specifically a
where clause of an associated type that is mentioned in them, so
something simple like Self.T.U == Int goes on the T associated type
definition, and similarly Self.T.U == Self.V will go on V (it's kinda
nonsense, but also more directly connected to V). There's a left-bias
for cases without an "obvious" choice, meaning something more
complicated like Self.T.U == Foo<Self.V> will end up on T.
Requirements that don't fit elsewhere will go on the
protocol (e.g. Self.AssocTypeFromSuperProtocol == Int).
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.
This was a remnant of the old generics implementation, where
all nested types were expanded into an AllArchetypes list.
For quite some time, this method no longer returned *all*
dependent types, only those with generic requirements on
them, and all if its remaining uses were a bit convoluted.
- In the generic specialization code, we used this to mangle
substitutions for generic parameters that are not subject
to a concrete same-type constraint.
A new GenericSignature::getSubstitutableParams()
function handles this use-case instead. It is similar
to getGenericParams(), but only returns generic parameters
which require substitution.
In the future, SubstitutionLists will only store replacement
types for these generic parameters, instead of the list of
types that we used to produce from getAllDependentTypes().
- In specialization mangling and speculative devirtualization,
we relied on SubstitutionLists having the same size and
order as getAllDependentTypes(). It's better to turn the
SubstitutionList into a SubstitutionMap instead, and do lookups
into the map.
- In the SIL parser, we were making a pass over the generic
requirements before looking at getAllDependentTypes();
enumeratePairedRequirements() gives the correct information
upfront.
- In SIL box serialization, we don't serialize the size of the
substitution list, since it's available from the generic
signature. Add a GenericSignature::getSubstitutionListSize()
method, but that will go away soon once SubstitionList
serialization only serializes replacement types for generic
parameters.
- A few remaining uses now call enumeratePairedRequirements()
directly.
The protocol conformance checker verifies that all of the requirements
in the protocol's requirement signature are fulfilled. Save the
conformances from that check into the NormalProtocolConformance,
because this is the record of how that concrete type satisfies the
protocol requirements.
Compute, deserialize, and verify this information, but don't use it
for anything just yet. We'll use this to eliminate the "inherited
protocol map" and possibility some redundant type-witness
information.
SubstitutionList is going to be a more compact representation of
a SubstitutionMap, suitable for inline allocation inside another
object.
For now, it's just a typedef for ArrayRef<Substitution>.
This commit introduces new kind of requirements: layout requirements.
This kind of requirements allows to expose that a type should satisfy certain layout properties, e.g. it should be a trivial type, have a given size and alignment, etc.
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.
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.
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 :-)
* The Clang AST dumper uses a wide variety of colors, including bold
fonts. Use a similar scheme in the Swift AST dumper, by introducing a
`TerminalColor` struct that encompasses both a color and whether it
is bold.
* Currently the only color Swift's ASTDumper uses is red, for patterns.
Add a wider variety of colors, for various purposes. If maintainers
decide to change the color scheme of the output AST, they need only
to modify the color macros.
* Many AST methods take an output stream as an argument. When using
PrintWithColorRAII, these methods could not be used. Add a `getOS()`
method to PrintWithColorRAII, in order to support these methods.
withoutActuallyEscaping has a signature like `<T..., U, V, W> (@nonescaping (T...) throws<U> -> V, (@escaping (T...) throws<U> -> V) -> W) -> W, but our type system for functions unfortunately isn't quite that expressive yet, so we need to special-case it. Set up the necessary type system when resolving an overload set to reference withoutActuallyEscaping, and if a type check succeeds, build a MakeTemporarilyEscapableExpr to represent it in the type-checked AST.
