We weren't showing the unsafe uses when we determine that a for..in
loop is unsafe. Do so, which generally means complaining about `next()`
being unsafe. Fixes rdar://151237127
The Fix-It was adding @unsafe prior to the extension, which is
incorrect. Make sure we apply @unsafe at the right location for the
explicit conformance.
Fixes rdar://151800162
Previously we did not remove count parameters if any count parameters
were shared between count expressions, or if any count expression
contained operations. Buffer sizes were also just checked to be larger
than or equal than the given count.
We now extract the count from Spans/BufferPointers whenever possible,
and store that value in a variable at the start of the function. If
multiple parameters share the same count, a bounds check is emitted to
make sure that they have the same size. Subspans can be used if one span
is larger than necessary.
The message in the bounds check is changed so that it includes the
expected and actual value, to aid in debugging.
This patch also fixes some incorrect indentation, and adds the
Whitespace.swift test case to act as a regression test in case the
indentation changes, since the other test cases don't use significant
whitespace.
rdar://151488820
rdar://151511090
rdar://146333006
rdar://147715799
(cherry picked from commit f5fa481205)
Previously we would only add @_disfavoredOverload if the only type
changed was the return type, because in any other case it is unambiguous
which overload to call. However it is still ambiguous when storing the
function as a value rather than calling the function, unless explicit
type annotations are used.
To avoid breaking any existing code, this patch adds
@_disfavoredOverload to every overload generated by @_SwiftifyImport.
rdar://151206394
(cherry picked from commit 0f312adb92)
Parameters can be named with keywords without escaping, because it's
unambiguous in the grammar that they are parameters. They still need to
escaped when referred to inside the function body however. This escapes
all references to parameters using backticks.
Parameter names are also checked for clashes with the function name - in
such cases the parameter is renamed in the same way as unnamed
parameters.
rdar://151024645
(cherry picked from commit ebe2c60f43)
Update availability for CxxSpan<->Span, fix lifetimebound on parameters
with reference type
Because swift-ide-test doesn't care about typechecking,
std-span-interface.swift passed despite containing 2 separate errors.
This updates the test file to properly exercise the entire compilation
pipeline for the macro expansions, by running swift-frontend
-emit-module and calling each macro expansion.
The first issue was that CxxSpan initializers taking [Mutable]Span still
had their availability set to Swift 6.2+, even after back-deploying
caused [Mutable]Span to have availability back to Swift 5.0. Since
_SwiftifyImport expansions copy the availbility of Span, this resulted
in the macro expansions calling unavailable initializers. Interestingly
enough, this manifested itself in the form of a tripped assert in SIL
verification, because although we do now typecheck the expansions from
_SwiftifyImport, the compilation can still keep going after
`shouldEmitFunctionBody` returns false: the macro expansion declaration
is still there, but is now missing its definition, despite not being
external.
The second issue was when parameters with C++ reference types were
annotated with `[[clang::lifetimebound]]`. For parameters with a type
that is `Escapable`, this is normally done using `@lifetime(borrow
foo)`. However C++ reference parameters are imported as `inout`, which
requires the `@lifetime(&foo)` syntax.
rdar://151493400
rdar://151678415
(cherry picked from commit 262a53f599)
This code is no longer used given that region isolation is always enabled
along with strict concurrency checking.
(cherry picked from commit c283ce12d5)
When hoisting destroys of aggregates, an attempt is made to fold the
destroys of individual fields into the foregoing instructions. If the
aggregate is noncopyable, this transformation is illegal.
When hoisting destroys of aggregates, an attempt is made to fold the
destroys of individual fields into the foregoing instructions. If the
aggregate is nonescapable, this transformation is illegal.
rdar://152195094
Ideally this would also update the `--version` output to be overridden
by `SWIFT_TOOLCHAIN_VERSION`, but unfortunately various tools rely on
the current format (eg. swift-build).
(cherry picked from commit 3c098782b4)
If a `[[no_unique_address]]` field has zero size according to Clang, and field has a type that isn't representable in Swift, Swift would previously try to add an opaque field of size 1 for it.
This is wrong and was causing crashes for `std::string` while emitting a padding field:
```
_LIBCPP_NO_UNIQUE_ADDRESS ::std::__compressed_pair_padding<T1> _LIBCPP_CONCAT3(__padding1_, __LINE__, _);
```
rdar://151941799
(cherry picked from commit a7c174431f)
Check for unsafe constructs in all modes, so that we can emit the
"unsafe does not cover any unsafe constructs" warning consistently.
One does not need to write "unsafe" outside of strict memory safety
mode, but if you do... it needs to cover unsafe behavior.
(cherry picked from commit 1b94c3b3d6)
On creation, 'ClangImporter' adds overlay modulemap files for non-modular platform libraries (e.g. glibc, libstdc++), which allows Swift code to import and use those libraries.
This change adds the same filesystem overlay to dependency scanning queries by applying them to the filesystem instantiated for each depndency scanning worker. Without these overlays EBM builds cannot discover and use non-modular system libraries on non-Darwin platforms.
Resolves rdar://151780437
Make `getOriginalLocation` work with source ranges, and adjust the
cursor info logic to map the range into the original buffer. This
fixes the case where we were using bogus range lengths for macro
expansion decls.
rdar://151411756
[6.2][send-non-sendable] Recurse to the full underlying value computation instead of just the object one when computing the underlying object of an address.
Swift nodes imported from clang don't have doc comments carried over,
but IDEs are clever enough to fetch the comments from the associated
clang node. The swift node in the macro expansion from _SwiftifyImport
doesn't have a clang node directly associated with it however.
This patch adds the same comment from the clang node to the
_SwiftifyImport macro invocation node. Since the macro has access to
this node, it can easily copy over its leading trivia.
For now the comment is not altered at all, meaning @param still remains
even if the parmeter is removed.
rdar://151346977
(cherry picked from commit 6534b9b14f)
The name of a migratable feature might differ from the names of the
diagnostic groups containing the diagnostics that are used to drive
migration for that feature. Provide the set of diagnostic categories
that are associated with each migratable feature as part of the
supported features list.
(cherry picked from commit 7f2649ff33)
This feature is essentially self-migrating, but fit it into the
migration flow by marking it as migratable, adding
`-strict-memory-safety:migrate`, and introducing a test.
(cherry picked from commit abad2fae0f)
When migrating, provide warnings that add 'nonisolated' to nonisolated
conformances that don't already have it and would end up being inferred
to be isolated under the upcoming feature.
(cherry picked from commit a32782bcbc)
This is future-proofing the version part of the upcoming
feature. There currently no features that require that
but it's possible that they'd be added in the future.
(cherry picked from commit 4909b9baed)
When issuing warnings about an import not needing to be public, we did
not account for the Distributed module MUST be imported when a
distributed actor is declared. This also actually means that a public
distributed actor effectively is a public use of the DistributedActor
protocol
resolves rdar://152129980
Key paths can't reference non-escapable or non-copyable storage declarations,
so we don't need to refer to them resiliently, and can elide their property
descriptors.
However, declarations may still be conditionally Copyable and Escapable, and
if so, then they still need a property descriptor for resilient key path
references. When a property or subscript can be used in a context where it
is fully Copyable and Escapable, emit the property descriptor in a generic
environment constrained by the necessary conditional constraints.
Fixes rdar://151628396.
Otherwise, depending on the exact value that we perform the underlying look up
at... we will get different underlying values. To see this consider the
following SIL:
```sil
%1 = alloc_stack $MyEnum<T>
copy_addr %0 to [init] %1
%2 = unchecked_take_enum_data_addr %1, #MyEnum.some!enumelt
%3 = load [take] %2
%4 = project_box %3, 0
%5 = load_borrow %4
%6 = copy_value %5
```
If one were to perform an underlying object query on %4 or %3, one would get
back an underlying object of %1. In contrast, if one performed the same
operation on %5, then one would get back %3. The reason why this happens is that
we first see we have an object but that it is from a load_borrow so we need to
look through the load_borrow and perform the address underlying value
computation. When we do that, we find project_box to be the value. project_box
is special since it is the only address base we ever look through since from an
underlying object perspective, we want to consider the box to be the underlying
object rather than the projection. So thus we see that the result of the
underlying address computation is that the underlying address is from a load
[take]. Since we then pass in load [take] recursively into the underlying value
object computation, we just return load [take]. In contrast, the correct
behavior is to do the more general recurse that recognizes that we have a load
[take] and that we need to look through it and perform the address computation.
rdar://151598281
(cherry picked from commit 904ebc6784)
Omit an explicit access level from `MemberImportVisibility` fix-its under the
following conditions:
- `InternalImportsByDefault` is enabled.
- The required import needs an `internal` access level or lower.
- The module is not yet imported explicitly in any other file.
Resolves rdar://149577615.
