C++ swift::Parser is going to be replaced with SwiftParser+ASTGen.
Direct dependencies to it should be removed. Before that, remove
unnecessary '#include "swift/Parse/Parser.h"' to clarify what actually
depends on 'swift::Parser'.
Split 'swift::parseDeclName()' et al. into the dedicated files.
The "buffer ID" in a SourceFile, which is used to find the source file's
contents in the SourceManager, has always been optional. However, the
effectively every SourceFile actually does have a buffer ID, and the
vast majority of accesses to this information dereference the optional
without checking.
Update the handful of call sites that provided `nullopt` as the buffer
ID to provide a proper buffer instead. These were mostly unit tests
and testing programs, with a few places that passed a never-empty
optional through to the SourceFile constructor.
Then, remove optionality from the representation and accessors. It is
now the case that every SourceFile has a buffer ID, simplying a bunch
of code.
Obsolete the `-enable-swift3-objc-inference` option and related options by
removing support for inferring `@objc` attributes using Swift 3 rules.
Automated migration from Swift 3 has not been supported by the compiler for
many years.
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
Like the last commit, SourceFile is used a lot by Parse and Sema, but
less so by the ClangImporter and (de)Serialization. Split it out to
cut down on recompilation times when something changes.
This commit does /not/ split the implementation of SourceFile out of
Module.cpp, which is where most of it lives. That might also be a
reasonable change, but the reason I was reluctant to is because a
number of SourceFile members correspond to the entry points in
ModuleDecl. Someone else can pick this up later if they decide it's a
good idea.
No functionality change.
Some diagnostics got worse, but I think the reduction in compiler complexity
is worth it, and copy-and-pasting Swift 2 code is not likely to produce great
results anyway.
Also, this corrects an oversight where we did not reject @pseudogeneric on
function types in AST parsing.
This migrates anything using the following pattern:
```swift
if let optX = try? someOptional(),
let x = optX,
...
```
to this:
```swift
if let x = try? someOptional(),
...
```
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.
We used to assert migration scripts exist. This patch further
decouples these scripts and the compiler by treating missing scripts
as a regular compiler error.
Related: rdar://40538097
The migrator only applies changes from the APIDiffMigratorPass in the primary
file. This means that if a nominal type was renamed, for example, any members
users have added in an extension in a separate file won't be visible, because
the extension would still have the old name. This can result in 'wrong argument
label' errors with fixits to change the argument labels that, when applied by
the fixit pass, completely change which function was being called and cause
post-migration errors.
This patch updates the fixit pass to ignore diag::wrong_argument_labels.
diag::extra_argument_labels and diag::missing_argument_labels were already
filtered out for other reasons.
Resolves rdar://problem/40170377
- Combine the common logic for editor mode and non-editor mode.
- Do a better job minimizing fix-its.
- If '@unknown' is the only missing case, put `fatalError()` in the
Xcode placeholder, since that's what the compiler would have done.
Also restore some diagnostics in TypeCheckType that should have
migrated with the attributes. In particular, diagnose cases where
we have @autoclosure with any function type repr with a non-Void
input type.
Resolves SR-5296
Saying "implicitly non-escaping because it was declared @autoclosure"
does not make sense. Since Swift 3, parameters of function type are
non-escaping by default, whether or not they are @autoclosure.
We would also inhibit the fixit for inserting @escaping if the
@autoclosure attribute was present. Again, a holdover from the
Swift 2 days, when @autoclosure implied @noescape and the special
@autoclosure(escaping) attribute was used to define an escaping
autoclosure.
We already had this functionality in the FixitApplyDiagnosticConsumer,
but we also need it in the AST passes because different entries in the
API diff data may drive identical fix-its, namely a general type rename,
which can occur anywhere a DeclRef appears, but also for function overrides'
parameter type changes, which are context specific.
rdar://problem/32431533
The clang::RewriteBuffer can do weird things when seeing multiple
replacements where the replacement text is one character longer or
one character shorter than the range it is replacing.
rdar://problem/32234525
- Don't include inserts in the offset calculation
- Fix colon placement when printing JSON
- Consolidate adjacent insert/removal pairs into a single replacement,
as this is what the remap applier expects.
rdar://problem/31872288
This can be incorrectly reported by the type-checker when
argument arity doesn't match in trailing closure arguments.
This diagnostic isn't generally useful for the migrator.
rdar://problem/32477119
rdar://problem/32432254
This isn't generally useful for Swift 4 migration and in some cases
can result in code that doesn't compile, like `for let i in ...`.
rdar://problem/32390791
rdar://problem/32390726
This allows the migrator to pick up fix-its from notes such as:
“Argument of #selector refers to instance method '___' that is not
exposed to Objective-C”
Add some more testing for minimal/complete workflows, and upstream
the cross-file fix-it test.
rdar://problem/32228948
```swift
func foo(f: Void) -> ()) {}
```
This compiler currently suggests we change this to:
```swift
func foo(f: (Void) -> ()) {}
```
That's `(()) -> ()`, almost certainly not what someone wants in Swift
4. We should suggest changing that to:
```swift
func foo(f: () -> ()) {}
```
Additionally,
```swift
func foo(f: (Void) -> ()) {}
```
Should trigger a warning that the `(Void)` input type is `(())`, and you
can't supply `()` to it in Swift 4, and suggest a fix-it change it to:
```swift
func foo(f: () -> ()) {}
```
rdar://problem/32143617
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
With SE-110, the migrator may get a recommendation to add a Void
placeholder in the call to f in:
func foo(f: (Void) -> ()) {
f()
}
Here, f was () -> () in Swift 3 but now (()) -> () in Swift 4. Adding a
type placeholder in the f() call isn't helpful for migration, although
this particular fix-it should be to fix the f parameter's type.
rdar://problem/31895432
Based on recommendations in SE-0160, there are two migration workflows:
- Conservative: Maintain @objc visibility that was inferred in Swift 3
by adding @objc to all declarations that were implicitily visible to
the Objective-C runtime. This is invoked in the migrator by adding the
-migrate-keep-objc-visibility flag.
- Minimal: Only declarations that must be visible to Objective-C based
on their uses (or in cases like dynamic vars) are migrated.
rdar://problem/31876357
This handles optionality changes and type rewrites in function param and return types and constructor param and failability types.
Resolves rdar://problem/31766010
I had set up the driver to invoke a separate frontend invocation with
the "update code" mode. We sort of did this last release, except we
forked to the swift-update binary instead. This is causing problems with
testing in Xcode.
Instead, let's perform a single compile and add the remap file as an
additional output during normal compiles. The driver, seeing
-update-code, will add -emit-remap-file-path $PATH to the -c frontend
invocation.
rdar://problem/31857580
