The Bitstream part of Bitcode moved to llvm/Bitstream in LLVM. This
updates the uses in swift.
See r365091 [Bitcode] Move Bitstream to a separate library.
(cherry picked from commit 1cd8e19357)
* Fix Swift following bitstream reader API update
Upstream change in rL364464 broke downstream Swift.
(cherry picked from commit 50de105bf1)
Conflicts:
lib/Serialization/Deserialization.cpp
lib/Serialization/ModuleFile.cpp
tools/driver/modulewrap_main.cpp
This PR introduces `@differentiable` attribute to mark functions as differentiable. This PR only contains changes related to parsing the attribute. Type checking and other changes will be added in subsequent patches.
See https://github.com/apple/swift/pull/27506/files#diff-f3216f4188fd5ed34e1007e5a9c2490f for examples and tests for the new attribute.
Witness matching is a source of a lot of ad-hoc cycles, and mixes the
logic that performs resolution, caching, validation, and cycle detection into one
place. To make matters worse, some checkers kick off other checks in
order to cache work for further declarations, and access an internal
cache on their subject conformance for many requirements at once, or
sometimes just one requirement.
None of this fits into the request evaluator's central view of the
caching. This is further evidenced by the fact that if you attempt to
move the caching step into the evaluator, it overcaches the same
witness and trips asserts.
As a start, define requests for the resolution steps, and flush some
hacks around forcing witness resolution. The caching logic is mostly
untouched (the requests don't actually cache anything), but some cycle
breaking is now handled in the evaluator itself. Once witness matching
has been refactored to cache with the evaluator, all of these hacks can
go away.
My urge to destroy the LazyResolver outweighs the compromises here.
This non-user-facing attribute is used to denote pointer parameters
which do not accept pointers produced from temporary pointer conversions
such as array-to-pointer, string-to-pointer, and in some cases
inout-to-pointer.
By convention, most structs and classes in the Swift compiler include a `dump()` method which prints debugging information. This method is meant to be called only from the debugger, but this means they’re often unused and may be eliminated from optimized binaries. On the other hand, some parts of the compiler call `dump()` methods directly despite them being intended as a pure debugging aid. clang supports attributes which can be used to avoid these problems, but they’re used very inconsistently across the compiler.
This commit adds `SWIFT_DEBUG_DUMP` and `SWIFT_DEBUG_DUMPER(<name>(<params>))` macros to declare `dump()` methods with the appropriate set of attributes and adopts this macro throughout the frontend. It does not pervasively adopt this macro in SILGen, SILOptimizer, or IRGen; these components use `dump()` methods in a different way where they’re frequently called from debugging code. Nor does it adopt it in runtime components like swiftRuntime and swiftReflection, because I’m a bit worried about size.
Despite the large number of files and lines affected, this change is NFC.
* [Sema] Factor out shouldAttemptInitializerSynthesis
This makes sure we don't attempt to synthesize
a memberwise or default initializer for an invalid
decl, or one in a module interface.
* [Sema] Requesify inheritsSuperclassInitializers
This commit introduces a request for computing
whether a class inherits both designated and
convenience initializers from its superclass.
The shared logic of finding initializers which the
subclass hasn't overriden has been factored out
into `collectNonOveriddenSuperclassInits`.
* Cleanup addImplicitInheritedConstructorsToClass
This commit removes some code that's no longer
needed. In addition, now that we've requestified
`inheritsSuperclassInitializers`, we can directly
diagnose on non-inherited required convenience
inits within the loop.
* Inherited init synthesis no longer deals with clang decls
Now that the computation of
`inheritsSuperclassInitializers` has been split off
into a request, we can avoid calling
`addImplicitInheritedConstructorsToClass` for clang
decls.
* Address review feedback
Continue to cache the InheritsSuperclassInits bit
on the AST.
Use ProtocolConformanceRef::forInvalid() in implementations only as a semantic signal. In one place, use the default constructor to drop the final use of Optional<ProtocolConformanceRef>.
ProtocolConformanceRef already has an invalid state. Drop all of the
uses of Optional<ProtocolConformanceRef> and just use
ProtocolConformanceRef::forInvalid() to represent it. Mechanically
translate all of the callers and callsites to use this new
representation.
https://forums.swift.org/t/improving-the-representation-of-polymorphic-interfaces-in-sil-with-substituted-function-types/29711
This prepares SIL to be able to more accurately preserve the calling convention of
polymorphic generic interfaces by letting the type system represent "substituted function types".
We add a couple of fields to SILFunctionType to support this:
- A substitution map, accessed by `getSubstitutions()`, which maps the generic signature
of the function to its concrete implementation. This will allow, for instance, a protocol
witness for a requirement of type `<Self: P> (Self, ...) -> ...` for a concrete conforming
type `Foo` to express its type as `<Self: P> (Self, ...) -> ... for <Foo>`, preserving the relation
to the protocol interface without relying on the pile of hacks that is the `witness_method`
protocol.
- A bool for whether the generic signature of the function is "implied" by the substitutions.
If true, the generic signature isn't really part of the calling convention of the function.
This will allow closure types to distinguish a closure being passed to a generic function, like
`<T, U> in (*T, *U) -> T for <Int, String>`, from the concrete type `(*Int, *String) -> Int`,
which will make it easier for us to differentiate the representation of those as types, for
instance by giving them different pointer authentication discriminators to harden arm64e
code.
This patch is currently NFC, it just introduces the new APIs and takes a first pass at updating
code to use them. Much more work will need to be done once we start exercising these new
fields.
This does bifurcate some existing APIs:
- SILFunctionType now has two accessors to get its generic signature.
`getSubstGenericSignature` gets the generic signature that is used to apply its
substitution map, if any. `getInvocationGenericSignature` gets the generic signature
used to invoke the function at apply sites. These differ if the generic signature is
implied.
- SILParameterInfo and SILResultInfo values carry the unsubstituted types of the parameters
and results of the function. They now have two APIs to get that type. `getInterfaceType`
returns the unsubstituted type of the generic interface, and
`getArgumentType`/`getReturnValueType` produce the substituted type that is used at
apply sites.
Group info works by matching source filenames with groups, but in
module merging the decls in the module no longer have associated
SourceFiles. Long-term, maybe we should switch this to working on
filenames directly (using the new support provided by swiftsourceinfo
files), but for now just don't crash.
rdar://problem/56592085
