When compiling a Swift module in incremental mode, each Swift source file is compiled into an object file
and we use linker to link them together. Because the predicate function for checking dynamic feature
availability is eagerly synthesized per compilation unit, the linker will complain about duplicated
symbols for them. Setting their visibility as private ensures that linker doesn't see them, thus addressing
the linker errors.
One workaround for this problem is to enable WMO.
rdar://164971313
This eliminates a SIL verification error with `@c` functions, which
provide definitions for foreign entrypoints. We were serializing @c
definitions when we shouldn't be, which would cause problems down the
line if those @c definitions referenced something internal that they
shouldn't.
We were creating the JumpDests too early, so lowering a 'break' or 'continue'
statement would perform cleanups that were recorded while evaluating the
pack expansion expression, which would cause SIL verifier errors and
runtime crashes.
- Fixes https://github.com/swiftlang/swift/issues/78598
- Fixes rdar://131847933
For dynamic features defined from a header, we synthesize a pure Clang function to check whether the feature should
be enabled at runtime. Swift modules don't have capability to deserialize this clang predicate function, leading to
crasher as a result. This change fixes the crasher by hiding the synthesized function to be a module internal one.
rdar://164410957
It hoists `destroy_value` instructions for non-lexical values.
```
%1 = some_ownedValue
...
last_use(%1)
... // other instructions
destroy_value %1
```
->
```
%1 = some_ownedValue
...
last_use(%1)
destroy_value %1 // <- moved after the last use
... // other instructions
```
In contrast to non-mandatory optimization passes, this is the only pass which hoists destroys over deinit-barriers.
This ensures consistent behavior in -Onone and optimized builds.
This is necessary because we need to model its stack-allocation
behavior, although I'm not yet doing that in this patch because
StackNesting first needs to be taught to not try to move the
deallocation.
I'm not convinced that `async let` *should* be doing a stack allocation,
but it undoubtedly *is* doing a stack allocation, and until we have an
alternative to that, we will need to model it properly.
The existing tests we have here I'm hoping to reject in Sema, add
equivalent variants that use local functions which will continue to
be caught in SILGen.
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.
We already reject attempts to reference this for `lazy` properties.
For `lazy` locals let's just not expose it to name lookup to begin
with. This ensures we don't attempt to prematurely kick the interface
type computation for the var, fixing a couple of crashers.
With this patch, I'm flipping the polarity of things.
The flag `-enable-experimental-feature ManualOwnership` now turns on the diagnostics,
but they're all silenced by default. So, you need to add -Wwarning or -Werror to
your build settings to turn on the specific diagnostics you care about.
These are the diagnostic groups relevant to the feature:
- SemanticCopies aka "explicit copies mode"
- DynamicExclusivity
For example, the build setting `-Werror SemanticCopies` now gives you errors about
explicit copies, just as before, but now you can make them just warnings with -Wwarning.
To opt-out a declaration from everything when using the feature, use @_noManualOwnership.
@_manualOwnership is no longer an attribute as a result.
resolves rdar://163372569
SILGen inserts mark_unresolved_noncopyable_value at the introducer in some cases and at uses in other cases. This inconsistency can causes insertion of a redundant mark* instruction which crashes the move-only checker.
This change avoids inserting a redundant mark* instruction.
Instead of using the C name for `@c` functions in SIL, retain mangled
names and apply the `asmname` attribute, so we retain more type
information until later in the pipeline and avoid collisions.
Another part of rdar://137014448.
This experimental feature will be used to force the compiler to treat `Swift`
runtime availability as separate from platform availability when compiling for
targets that have the Swift runtime built-in.
SILGenBorrowedBaseVisitor did not take subscripts into account during its
visit. Add this case following the handling of MemberRefExpr for properties.
Fixes rdar://163022690.
