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
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
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
Added a -v(verbose) option to swift that will trigger verbose printing in SIL
Printer. SIL Printer will print the location info only in the verbose mode.
Here is the example of the format - only the line and colon are displayed for
brevity:
%24 = apply %13(%22) : $[cc(method), thin] ((), [byref] Bool) -> Builtin.Int1 // user: %26 line:46:10
(This will be used to test the validity of SILLocation info.)
Swift SVN r6991
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
