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
llvm r283043 and possibly other recent changes switch to use StringRef
instead of char* pointers. Update Swift to match. In some cases, this is
a clear improvement. It would be good to assess the impact on memory use,
particularly for the Filename component of source locations.
Note that the change to SILLocation::isNull fixes an apparent bug where
the location was treated as null when the filename was *not* null.
- Added missing ifdef guard in PointerIntEnum header
- Consistent naming convention for ifdef guards
- Consistent 'end namespace swift'
- Consistent single EOL at end of header files
When users try to print the interface of a specific type (most often through cursor
infor query of SourceKit), we should simplify the original decls by replacing
archetypes with instantiated types, hiding extension details, and omitting
unfulfilled extension requirements. So the users can get the straight-to-the-point
"type interface". This commit builds the testing infrastructure for this feature,
and implements the first trick that wraps extension contents into the interface body.
This commit also moves some generic testing support from SourceKit to Swift.
Swift SVN r32630
llvm::Optional lives in "llvm/ADT/Optional.h". Like Clang, we can get
Optional in the 'swift' namespace by including "swift/Basic/LLVM.h".
We're now fully switched over to llvm::Optional!
Swift SVN r22477
Some of the buffers are owned by the ClangImporter, so after the
ClangImporter's been deallocated, the SourceManager isn't going to be fully
valid any more.
Should fix issues from r21958.
Swift SVN r21989
This rare crash happens when
1. A diagnostic is reported when building a Clang module.
2. The diagnostic is mapped to a Swift diagnostic by mirroring the Clang
source buffer as a Swift source buffer (via non-owning reference).
3. The Clang CompilerInstance used specifically to build the module is
destroyed.
4. Some /new/ buffer is allocated in the same memory spot as the old buffer.
5. Some new Clang diagnostic occurs in the new buffer.
6. The Swift source manager asserts when trying to set up a virtual name
for the diagnostic in the second imported buffer, because there's already
a name for that region.
The fix, because we don't expect diagnostics from modules to appear very
often, is to keep any clang::SourceManagers alive if diagnostics are emitted
in their buffers. We can revisit this if/when Swift's source manager
(currently built on llvm::SourceMgr) has the ability to remove buffers.
Many thanks to Greg for noticing the problem, tracking it down, and providing
a diff to make it fail reproducibly under GuardMalloc. I've tried to preserve
the spirit of that diff in the new logic in ~SourceManager, which will also
fail reliably with GuardMalloc (and probably ASan).
rdar://problem/18285805
Swift SVN r21958
...or at least the same machinery as #line. We add a (referential) mirror
of the Clang buffer to Swift's source manager, then remap that particular
line to whatever Clang currently thinks is the presumed location for that
line. (This means we respect Clang line directives too.)
This also modifies Swift's source manager to be more forgiving about adding
the same virtual file range twice; it will tell you when you try to do it.
<rdar://problem/16596800>
Swift SVN r20572
As part of this change, allow #line directives to extend to the end of the
file, rather than requiring a reset.
Note that #line regions that start or end within function bodies will not
behave correctly when in delayed parsing modes. This was true before and
after this commit. (#line regions contained entirely within a function and
not within any other #line regions should be fine.)
Swift SVN r20571
This patch extends the syntax with a new #line directive that is inspired
by the homonymous CPP directive. It can be specified in all locations a #if
is legal (Stmt, Decl).
Semantics
---------
#line 42 "file.swift"
This makes diagnostics and debug information behave as if the subsequent
lines came from file.swift+42.
#line // without arguments
This switches back to the main source file and the switches back to the
normal line numbering. Any previous #line directives will result in gaps
in the main file.
Rationale
---------
LLDB and the REPL need this for making expressions that are entered into
the expression evaluator or REPL debugable. For more info see
<rdar://problem/17441710> Need #line directive or something similar so we can enhance the debugging of expressions and REPL
Also, I believe the stdlib would benefit from this and it would allow us
to get rid of the line-directive wrapper script.
Swift SVN r19384
...in preparation for non-source locations, i.e. locations that don't come
frome source buffers.
No functionality change, but a fair bit of SourceManager API and idioms have
changed.
Swift SVN r18942
Adding these asserts would help debugging. Without the asserts it would fail
anyway, but in a more obscure place, usually with a null pointer dereference.
Swift SVN r14512
We can attach comments to declarations. Right now we only support comments
that precede the declarations (trailing comments will be supported later).
The implementation approach is different from one we have in Clang. In Swift
the Lexer attaches the comments to the next token, and parser checks if
comments are present on the first token of the declaration. This is much
cleaner, and faster than Clang's approach (where we perform a binary search on
source locations and do ad-hoc fixups afterwards).
The comment <-> decl correspondence is modeled as "virtual" attributes that can
not be spelled in the source. These attributes are not serialized at the
moment -- this will be implemented later.
Swift SVN r14031
Also remove the SourceLoc parameter from addNewSourceBuffer(). In llvm::SourceMgr
it is used to indicate textual inclusion, which we don't have in swift.
Swift SVN r10014
integration
Motivation: libIDE clients should be simple, and they should not have to
translate token-based SourceRanges to character locations.
This also allows us to remove the dependency of DiagnosticConsumer on the
Lexer. Now the DiagnosticEngine translates the diagnostics to CharSourceRanges
and passes character-based ranges to the DiagnosticConsumer.
Swift SVN r7173
Every valid source location corresponds to a source buffer. There should be no
cases where we create a source location for a random string. Thus,
findBufferContainingLoc() always succeeds.
Swift SVN r7120
Also centralizes the knowledge about whether the hashbang is allowed in the
SourceManager. This fixes a bug in tokenize() because previously it just had
to guess.
Swift SVN r6822
around everywhere
Fixes:
rdar://14585108 Code completion does not work at the beginning of the file
rdar://14592634 Code completion returns zero results at EOF in a function
without a closing brace
Swift SVN r6820
