We want to be able to adopt
(https://github.com/swiftlang/swift/pull/82225) in the stdlib without
breaking people building at desk with older toolchains, so let's add a
feature flag.
The implementation of Knuth-Bendix completion has had a subtle
bookkeeping bug since I first wrote the code in 2021.
It is possible for two rules to overlap in more than one position,
but the ResolvedOverlaps set was a set of pairs (i, j), where
i and j are the index of the two rules. So overlaps other than
the first were not considered. Fix this by changing ResolvedOverlaps
to a set of triples (i, j, k), where k is the position in the
left-hand side of the first rule.
The end result is that we would incorrectly accept the protocol M3
shown in the test case. I'm pretty sure the monoid that M3 encodes
does not have a complete presentation over any alphabet, so of
course it should not be accepted here.
The concrete nesting limit, which defaults to 30, catches
things like A == G<A>. However, with something like
A == (A, A), you end up with an exponential problem size
before you hit the limit.
Add two new limits.
The first is the total size of the concrete type, counting
all leaves, which defaults to 4000. It can be set with the
-requirement-machine-max-concrete-size= frontend flag.
The second avoids an assertion in addTypeDifference() which
can be hit if a certain counter overflows before any other
limit is breached. This also defaults to 4000 and can be set
with the -requirement-machine-max-type-differences= frontend flag.
This logic was introduced in https://github.com/swiftlang/swift/pull/75135.
The intent was to prevent an implied conformance from overriding an
existing unavailable one, for example in the case of Sendable. Let's
relax this check a bit to only diagnose if the mismatch is in the
unconditional availability, and not OS version.
Fixes rdar://142873265.
This gives us a means to use llvm's intrinsics that implement more niche
SIMD instructions from the standard library, where we cannot use the C
intrinsics headers from clang (because they're in the cpp module).
Turns out we can also get solver-allocated original ErrorTypes through
type resolution. Given the original type is only used for
printing/debugging, let's just fold away any type variables and
placeholders into UnresolvedType (which print as placeholders). This
matches what `Solution::simplifyType` does.
This fixes a small oversight in the type checker's LifetimeDependence
inference. Allow inference on _read accessors even when 'self' is a trivial
type. This is needed because the compiler synthesizes a _read accessor even when
the user defines a getter (this is probably a mistake, but it's easire to just
fix inference at this point). There is no workaround because it defining both a
getter and '_read' is illegal!
extension UnsafeMutableRawBufferPointer {
var mutableBytes: MutableRawSpan {
@_lifetime(borrow self)
get {
unsafe MutableRawSpan(_unsafeBytes: self)
}
}
}
Fixes rdar://153346478 (Can't compile the
UnsafeMutableRawBufferPointer.mutableBytes property)
This teaches ClangImporter to respect the `_Nonnull`/`_Nullable` arguments on templated function parameters.
Previously Swift would only import a non-annotated function overload. Using an overload that has either `_Nonnull` or `_Nullable` would result in a compiler error. The non-annotated overload would get imported with incorrect nullability: Swift would always assume non-null pointers, which was inconsistent with non-templated function parameters, which are mapped to implicitly unwrapped optionals.
With this change all three possible overloads are imported, and all of them get the correct nullability in Swift.
rdar://151939344
This patch makes sure we don't get warnings in strict memory safe mode
when using shared references. Those types are reference counted so we
are unlikely to run into lifetime errors.
rdar://151039766
Currently, when we jump-to-definition for decls that are macro-expanded
from Clang imported decls (e.g., safe overloads generated by
@_SwiftifyImport), setLocationInfo() emits a bongus location pointing to
a generated buffer, leading the IDE to try to jump to a file that does
not exist.
The root cause here is that setLocationInfo() calls getOriginalRange()
(earlier, getOriginalLocation()), which was not written to account for
such cases where a macro is generated from another generated buffer
whose kind is 'AttributeFromClang'.
This patch fixes setLocationInfo() with some refactoring:
- getOriginalRange() is inlined into setLocationInfo(), so that the
generated buffer-handling logic is localized to that function. This
includes how it handles buffers generated for ReplacedFunctionBody.
- getOriginalLocation() is used in a couple of other places that only
care about macros expanded from the same buffer (so other generated
buffers not not relevant). This "macro-chasing" logic is simplified
and moved from ModuleDecl::getOriginalRange() to a free-standing
function, getMacroUnexpandedRange() (there is no reason for it to be
a method of ModuleDecl).
- GeneratedSourceInfo now carries an extra ClangNode field, which is
populated by getClangSwiftAttrSourceFile() when constructing
a generated buffer for an 'AttributeFromClang'. This could probably
be union'ed with one or more of the other fields in the future.
rdar://151020332
`substBase` here can contain type variables or placeholders, avoid
using them as the original ErrorTypes since ErrorTypes cannot be
solver-allocated currently. This only affects type printing so
shouldn't matter much.
Ideally we'd be able to use the llvm interleave2 and deinterleave2
intrinsics instead of adding these, but deinterleave currently isn't
available from Swift, and even if you hack that in, the codegen from
LLVM is worse than what shufflevector produces for both x86 and arm. So
in the medium-term we'll use these builtins, and hope to remove them in
favor of [de]interleave2 at some future point.
This was used a long time ago for a design of a scanner which could rely on the client to specify that some modules *will be* present at a given location but are not yet during the scan. We have long ago determined that the scanner must have all modules available to it at the time of scan for soundness. This code has been stale for a couple of years and it is time to simplify things a bit by deleting it.
Adds an access control field for each imported module identified. When multiple imports of the same module are found, this keeps track of the most "open" access specifier.
I don't believe we ever form these types, and if we did we aren't
correctly handling them in `Solution::simplifyType`. Let's just
enforce we don't get them.
