The `projection` flag indicates that `index_addr` projects an element address from an array base address, as opposed to being used for general pointer arithmetic.
When this flag is set, the result address can only reach the single element at the given index — it is not possible to chain multiple `index_addr` instructions to reach other array elements from the result.
Without this flag, the result may be used as the base of another `index_addr`, allowing arithmetic across element boundaries (e.g. an `index_addr` with index 1 followed by an `index_addr` with index 2 reaches the element at offset 3).
An `index_addr [projection]` is mandatory to go from an array base address to an element - even if it's the first element, i.e. the index is zero.
This means that the optimizer must not remove `index_addr [projection]` with a zero index.
In diagnostic mode, propagate function value placeholder/hole to
arguments and result. This helps to avoid recording extraneous
fixes because generic parameters and leading-dot syntax arguments
cannot be inferred in this case.
- Remove redundant isCrossingCheck ternary in MismatchedIsolatedConformances:
printStringForDiagnostics now correctly returns "@concurrent" for
NonisolatedConcurrent and "nonisolated" for Nonisolated, so the manual
override is unnecessary. Remove the isCrossingCheck field entirely.
- Change isolated_conformance_wrong_domain and
isolated_conformance_may_cross_isolation diagnostics to accept
ActorIsolation directly instead of StringRef, letting the diagnostic
engine call printForDiagnostics.
- Rename ASTDumper flag from "isolated_to_caller_isolation" to
"nonisolated_nonsending".
- Restore SIL test CHECK lines that lost @caller_isolated annotations
during rebase conflict resolution (optimize_hop_to_executor.sil,
attr_execution tests, SILGen tests, Serialization tests).
- Apply caller_isolation_inheriting -> nonisolated(nonsending) rename
to restored test files.
We cannot use spare bits or other overlapping storage layout tricks with fundamentally
address-only enums, and we can take advantage of this to do borrowing switches or other
in-place projections without copying the value. However, for resilient enums, the
implementation may use spare bit packing, but the type must be handled address-only
outside of its defining module, and we didn't have a way to express that with
borrowing switch. Optimization passes have also been running into problems with the
complexity that we were using `unchecked_take_enum_data_addr` sometimes as a pure
operation. This patch splits the instruction into three:
- `unchecked_inplace_enum_data_addr` represents a nondestructive in-place enum
projection. It is only allowed for enums whose projection operation is
nondestructive.
- `unchecked_take_enum_data_addr` represents a destructive enum projection,
invalidating the enum and leaving the payload to be further consumed.
This matches the current instruction's semantics.
- `unchecked_borrow_enum_data_addr` represents a borrowing enum projection.
The instruction takes a second operand for "scratch" space, which the
enum representation may be copied into in order to avoid invalidating the
enum value, so the result is dependent on the lifetime of both the
original enum and the scratch buffer. This allows for borrowing switches
over resilient enums.
`unchecked_borrow_enum_data_addr` is implemented by taking advantage of the
"address-only enums can't do spare bit optimization" property at runtime.
We inspect the operand type's bitwise-borrowability from its metadata. If
the type is bitwise-borrowable, then we are allowed to bitwise-copy the
enum to the scratch space and apply the projection to the scratch space,
preserving the original value. If the type is not bitwise-borrowable, then
we cannot use spare bit optimization in its layout, so we apply the
projection in-place.
Fixes rdar://174952822.
For a given function, we might end up emitting it's definition as
object code, serialized SIL, or both. The @export, @inlinable, and
@inline(always) attributes provide control of this behavior at the
declaration level.
Centralize the query function that will look for each of these
attributes and map down to a specific "code generation model", whose 3
options follow the naming from SE-0497: interface, inlinable, and
implementation. Use this one computation to back the queries for
"always emit into client", "never emit into client", and "inlinable"
so we can't get inconsistent results from places that are doing
one-off checks for these attributes.
If a function type requires an implicit isolation parameter
also set `nonisolated(nonsending)` isolation on it. This helps
us track all of the references to `nonisolated(nonsending)`
functions.
Add a LIBRARY_LEVEL record to the .swiftmodule options block so the
declared -library-level value survives across compilations. Without
this, imported modules have to always fell back to a path heuristic
that could only distinguish API vs SPI and never returned IPI.
rdar://174255626
Default to use new swift-driver to run lit tests as legacy swift driver
is deprecated for a long time. The lit tests for legacy drivers are also
disable when running new swift-driver.
Tests that relies on legacy swift driver (for example, tests merge
module) can be enabled on conditions `legacy_swift_driver`. Fix and
split up some existing tests that relies on legacy driver.
Also, since the mock SDK's implementation of CGFloat is wrong,
update some existing tests to use the real SDK instead. This
exposed a few instances where the behavior was not as intended;
I added FIXME comments explaining what's going on.
* replace the non-OSSA ClosureSpecializer with the new OSSA ClosureSpecialization pass
* move the OwnershipModelEliminator after the mid-level and closure-specialization pipelines
* add an additional RedundantLoadElimination pass at the begin of the low-level pipeline to compensate for not eliminated loads in OSSA
We need to start moving people over to using the version of
suppressed associated types that has the officially accepted
behavior according to SE-503, and that is via
`SuppressedAssociatedTypesWithDefaults`.
To allow for time to migrate to the new version, I'm introducing
the deprecation message as a warning for now.
This set of changes also moves most of the test suite over to using
the officially accepted version.
rdar://172231663
Currently only the top level dependencies get serialized in Swift modules. In
practice this is not enough information to fully replay a module import
sequence, especially when the dependencies include binary SDK modules that were
built elsewhere. In this case we cannot follow the links to its depenencies,
since they refer to paths on a different machine or unavailable CAS. During an
EBM build, the dependency scanner writes the complete list of dependencies into
a json file called the explicit Swift module map -- including the local
locations of the dependencies of binary SDK modules. Using this LLDB can replay
a module import with 100% accuracy.
rdar://170514919
Replaces the other ExperimentalLanguageFeature (non-plural) SPI usages with the plural version. Also removes the `@_spi` flag from BodyMacroWithControlFlow as body macros are no longer an experimental feature. This is liked to a PR on swift-syntax: https://github.com/swiftlang/swift-syntax/pull/3272
Extend support for proper errors on broken modularization to type
members, previously only top-level declarations were reported as error.
This change raises errors with relevant context if a type member is
referenced from a swiftmodule file but at reading the member is not
found or changed shape.
It doesn't report moves between modules like we do for top-level
declarations. This is less likely to happen at the member level as the
check is already applied at the top-level for the same reference. We may
still see such issues when using `SWIFT_NAME` to assign a top-level
declaration to a type from a different module.
When a function type refers to a Swift declaration we get a crash during
deserialization. This patch prevents serializing the problematic clang
function types to avoid this crash.
rdar://166359524
Attempt to optimize by forwarding the destroy to operands of forwarding instructions.
```
%3 = struct $S (%1, %2)
destroy_value %3 // the only use of %3
```
->
```
destroy_value %1
destroy_value %2
```
The benefit of this transformation is that the forwarding instruction can be removed.
Also, handle `destroy_value` for phi arguments.
This is a more complex case where the destroyed value comes from different predecessors via a phi argument.
The optimization moves the `destroy_value` to each predecessor block.
```
bb1:
br bb3(%0)
bb2:
br bb3(%1)
bb3(%3 : @owned T):
... // no deinit-barriers
destroy_value %3 // the only use of %3
```
->
```
bb1:
destroy_value %0
br bb3
bb2:
destroy_value %1
br bb3
bb3:
...
```
We need to serialize the underlying type substitution map for an
inlinable function. However, there is no reason to deserialize it
eagerly, since doing so can lead to cycles. It is better for
correctness and performance to only deserialize it when needed.
Technically this fixes a regression from #84299, but the actual
problem was there all along, it was just exposed by my change
on a specific project.
Fixes rdar://163301203.
Predefined declarations (like _GUID) are special forward declarations
inserted by Clang and aren't serialized into the pcm and their
definition pointers aren't retained across serialization and
deserialization, which causes this type not found error. Avoid putting
non-defining predefined declarations into the swift lookup table when
their definitions exist in the same module so that the definitions
will be associated with the base name and avoid this error.
Introduce a last resort check reporting references to
implementation-only dependencies that would appear in the generated
swiftmodule. This check is applied at serialization, long after
exportability checking applied at typechecking. It should act as a back
stop to references missed by typechecking or @_implementationOnly decls
that should have been skipped.
This check is gated behind CheckImplementationOnlyStrict and should be
used with embedded only.
rdar://160697599
This showed up on and off again on the source-compatibility testsuite project hummingbird.
The gist of the problem is that transformations may not rewrite the
type of an inlined instance of a variable without also createing a
deep copy of the inlined function with a different name (and e.g., a
specialization suffix). Otherwise the modified inlined variable will
cause an inconsistency when later compiler passes try to create the
abstract declaration of that inlined function as there would be
conflicting declarations for that variable.
Since SILDebugScope isn't yet available in the SwiftCompilerSources
this fix just drop these variables, but it would be absolutely
possible to preserve them by using the same mechanism that SILCloner
uses to create a deep copy of the inlined function scopes.
rdar://163167975
Whenever we have a reference to a foreign function/variable in SIL, use
a mangled name at the SIL level with the C name in the asmname
attribute. The expands the use of asmname to three kinds of cases that
it hadn't been used in yet:
* Declarations imported from C headers/modules
* @_cdecl @implementation of C headers/modules
* @_cdecl functions in general
Some code within the SIL pipeline makes assumptions that the C names of
various runtime functions are reflected at the SIL level. For example,
the linking of Embedded Swift runtime functions is done by-name, and
some of those names refer to C functions (like `swift_retain`) and
others refer to Swift functions that use `@_silgen_name` (like
`swift_getDefaultExecutor`). Extend the serialized module format to
include a table that maps from the asmname of functions/variables over
to their mangled names, so we can look up functions by asmname if we
want. These tables could also be used for checking for declarations
that conflict on their asmname in the future. Right now, we leave it
up to LLVM or the linker to do the checking.
`@_silgen_name` is not affected by these changes, nor should it be:
that hidden feature is specifically meant to affect the name at the
SIL level.
The vast majority of test changes are SIL tests where we had expected
to see the C/C++/Objective-C names in the tests for references to
foreign entities, and now we see Swift mangled names (ending in To).
The SIL declarations themselves will have a corresponding asmname.
Notably, the IRGen tests have *not* changed, because we generally the
same IR as before. It's only the modeling at the SIL lever that has
changed.
Another part of rdar://137014448.
Erik Eckstein
Pavel Yaskevich
Dario Rexin
Artem Chikin
Konrad Malawski
Joe Groff
Aidan Hall
Doug Gregor
Pavel Yaskevich
Saleem Abdulrasool
Sam Pyankov
Meghana Gupta
Steven Wu
Meghana Gupta
Slava Pestov
Kavon Farvardin
Adrian Prantl
Yuta Saito
Becca Royal-Gordon
Hunter Baker
Alexis Laferrière
Gabor Horvath
Mishal Shah
Hiroshi Yamauchi
Kuba (Brecka) Mracek