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.
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
Adds a NumStoredPropertiesQueries stat.
Adds a test case for an increasing number of lazy stored class
properties. Each property requires a formal access within the
initializer. This would manifest as cubic behavior in
AccessEnforcementOpts, which scales as O(1.5) in the above stat.
If a class does not have a custom @objc name, objc_getClass() can find
it at runtime by calling the Swift runtime's metadata demangler hook.
This avoids the static initializer on startup. If the class has a
custom runtime name we still need the static initializer unfortunately.
Fixes <rdar://problem/49660515>.
Sema no longer adds conformances to a per-SourceFile list that it thinks
are going to be "used" by SILGen, IRGen and the runtime. Instead, previous
commits already ensure that SILGen determines the set of conformances to be
emitted, triggering conformance checking as needed.
As pointed out on a recent JIRA, crash traces don't mention what
version of Swift you were running. Usually that can be gleaned from
the path, but not always.
form SerializedModuleLoader into its own ModuleLoader class. (NFC-ish)
This gives better control over the order in which the various module
load mechanisms are applied.
...by coalescing duplicates and dropping conflicts. Both cases can
happen with "expected-error 2 {{...}}": we might get multiple fix-its
providing the same new message, or one message might have diverged
into two, giving us incompatible changes.
Windows requires a handle to get memory usage, so do a slight refactor
to collect the child's memory usage as it exits instead of as the parent
is cleaning up.
This is an attribute that gets put on an import in library FooKit to
keep it from being a requirement to import FooKit. It's not checked at
all, meaning that in this form it is up to the author of FooKit to
make sure nothing in its API or ABI depends on the implementation-only
dependency. There's also no debugging support here (debugging FooKit
/should/ import the implementation-only dependency if it's present).
The goal is to get to a point where it /can/ be checked, i.e. FooKit
developers are prevented from writing code that would rely on FooKit's
implementation-only dependency being present when compiling clients of
FooKit. But right now it's not.
rdar://problem/48985979
I did not wire anything up to it.
This is in preparation for fixing issues around SILGenPattern fallthrough
emission and bad rename/edit all in scope of case stmt var decls. Specifically,
I am going to ensure that we can get from any VarDecl in the following to any
other VarDecl:
switch x {
case .a(let v1, let v2), .b(let v1, let v2):
...
fallthrough
case .c(let v1, let v2), .d(let v1, let v2):
...
}
This will be done by:
1. Pointing the var decls in .d at the corresponding var decls in .c.
2. Pointing the var decls in .c at the corresponding var decls in .b.
3. Pointing the var decls in .b at the corresponding var decls in .a.
4. Pointing the var decls in .a at the case stmt. Recognizing that we are asking
for the next VarDecl, but have a case stmt, we check if we have a fallthrough
case stmt (which I am going to add in a subsequent commit). If so, follow down
the fallthrough case stmts until you find a fallthrough case stmt that doesn't
fallthrough itself and then return the corresponding var decl in the last case
label item in that var decl (in the above .d).
I also put in some asserts to make sure that we never try to vend a parent value
that is a nullptr.
rdar://47467128
This is just for use in the debugger when one may want to know what is in the
current scope. The order is not guaranteed but at least it can provide /some/
info ignoring that property. These are no-ops when not in asserts and I put in a
compile time warnign to make sure it is not used in the actual code base.
When loading a module supporting multiple targets, the module loader now looks for a file named with a normalized version of the target triple first, and only falls back to the architecture name if the normalized triple is not found.
`cl` objects to the initialization of the templated type differing in storage
class due to the indication of `constexpr`. `constexpr` does not give the value
itself a `const` storage class. However, because the value is not initialized
inline, it does not like the `constexpr` attribute. Apply the `constexpr` only
on clang, and correct the storage to `const`.
<rdar://problem/46548531> Extend @available to support PackageDescription
This introduces a new private availability kind "_PackageDescription" to
allow availability testing by an arbitary version that can be passed
using a new command-line flag "-swiftpm-manifest-version". The semantics
are exactly same as Swift version specific availability. In longer term,
it maybe possible to remove this enhancement once there is
a language-level availability support for 3rd party libraries.
Motivation:
Swift packages are configured using a Package.swift manifest file. The
manifest file uses a library called PackageDescription, which contains
various settings that can be configured for a package. The new additions
in the PackageDescription APIs are gated behind a "tools version" that
every manifest must declare. This means, packages don't automatically
get access to the new APIs. They need to update their declared tools
version in order to use the new API. This is basically similar to the
minimum deployment target version we have for our OSes.
This gating is important for allowing packages to maintain backwards
compatibility. SwiftPM currently checks for API usages at runtime in
order to implement this gating. This works reasonably well but can lead
to a poor experience with features like code-completion and module
interface generation in IDEs and editors (that use sourcekit-lsp) as
SwiftPM has no control over these features.
