Non-‘@objc’ ‘dynamic’ has been allowed since Swift 5, but there’s no
reason to tie it to the language mode (Swift >= 5).
Fixes rdar://problem/50348013.
These observer methods were used by external clients. Since we no longer
have the granularity between diagnostics and optimization, they're
rolled into a new observer callback, `performedSILProcessing`.
This (effectively) reverts commit 7b43e1d04d.
That is, if a struct's generic requirements can't be deserialized,
drop the struct. This is the same logic that's already in play for
enums and (as of the previous commit) classes, so it should be pretty
well tested by now. (Hence the sole test I'm adding here, snuck into
superclass.swift because it's a superclass /constraint/ being tested.)
I don't know of any outstanding issues caused by this, but it was
weird to have it for enums and classes but not structs, so here we
are.
...instead of crashing. Also drop the class if its generic
requirements depend on a type that can't be loaded (instead of
crashing).
rdar://problem/50125674
The change replaces 'set bit enumeration' with arithmetic
and bitwise operations. For example, the formula
'(((x & -x) + x) & x) ^ x' can be used to find the rightmost
contiguous bit mask. This is essentially the operation that
SetBitEnumerator.findNext() performed.
Removing this functionality reduces the complexity of the
ClusteredBitVector (a.k.a. SpareBitVector) implementation and,
more importantly, API which will make it easier to modify
the implementation of spare bit masks going forward. My end
goal being to make spare bit operations work more reliably on
big endian systems.
Side note:
This change modifies the emit gather/scatter functions so that
they work with an APInt, rather than a SpareBitVector, which
makes these functions a bit more generic. These functions emit
instructions that are essentially equivalent to the parallel bit
extract/deposit (PEXT and PDEP) instructions in BMI2 on x86_64
(although we don't emit those directly currently). They also map
well to bitwise manipulation instructions on other platforms (e.g.
RISBG on IBM Z). So we might find uses for them outside spare bit
manipulation in the future.
On Windows, there are multiple variants of the C runtime that must be
explicitly specified and consistently used from the runtime to the
application. The new `-libc` option allows us to control the linking
phase by correctly embedding the requested library to be linked. It is
made into a required parameter on Windows and will add in the
appropriate flags for the imported C headers as well. This ensures that
the C library is not incorrectly linked.
The logic I had here checked whether an extension used an
implementation-only type whenever there was a declaration within that
extension that needed checking...but unfortunately that included not
just PatternBindingDecls (whose access is filtered at a later step)
but things like IfConfigDecls (#if). Change this to only check
signatures of extensions with ABI-public members, something that is
tested once when visiting an ExtensionDecl.
Additionally, skip AccessorDecls entirely, since they'll be tested
as part of the corresponding subscript or var. This saves a duplicate
diagnostic.
rdar://problem/50541589
I thought it would be useful to allow some uses of a module to be
'@_implementationOnly' and others to not be in case someone wanted to
change from one to the other gradually, but it turns out that if
you're trying to /make/ an import implementation-only, you want to
know everywhere you used it.
rdar://problem/50748157
When backward deploying to an OS that may not have these entry points, weak-link them so that they
can be used conditionally in availability contexts that check for them.
rdar://problem/50731151
Check the availability of decls that declare an opaque return type to ensure they deploy to a
runtime that supports opaque types.
rdar://problem/50731151
Introduce an attribute @_disfavoredOverload that can be used to state
that a particular declaration should be avoided if there is a
successful type-check for a non-@_disfavoredOverload. It's a way to
nudge overload resolution away from particular solutions.
This lets us make some more assumptions in the next commit, but I
think it's also just a nice cleanup to /not/ allow random predicates
here.
There were three callers of this API:
- PrintAST, which was using PrintOptions::shouldPrint but /also/
incorrectly notifying listeners that a declaration would be skipped.
- (IDE) Interface generation, which uses PrintOptions::shouldPrint to
count how many "inherits" there will be.
- SwiftDocSupport's reportRelated, which does no filtering at all.
Creating a PrintOptions here is a little more expensive, but still.
No intended functionality change.
