This repository has been archived by the owner on Jan 25, 2024. It is now read-only.
Merge 0.23.0 from upstream to textnow branch #3
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Before: ``` swift-DEVELOPMENT-SNAPSHOT-2020-01-29-a.xctoolchain -> org.swift.50202001291a swift-TEST-SNAPSHOT-2020-01-23-a.xctoolchain -> org.swift.50202001231a swift-latest.xctoolchain -> org.swift.50202001291a ``` After: ``` /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2020-01-29-a.xctoolchain -> org.swift.50202001291a /Library/Developer/Toolchains/swift-TEST-SNAPSHOT-2020-01-23-a.xctoolchain -> org.swift.50202001231a /Library/Developer/Toolchains/swift-latest.xctoolchain -> org.swift.50202001291a /Users/ksmiley/Library/Developer/Toolchains/swift-5.2-DEVELOPMENT-SNAPSHOT-2020-04-28-a.xctoolchain -> org.swift.52202004281a /Users/ksmiley/Library/Developer/Toolchains/swift-latest.xctoolchain -> org.swift.52202004281a ```
…om its dependencies, otherwise coverage data might get dropped. PiperOrigin-RevId: 325306099
Co-authored-by: Michael Eisel <meisel@spotify.com> Co-authored-by: Keith Smiley <keithbsmiley@gmail.com>
This is outdated, best to look at the github insights tab
* Add a feature to support compiling system modules with reduced
diagnostic output.
* Support system modules passed as path names (strings) instead of
`File` artifacts.
* Add the necessary tool config to support compiling explicit
modules with Xcode 12 and higher (when the features are also
enabled).
* When compiling explicit modules, generate module maps for
`objc_library` targets in the Swift rules instead of using
the one propagated by `ObjcProvider` to ensure that `use`
declarations for dependencies unknown to the native Bazel
module map generation code are present.
PiperOrigin-RevId: 327813526
Co-authored-by: Tony Allevato <allevato@google.com>
…ne is macOS (bazelbuild#473) This is to prevent the linking failures if a `swift_library` target has too many files that can cause its linking args to become longer than the system's command length limits. This does not change the behavior when building on Linux yet, since `ar` does not support passing arguments using a parameter file.
… to use an allocator provided by the `--custom_malloc` flag, if any. (bazelbuild#478) PiperOrigin-RevId: 329317960 Co-authored-by: Tony Allevato <allevato@google.com>
… as object files) do not have spaces in their names. This was already handled for basenames, but not for directory names between the target's package and the file; for example, if one had `swift_library(name = "ArgumentParser", ...)` in a `BUILD` file that also contained `Sources/ArgumentParser/Parsable Types/ParsableCommand.swift`. PiperOrigin-RevId: 329799243
* Pin rules_proto to a rev that contains bzl_library definitions * Update bzl_library targets Mostly so depending on them from a stardoc rule works now we load rules_proto Mostly autogenerated & then tweaked based on the gazelle in bazelbuild/bazel-skylib#271 * Revert removal of for_bazel_tests filegroup target * Update internal bzl_libraries to only be visible to //swift:__subpackages__ * Also limit visibility of //test/fixtures:common
The DescriptorSets ProtoInfo exposes don't have source info, so the generated source don't have the comment. bazelbuild/bazel#9337 is open to attempt to get that, but this provides a way to opt into forcing it. This does come with a minor risk for cross repository and/or generated proto files where the protoc command line might not be crafted correctly, so it remains opt in. RELNOTES: None PiperOrigin-RevId: 330538313
The DescriptorSets ProtoInfo exposes don't have source info, so the generated source don't have the comment. bazelbuild/bazel#9337 is open to attempt to get that, but this provides a way to opt into forcing it. This does come with a minor risk for cross repository and/or generated proto files where the protoc command line might not be crafted correctly, so it remains opt in. This is followup to the previous change that did this for swift_proto_library. NOTE: The current version of swift grpc depended on doesn't include comments, but the NIO version appears to support it for methods, so landing the work in advance of things updating to that version. RELNOTES: None PiperOrigin-RevId: 330729710
RELNOTES: None PiperOrigin-RevId: 330801521
…hat don't have any headers (and that don't specify an explicit module map using the `module_map` attribute). This is typically the case for libraries that group other libraries via their `deps`. Users mistakenly import these thinking they're required to use the underlying declarations, but they do nothing (except make more work for the compiler). PiperOrigin-RevId: 332246632 (cherry picked from commit 639ecfa)
This is phase 2 of of the switch to toolchain transitions. See bazelbuild/bazel#11584 for details. This shouldn't be merged into rules_swift's master branch until https://cs.opensource.google/bazel/bazel/+/58fdf63d81cc71f0315918b111fc56f4c039f1a5 is in a Bazel release (which should be 3.7, bazelbuild/bazel#12188). PiperOrigin-RevId: 334610489
This comment made it sound like this shouldn't ever happen, but if you pass `-rpath @loader_path/something` you will always hit this case.
…ived files (bazelbuild#504) Co-authored-by: Keith Smiley <keithbsmiley@gmail.com>
The swiftmodule generation should not attempt to perform indexing.
…ompiling the explicit module for its generated header. PiperOrigin-RevId: 372240650 (cherry picked from commit cc15b6e)
…ode 12.5/Swift 5.4 or higher). PiperOrigin-RevId: 373046121 (cherry picked from commit 4cd9b2c)
…hich packages are allowed to enable/disable specific features. (bazelbuild#627) Co-authored-by: Tony Allevato <allevato@google.com>
…t generated header. The Swift compiler determines which module to import a symbol from based on the module that defines that symbol. Due to modular re-exports (which are particularly common among system frameworks), this may not be the same framework that the user imported from Swift and added to their dependencies. (For example, most users will import and depend on `Foundation` to use `NSObject`, but Swift will import it from the module it is actually defined in, `ObjectiveC`.) PiperOrigin-RevId: 371919747 (cherry picked from commit d8a381c)
This depends on lambda support which bazel 4.1 does not have
This reverts commit 021c11b.
For layering checks with explicit modules, we only want `-fmodules-strict-decluse`; it's not useful to let headers without a known module map sneak through. PiperOrigin-RevId: 375825780 (cherry picked from commit 214f725)
…iling any explicit Clang module. The toolchain's `clang_implicit_deps` are not passed to Swift compilations; only to actions that compile an explicit C/Objective-C module using `swift_common.precompile_clang_module`. PiperOrigin-RevId: 375816204 (cherry picked from commit 9afbc30)
…ode 12.5: ``` <unknown>:0: error: invalid argument '-fsystem-module' only allowed with '-emit-module' ``` This happens because ClangImporter changes the invocation's action to `GenerateModule` *after* the invocation is created by parsing the `-Xcc` flags from the Swift command line, and Clang's argument parser emits a diagnostic if `-fsystem-module` is used with any other action. PiperOrigin-RevId: 375942286 (cherry picked from commit c497e6e)
Matches the one just landed in rules_apple: bazelbuild/rules_apple@61bc7c0
Missed with 84286ad. Also reverts the hard error on not creating directories. It could try to create the same directory multiple times, and the previous behavior silently errored on those. This can get fixed up in a later change to only try to create each directory once, and to only error if the directory doesn't already exist.
swift and clang write index data based on the status of what resides in `index-store-path`. When using a transient per-swift-library index, it writes O( M imports * N libs) indexer data and slows down compilation significantly: to the tune of 6GB+ index data in my testing. Bazel likes to use per `swift_library` data in order to remote cache them, which needs extra consideration to work with the design of swift and clang and preserve the performance This PR does 2 things to make index while building use the original model of the index-store so we don't have to patch clang and swift for this yet. When the feature, `swift.use_global_index_store`, is set: 1. it writes to a global index cache, `bazel-out/global_index_store` 2. it copies indexstore data (records and units) to where Bazel expected them for caching: e.g. the original location with `swift.index_while_building` I added a detailed description of this feature in the RFC to add it there MobileNativeFoundation/index-import#53. In practice, transitive imports will be indexed by deps and if they aren't cached then the fallback is Xcode wil index transitive files if we set those as deps on the unit files
This change adds the search path for StoreKitTest/XCTest now available on watchOS in Xcode 12.5, and retires a number of workarounds and/or conditional code paths that are for older versions of Xcode that we don't care about anymore. For example, statically linking the Swift runtime is no longer supported on Darwin with modern versions of Xcode. PiperOrigin-RevId: 377920556 (cherry picked from commit bf5fccc)
…om the Swift toolchain. It may have been needed in the past with older versions of Swift, but it doesn't appear to be anymore (and it causes problems if the version targeted during the build is mismatched with the simulator/OS version under which the test is running). PiperOrigin-RevId: 378400910 (cherry picked from commit 92b727e)
…e toolchain. Apple binaries/bundles will automatically get these linker flags if they have any Swift target in their dependencies; this eliminates the need to pass them separately at the top level. PiperOrigin-RevId: 378024438 (cherry picked from commit 96f0a67) # Conflicts: # swift/internal/providers.bzl # swift/internal/swift_toolchain.bzl # swift/internal/xcode_swift_toolchain.bzl
If there are 2 concurrent processes creating the same directories, then it will fail I noticed this on the CI errors of bazelbuild#567, and a co-worker was hitting it today. I suspect invalidating the worker or other updates triggered big rebuilds. I don't know of a perfect repro but, at a 10% rate: invoking Bazel to build 2 swift libraries in the same BUILD file.
Now that we only report failures from `MakeDir` if there is actually an error, we can error out earlier for a better error message.
This should have been deleted in the previous change that refactored the linker flags. It no longer works because it tries to access a provide field that no longer exists, but nothing broke because nothing calls it anymore. Yay weak typing. PiperOrigin-RevId: 378673728 (cherry picked from commit 503c9cc)
…inline string (bazelbuild#647) For consistency with other repos that do not define their own build files
So they are copied over in integration tests in rules_apple
Not sure why this works sometimes and not others but we need to terminate this where the BUILD file lives
ericgreene
approved these changes
Sep 20, 2021
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.