Ensure we do not expect additional linker args to be produced in targets with Swift-produced object files (#378)
If Swift produced an object in the linked libraries of a target, we allow it to generate additional linker options, even if it did not run to compile any source files. However, we should not attempt to inject top-level AST paths for debugging since no actual compile took place, and the paths won't exist at execution time. Use the object file type when injecting Swift tool usage in these targets so that we don't take the unintended code path.
Bootstrap: update logic to support pre-and post python 3.8 (#8446)
PR #8373 (commit ID: 0193d5fb8) updated a `shutil.copytree(...)` command to pass in the `dirs_exists_ok=True` argument. However, Python added support for the `dirs_exists_ok` argument to `shutil.copytree` in 3.8.
Update the function call to inspect the python version, and only add the argument if the script is running in a Python version equal, or higher than 3.8.
Add a build flavor to opt-out of BTCFI on OpenBSD.
To work-around #80059, we need to stop return address signing and opt-out of BTCFI enforcement via enabling a platform linker option.
We don't want to completely undo the BTCFI work in the rare case that we later figure out how to properly address the above issue, or allow users who might want to benefit from BTCFI enforcement and won't use Concurrency. To do this, condition the existing BTCFI flag enforcement into a configuration option that defaults to off for now.
Because the new swift-driver needs to "know" whether the frontend is configured to opt-out or not, and since the new driver communicates with the frontend via the target info JSON to begin with, we add a field that emits the build flavor to signal the right behavior.
[ASTScope] Allow `try` in unfolded sequence to cover following elements
Rather than fixing-up in the parser, adjust the ASTScope logic such that a `try` element in a SequenceExpr is considered as covering all elements to the right of it. Cases where this isn't true are invalid, and will be diagnosed during sequence folding. e.g:
[ExplicitModuleBuild] Don't leak chained bridging header in objc header
When generating an objc header from the swift module when a bridging header is used, make sure to use the original bridging header, not the chained bridging header. This also avoids incorrectly generated a header include when no actual bridging header is used, just a chained bridging header that is coming from a dependency.
This is the C++ driver counterpart to a change that landed in the Swift driver a while ago to use the clang-linker to determine what the default linker is. This is to avoid hard-coding gold, which is deprecated and not available on some newer Linux distributions. The challenge is that these newer Linux distributions don't already have Swift so we have to use the old C++ driver implementation.