You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Allow passing extra arguments to plugin compilation.
For most case, compiling against the host toolchain does not need extra
arguments, but in some complicated setups, the host toolchain might need
extra arguments for search paths and such. In the case of the manifest,
the option of using `-Xmanifest` arguments to customize the manifest
compilation has existed for a while, but in the case of plugins, the
same option was not available and made consuming packages with plugins
very complicated.
The changes in this commit add `-Xbuild-tools-swiftc` to affect both manifest
and plugin compilation, allowing complicated setups to provide their values
and compile and use plugins. `-Xmanifest` is kept for backwards
compatibility, but it will only affect manifest compilation, as before,
and it will print a warning if used.
Includes modifications in one of the plugin tests to show that the
`-Xbuild-tools-swiftc` parameters are passed to the plugin compilation (I
could not find a similar test for `-Xmanifest`).
Copy file name to clipboardExpand all lines: CHANGELOG.md
+5Lines changed: 5 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,6 +3,10 @@ Note: This is in reverse chronological order, so newer entries are added to the
3
3
Swift Next
4
4
-----------
5
5
6
+
*[#5966]
7
+
8
+
Plugin compilation can be influenced by using `-Xbuild-tools-swiftc` arguments in the SwiftPM command line. This is similar to the existing mechanism for influencing the manifest compilation using `-Xmanifest` arguments. Manifest compilation will also be influenced by `-Xbuild-tools-swiftc`, but only if no other `-Xmanifest` arguments are provided. Using `-Xmanifest` will show a deprecation message. `-Xmanifest` will be removed in the future.
9
+
6
10
*[#5728]
7
11
8
12
In packages that specify resources using a future tools version, the generated resource bundle accessor will import `Foundation.Bundle` for its own implementation only. _Clients_ of such packages therefore no longer silently import `Foundation`, preventing inadvertent use of Foundation extensions to standard library APIs, which helps to avoid unexpected code size increases.
0 commit comments