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.
Explanation: Shared references imported from C++ were not considered
safe. This is a widely used feature and this fix is blocking the users
from adopting strictly memory safe Swift.
Issue: rdar://151039766
Risk: Low, the fix only changes what declarations are considered safe.
Testing: Regression test added.
Original PR: #82203
Reviewer: @egorzhdan @fahadnayyar
When accessing stored properties out of an addressable variable or parameter
binding, the stored property's address inside the addressable storage of the
aggregate is itself addressable. Also, if a computed property is implemented
using an addressor, treat that as a sign that the returned address should be
used as addressable storage as well. rdar://152280207
When a `FixedArray`'s fixed size is 1, it looks like `[1 x %Ty]`. Given
an array's address, performing an operation on each element's address
entail's indexing into the array to each element's index to produce an
element's address for each index. That is true even when the array
consists of a single element. In that case, produce an address for that
single element by indexing to index 0 into each passed-in array.
rdar://151726387
These are special declarations that are synthesized by the compiler
or a macro and warnings about them are non-actionable.
(cherry picked from commit 17976c7775)
The execution of these functions is controlled by the testing
framework and it's okay if their behavior changes when the feature
flag is enabled.
Resolves: rdar://152687527
(cherry picked from commit f2f5d234dc)
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)
(cherry picked from commit 125a0862a9)
rdar://149882902
swift_conformsToProtocol does not properly handle nullptr values, which can currently be passed if the source type is an optional metatype. This change adds emission of a null check before calling the runtime function in these cases.
Macro expansion can call typeCheckExpr(), which performs qualified
lookups. So if we expand macros while binding extensions, these
qualified lookups can fail because they cannot find members of
extensions that have not been bound yet.
To fix this, try binding extensions without performing macro
expansion first. If any extensions remain at the end, we fall back
to the old behavior, and try to bind them again, this time
performing macro expansion.
Fixes rdar://149798059.
I previously added this hack to match the logic in
`TypeChecker::lookupUnqualified`, but it turns out that can introduce
request cycles for cases where `CodingKeys` is used in a generic
requirement for one of `Codable`'s potential value witnesses. Scale
back the hack such that it's only done when we get an initial empty
lookup result, ensuring we maintain source compatibility. Both these
lookup hacks should go away once we properly handle CodingKeys
synthesis.
rdar://153096639
Unforunately, x86 ELF linkers like to optimize GOTPCREL relocations by
replacing `mov` instructions that go via the GOT with `lea` instructions
that do not.
That would be fine, but they aren't very selective and will happily
perform this transformation in non-code sections if they think that
the bytes before a relocation look like a `mov` instruction.
This corrupts our metadata.
rdar://148168098
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
(cherry picked from commit 44aba1382d)
Explanation: C++ template instantiations that are not behind type
aliases don't have corresponding Swift names that are both syntactically
and semantically valid types. This PR prevents generating swiftified
overloads for those types.
Issue: rdar://151422108
Risk: Low, we swiftify functions less often.
Testing: Regression test added.
Original PR: #81973
Reviewer: @hnrklssn
Prevent migration from handling declarations that come from a
module different from the current one, this is primarily a
problem for swiftinterfaces that can get rebuilt when the module
is imported by a model that has migration mode enabled.
Resolves: rdar://152687353
(cherry picked from commit bcd6caaea4)
The compiler would previously accept use of `@_inheritActorContext`
on a parameter with a synchronous function type which wasn't marked
as `@isolated(any)`. That is incorrect because in such cases the
attribute has no effect and furthermore would prevent Sendable
and isolation checking.
Uses like that are currently diagnosed by the type-checker but we
need to go one step further and remove the effect in such case to
prevent invalid uses.
Resolves: rdar://143581268
(cherry picked from commit dbe19b6d5f)
The reason I am doing this is that we have gotten reports about certain test
cases where we are emitting errors about self being captured in isolated
closures where the sourceloc is invalid. The reason why this happened is that
the decl returned by getIsolationCrossing did not have a SourceLoc since self
was being used implicitly.
In this commit I fix that issue by using SIL level information instead of AST
level information. This guarantees that we get an appropriate SourceLoc. As an
additional benefit, this fixed some extant errors where due to some sort of bug
in the AST, we were saying that a value was nonisolated when it was actor
isolated in some of the error msgs.
rdar://151955519
(cherry picked from commit f31236931b)
When instantiating templated functions with pointers to the templated type, the ClangImporter does not strip type sugar. This strips type sugar for bounds attributes, to make sure that they import the same regardless of whether they are parsed or not.
rdar://151041990
(cherry picked from commit 00afb8ba81)
Adds support for printing a C++ foreign reference in Swift.
Also skips metadata of private fields in C++ records imported as Swift classes, following up on #81035
(cherry-picked from 848fad0021)
Explanation: We did not handle this declaration kind. This PR makes sure we
mangle it the same way we do for the target declaration.
Issue: rdar://152841420
Risk: Low, the fix is small, localized, and straightforward.
Testing: Regression test added.
Original PR: #82144
Reviewer: @egorzhdan @hnrklssn @j-hui
