Following along with the Getting Started guide. I noticed that the guide specifically suggests adding the `--sccache` flag if needed, but it is included in the example invocation:
> If you installed and want to use Sccache, add --sccache to the invocation.
This means that the flag is optional and should be removed from the example invocation leaving at the user discretion to use.
Attempting to bypass the compiler and access runtime functions directly has
a long history of breaking in hard-to-predict ways, and there's usually a better
way. Put up a warning to try to flush out misuses of runtime functions to see
if we can turn this into an error.
- Add simple support for the AVR architecture, as a supported conditional compilation value, and added to the default llvm targets to build.
(Later PRs will fix support for 16-bit pointers, which is broken in places, and any fixes needed to get the standard library to build.)
(Note: AVR as a target is expected to always be compiled with -enable-experimental-feature Embedded.)
This corresponds to the parameter-passing convention of the Itanium C++
ABI, in which the argument is passed indirectly and possibly modified,
but not destroyed, by the callee.
@in_cxx is handled the same way as @in in callers and @in_guaranteed in
callees. OwnershipModelEliminator emits the call to destroy_addr that is
needed to destroy the argument in the caller.
rdar://122707697
Add some documentation to describe the proposed model for cross-compilation, associated flags, and the reasoning for the structure. This should allow us to have a reference for the design allowing us to evolve the model.
Co-authored-by: Evan Wilde <ewilde@apple.com>
Co-authored-by: Alexander Smarus <bender@readdle.com>
Co-authored-by: Danielle <dani@builds.terrible.systems>
Consider the following piece of code and what the isolation is of the closure
literal passed to doSomething():
```swift
func doSomething(_ f: sending () -> ()) { ... }
@MyCustomActor
func foo() async {
doSomething {
// What is the isolation here?
}
}
```
In this case, the isolation of the closure is @MyCustomActor. This is because
non-Sendable closures are by default isolated to their current context (in this
case @MyCustomActor since foo is @MyCustomActor isolated). This is a problem
since
1. Our closure is a synchronous function that does not have the ability to hop
to MyCustomActor to run said code. This could result in a concurrency hole
caused by running the closure in doSomething() without hopping to
MyCustomActor's executor.
2. In Region Based Isolation, a closure that is actor isolated cannot be sent,
so we would immediately hit a region isolation error.
To fix this issue, by default, if a closure literal is passed as a sending
parameter, we make its isolation nonisolated. This ensures that it is
disconnected and can be transferred safely.
In the case of an async closure literal, we follow the same semantics, but we
add an additional wrinkle: we keep support of inheritActorIsolation. If one
marks an async closure literal with inheritActorIsolation, we allow for it to be
passed as a sendable parameter since it is actually Sendable under the hood.
The Getting Started guide offers a build-script command that new contributors can use to quickly build a debug compiler on their local machine. The command already has `--skip-tvos` and `--skip-watchos` flags since most compiler contributors don't need to build for those platforms. This change adds `--skip-xros` flag to the command.
It indicates that the value's lifetime continues to at least this point.
The boundary formed by all consuming uses together with these
instructions will encompass all uses of the value.
