Add an option to the lexer to go back and get a list of "full"
tokens, which include their leading and trailing trivia, which
we can index into from SourceLocs in the current AST.
This starts the Syntax sublibrary, which will support structured
editing APIs. Some skeleton support and basic implementations are
in place for types and generics in the grammar. Yes, it's slightly
redundant with what we have right now. lib/AST conflates syntax
and semantics in the same place(s); this is a first step in changing
that to separate the two concepts for clarity and also to get closer
to incremental parsing and type-checking. The goal is to eventually
extract all of the syntactic information from lib/AST and change that
to be more of a semantic/symbolic model.
Stub out a Semantics manager. This ought to eventually be used as a hub
for encapsulating lazily computed semantic information for syntax nodes.
For the time being, it can serve as a temporary place for mapping from
Syntax nodes to semantically full lib/AST nodes.
This is still in a molten state - don't get too close, wear appropriate
proximity suits, etc.
In LLVM, the convention is that *_INCLUDE_* means that cmake will generate
targets but says nothing about whether or not something will be built by default
or not. This means that as far as cmake is concerned, those targets do not
exist.
On the other hand, *_BUILD_* determines whether or not a class of things is a
dependency of the "all" target. Of course this implies that *_BUILD_* implies
that *_INCLUDE_* must be set to TRUE.
Currently SWIFT_BUILD_TOOLS is implemented like a *_INCLUDE_* option, so change
its name to SWIFT_INCLUDE_TOOLS.
We'd like to be able to compare TypeRefs with pointer equality,
but we can't link LLVMSupport, so make a lightweight TypeRefID
like FoldingSetID, that only supports the input types necessary
to unique TypeRefs.
rdar://problem/25924875
The code goes into its own sub-tree under 'tools' but tests go under 'test',
so that running 'check-swift' will also run all the SourceKit tests.
SourceKit is disabled on non-darwin platforms.
This way they can be used from other projects, like LLDB. The downside
is we now have to make sure the header is included consistently in all
the places we care about, but I think in practice that won't be a problem,
especially not with tests.
rdar://problem/22240127
Swift SVN r31173
Replace ReST-flavored documentation comments with Markdown.
rdar://problem/20180412
In addition to full Markdown support, the following extensions are
supported. These appear as lists at the top level of the comment's
"document". All of these extensions are matched without regard to
case.
Parameter Outlines
------------------
- Parameters:
- x: ...
- y: ...
Separate Parameters
-------------------
- parameter x: ...
- parameter y: ...
- Note:
Parameter documentation may be broken up across the entire comment,
with a mix of parameter documentation kinds - they'll be consolidated
in the end.
Returns
-------
- returns: ...
The following extensions are also list items at the top level, which
will also appear in Xcode QuickHelp as first-class citizens:
- Attention: ...
- Author: ...
- Authors: ...
- Bug: ...
- Complexity: ...
- Copyright: ...
- Date: ...
- Experiment: ...
- Important: ...
- Invariant: ...
- Note: ...
- Postcondition: ...
- Precondition: ...
- Remark: ...
- Remarks: ...
- See: ...
- Since: ...
- Todo: ...
- Version: ...
- Warning: ...
These match most of the extra fields in Doxygen, plus a few more per request.
Other changes
-------------
- Remove use of rawHTML for all markup AST nodes except for those
not representable by the Xcode QuickHelp XSLT - <h>, <hr/>, and of
course inline/block HTML itself.
- Update the doc comment RNG schema to more accurately reflect Xcode
QuickHelp.
- Clean up cmark CMake configuration.
- Rename "FullComment" to "DocComment"
- Update the Swift Standard Documentation (in a follow-up commit)
- Update SourceKit for minor changes and link against cmark
(in a follow-up commit).
Swift SVN r27727
This library becomes a permanent interface that we would need to support
in the long term, so we should get dylib names and APIs right.
rdar://20418214
Swift SVN r26957
...and rename it to swift_common_llvm_config.
This is the function that acts like llvm_config but handles the LLVM build
being a different configuration from the Swift (or SourceKit) build, which
can be problematic for multi-configuration build schemes like Xcode.
There's also one fix here: LLVM dependencies for dylibs weren't being
properly added. (This is the "SHARED_LIBRARY" case near the bottom.)
Swift SVN r26631
(and similar mixed modes)
This is duplicating some of the work in swift_llvm_config, and should
probably be refactored back there at some point, but for now this gets
unit tests building in Xcode when the build configurations for LLVM and
Swift aren't the same.
Swift SVN r24257
Whatever difficulty there supposedly was in doing this for Clang must
apply only to standalone builds where no LLVM source is available.
Swift SVN r3057
