The diagnostic is now a warning and the new message alerts the user that
though it is valid to have let and var as argument label names,
they are interpreted as argument labels, not keywords.
Allow the use of declarations whose names start with $ in all
modes. However, normal code cannot define new entities with names that
start with $: only the implementation can do that, e.g., for property
delegates.
ParsedSyntaxBuilder has a convenient function to add member to a syntax-collection
child. The function name uses the type name of the collection's members,
which can lead to name collision. This patch renames it.
This adds an implicit body so that we can dig out the return type
context the same way as a normal function. For now, we are also treating
the first expression in a multi-statement implicit getter body the same
way; we'll need to refactor how we complete in accessors to
differentiate those cases.
When completing in the only expression of closure, use the return type
of the closure as the type context for the code-completion. However,
since code-completion may be on an incomplete input, we only use the
return type to improve the quality of the result, not to mark it
invalid, since (a) we may add another statement afterwards, or (b) if
the context type is Void it doesn't need to match the value.
This is just for use in the debugger when one may want to know what is in the
current scope. The order is not guaranteed but at least it can provide /some/
info ignoring that property. These are no-ops when not in asserts and I put in a
compile time warnign to make sure it is not used in the actual code base.
Previously, the Lexer kept a single flag whether we’re lexing Swift or SIL. Instead, keep track if we’re parsing Swift, SIL, or a Swiftinterface file. .swiftinterface files allow $-prefixed identifiers anywhere.
This eliminates the overhead of doing name lookups during parsing (which is unncessary during syntactic parsing) by enabling the `EnableASTScopeLookup` lang option.
This eliminates the overhead of ParsedRawSyntaxNode needing to do memory management.
If ParsedRawSyntaxNode needs to point to some data the memory is allocated from a bump allocator.
There are also some improvements on how the ParsedSyntaxBuilders work.
Avoid implicitely assuming 'null' node if its OpaqueSyntaxNode is null, there should be no interpretation
of OpaqueSyntaxNode values, a SyntaxParseActions implementation should be able to return null pointers as OpaqueSyntaxNode.
Doing a "direct ParsedSyntaxRecorder::record[some syntax]" call from the parser is not a good idea due to possibility
of being in a backtracking context when the call is made. Replace them with "ParsedSyntaxRecorder::make[some syntax]"
which will implicitly check for backtracking and create a recorded or deferred node accordingly.
Instead of creating syntax nodes directly, modify the parser to invoke an abstract interface 'SyntaxParseActions' while it is parsing the source code.
This decouples the act of parsing from the act of forming a syntax tree representation.
'SyntaxTreeCreator' is an implementation of SyntaxParseActions that handles the logic of creating a syntax tree.
To enforce the layering separation of parsing and syntax tree creation, a static library swiftSyntaxParse is introduced to compose the two.
This decoupling is important for introducing a syntax parser library for SwiftSyntax to directly access parsing.
Parsing collection literal expression used to take exponential time
depending on the nesting level of the first element.
Stop using 'parseList()' because using it complicates libSyntax parsing.
rdar://problem/45221238 / https://bugs.swift.org/browse/SR-9220
rdar://problem/38913395 / https://bugs.swift.org/browse/SR-7283
Instead of creating multiple CodeBlockItemList nodes, that need to get merged and discarded later on, do this:
* Ensure for libSyntax parsing that we parse the whole file
* Create top-level CodeBlockItem nodes that we just directly wrap with a single CodeBlockItemList node at the end
The importance of this change will become more obvious later on when we'll decouple syntax parsing from the formation of libSyntax tree nodes.
<rdar://problem/46548531> Extend @available to support PackageDescription
This introduces a new private availability kind "_PackageDescription" to
allow availability testing by an arbitary version that can be passed
using a new command-line flag "-swiftpm-manifest-version". The semantics
are exactly same as Swift version specific availability. In longer term,
it maybe possible to remove this enhancement once there is
a language-level availability support for 3rd party libraries.
Motivation:
Swift packages are configured using a Package.swift manifest file. The
manifest file uses a library called PackageDescription, which contains
various settings that can be configured for a package. The new additions
in the PackageDescription APIs are gated behind a "tools version" that
every manifest must declare. This means, packages don't automatically
get access to the new APIs. They need to update their declared tools
version in order to use the new API. This is basically similar to the
minimum deployment target version we have for our OSes.
This gating is important for allowing packages to maintain backwards
compatibility. SwiftPM currently checks for API usages at runtime in
order to implement this gating. This works reasonably well but can lead
to a poor experience with features like code-completion and module
interface generation in IDEs and editors (that use sourcekit-lsp) as
SwiftPM has no control over these features.
