In several places, there was the same or similar code to either do
a symlink or use copy/copy_if_different/copy_directory in Windows
systems. The checks were also slightly different in some cases.
There is a `SWIFT_COPY_OR_SYMLINK` that can be controlled as a CMake
option, and uses `CMAKE_HOST_UNIX` as default. Change all cases that
I can find to use that value. Also create a parallel value
`SWIFT_COPY_OR_SYMLINK_DIR` to apply to directories.
There is still a couple of cases that are specific to macOS SourceKit
framework which I have left as-is, since symlinks is probably the only
right thing to do there.
There's a case for Windows specifically that uses symlinks (in
523f807694/cmake/modules/SwiftConfigureSDK.cmake (L502))
which I have not modified as well.
As of CMake 3.25, there are now global variables `LINUX=1`, `ANDROID=1`,
etc. These conflict with expressions that used these names as unquoted
strings in positions where CMake accepts 'variable|string', for example:
- `if(sdk STREQUAL LINUX)` would fail, because `LINUX` is now defined and
expands to 1, where it would previously coerce to a string.
- `if(${sdk} STREQUAL "LINUX")` would fail if `sdk=LINUX`, because the
left-hand side expands twice.
In this patch, I looked for a number of patterns to fix up, sometimes a
little defensively:
- Quoted right-hand side of `STREQUAL` where I was confident it was
intended to be a string literal.
- Removed manual variable expansion on left-hand side of `STREQUAL`,
`MATCHES` and `IN_LIST` where I was confident it was unintended.
Fixes#65028.
Otherwise we set it on all targets/languages in a subdirectory (I forgot if it
propagates up). Regardless, this type of viral stuff is something we want to
move away from since it creates a code that is a "forall" piece of code rather
than a piece of code that only effects a single target.
I also conditionalized the actual definitions being added on the compiled file's
language being C,CXX,OBJC,OBJCXX since as we add Swift sources to the host side
of the compiler, we will not want these flags to propagate to Swift sources.
CMake supports the notion of installation components. Right now we have some
custom code for supporting swift components. I think that for installation
purposes, it would be nice to use the CMake component system.
This should be a non-functional change. We should still only be generating
install rules for targets and files in components we want to install, and we
still use the install ninja target to install everything.
This is a follow up to the discussion on #22740 to switch the host
libraries to use the `target_link_libraries` rather than the
`LINK_LIBRARIES` special handling. This allows the dependency to be
properly tracked by CMake and allows us to use the more modern syntax.
This migrates anything using the following pattern:
```swift
if let optX = try? someOptional(),
let x = optX,
...
```
to this:
```swift
if let x = try? someOptional(),
...
```
This reverts commit 121f5b64be.
Sorry to revert this again. This commit makes some pretty big changes. After
messing with the merge-conflict created by this internally, I did not feel
comfortable landing this now. I talked with Saleem and he agreed with me that
this was the right thing to do.
The key thing here is that all of the underlying code is exactly the same. I
purposely did not debride anything. This is to ensure that I am not touching too
much and increasing the probability of weird errors from occurring. Thus the
exact same code should be executed... just the routing changed.
In Swift3, shadowning type(of:) was impossible, because it was a parser
magic. In Swift4, type(of:) is resolved as normal function in stdlib so
it can be shadowed. 'TypeOfMigratorPass' was a targeted migrator pass
that prepend 'Swift.' to 'type(of:)' so that it refers Swift.type(of:)
stdlib builtin function.
To support migration from both Swift 3 and 4, this patch
teaches the driver to pick up the right set of migration scripts
according to the given Swift version. We also pushed some placeholder script
files for migration from Swift 4. This patch also brings the migrator
up-to-date by avoiding migration if the Swift version is already 4.2.
This fixes a bug found while building Swift for Windows. The CMake invocation
assumed that the host system had a utility called `create_symlink`. That
assumption breaks down on Windows, where `copy` is the equivalent tool.
The SyntacticMigratorPass is getting Too Big To Fail and covers
multiple migrations. There was already an early exit to not run
the pass if APIDigesterDataStorePath wasn't supplied, so SE-0110
tuple splat fix-its weren't getting run. This manifested in Migrator
tests not printing migrated contents on Linux.
New: ASTMigratorPass
Renamed: SyntacticMigratorPass -> APIDiffMigratorPass
New: TupleSplatMigratorPass
These implementations are entirely hidden and can only be invoked
by a swift::migrator function.
rdar://problem/32025974
This adds an adapter class that wraps Clang's lib/Edit
Commit and EditedSource classes for use in the initial
"syntactic" passes. Once the passes have completed,
the resulting source file is then passed to the Swift compiler
fix-it passes.
rdar://problem/30926261
These data files are installed into runtime resource directory so that migrator can pick them automatically according to specific platforms. To support testing, a front-end option -api-diff-data-file can be used to specify the data file to use and it will overwrite the default ones from resource directory.
The Swift 4 Migrator is invoked through either the driver and frontend
with the -update-code flag.
The basic pipeline in the frontend is:
- Perform some list of syntactic fixes (there are currently none).
- Perform N rounds of sema fix-its on the primary input file, currently
set to 7 based on prior migrator seasons. Right now, this is just set
to take any fix-it suggested by the compiler.
- Emit a replacement map file, a JSON file describing replacements to a
file that Xcode knows how to understand.
Currently, the Migrator maintains a history of migration states along
the way for debugging purposes.
- Add -emit-remap frontend option
This will indicate the EmitRemap frontend action.
- Don't fork to a separte swift-update binary.
This is going to be a mode of the compiler, invoked by the same flags.
- Add -disable-migrator-fixits option
Useful for debugging, this skips the phase in the Migrator that
automatically applies fix-its suggested by the compiler.
- Add -emit-migrated-file-path option
This is used for testing/debugging scenarios. This takes the final
migration state's output text and writes it to the file specified
by this option.
- Add -dump-migration-states-dir
This dumps all of the migration states encountered during a migration
run for a file to the given directory. For example, the compiler
fix-it migration pass dumps the input file, the output file, and the
remap file between the two.
State output has the following naming convention:
${Index}-${MigrationPassName}-${What}.${extension}, such as:
1-FixitMigrationState-Input.swift
rdar://problem/30926261
