When we requestify `getInitKind`, we don't want to invoke the request during parsing. What the parsing code
really cares about is whether or not the decl has `ConvenienceAttr`.
When the parser wires up the body of a function, it's a legitimate use of
setting a parsed body. Separate these out from the other uses of
setBody() that we want to eliminate over time.
A number of callers to AbstractFunctionDecl::getBody() were only
extracting the source range of the body... which can be retrieved more
efficiently with getBodySourceRange().
- When parsing a type or extension declaration, attempt to parse a function or property declaration when meeting an identifier, an operator or a paren (for tuple declarations).
- Produce the diagnostic with a fix-it suggesting to insert the needed keyword
- Recover parsing as if the declaration with the missing keyword is a function/property declaration
Resolves https://bugs.swift.org/browse/SR-10477
This is a step in the direction of fixing the fallthrough bug. Specifically, in
this commit I give case stmts a set of var decls for the bodies of the case
statement. I have not wired them up to anything except the var decl
list/typechecking.
rdar://47467128
We weren't renaming all occurrences of 'x' in the cases like the below:
case .first(let x), .second(let x):
print("foo \(x)")
fallthrough
case .third(let x):
print("bar \(x)")
We would previously only rename occurrences within the case statement the query
was made in (ignoring fallthroughs) and for cases with multiple patterns (as in
the first case above) we would only rename the occurrence in the first pattern.
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.
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.
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.
`#assert` is a new static assertion statement that will let us write
tests for the new constant evaluation infrastructure that we are working
on. `#assert` works by lowering to a `Builtin.poundAssert` SIL
instruction. The constant evaluation infrastructure will look for these
SIL instructions, const-evaluate their conditions, and emit errors if
the conditions are non-constant or false.
This commit implements parsing, typechecking and SILGen for `#assert`.
Type may depend on its suffix. Parsing complete expression including its
suffix improves context type info around the CC token.
rdar://problem/44143964
Make sure StructureMarkerRAII checks structure nesting level on all paths. Previously swift crashed with no diagnostic on deeply nested '('. Now we print an error when more than 256 parens deep, just as we always have for '['.
fixes SR-4866
Parsed declarations would create an untyped 'self' parameter;
synthesized, imported and deserialized declarations would get a
typed one.
In reality the type, if any, depends completely on the properties
of the function in question, so we can just lazily create the
'self' parameter when needed.
If the function already has a type, we give it a type right there;
otherwise, we check if a 'self' was already created when we
compute a function's type and set the type of 'self' then.
This was meant to be `Status |= ThePattern`. But it actually should be
removed because we don't want to propagate isParseError() status as it's
recovered, and we propagate hasCodeCompletion() below.
Using dummy UnresolvedMemberExpr doesn't give us much benefit. Instead, use
CodeCompletionExpr which is type checked as type variable so can use
CodeCompletionTypeContextAnalyzer to infer context types.
This way, we can eliminate most of special logic for UnresolvedMember.
rdar://problem/39098974
Fix ASTVerifier error for end location of 'IfConfigDecl'.
Previously, for:
```
#if
// something
<COMPLETE>
```
End location of the dummy body of 'TopLevelCodeDecl' was at the eof, but the
end loc of the 'IfConfigDecl' was at the code-completion token. That
caused the ASTVerifier error "invalid IfConfigStmt end location".
https://bugs.swift.org/browse/SR-2364
rdar://problem/41217187
For now, the accessors have been underscored as `_read` and `_modify`.
I'll prepare an evolution proposal for this feature which should allow
us to remove the underscores or, y'know, rename them to `purple` and
`lettuce`.
`_read` accessors do not make any effort yet to avoid copying the
value being yielded. I'll work on it in follow-up patches.
Opaque accesses to properties and subscripts defined with `_modify`
accessors will use an inefficient `materializeForSet` pattern that
materializes the value to a temporary instead of accessing it in-place.
That will be fixed by migrating to `modify` over `materializeForSet`,
which is next up after the `read` optimizations.
SIL ownership verification doesn't pass yet for the test cases here
because of a general fault in SILGen where borrows can outlive their
borrowed value due to being cleaned up on the general cleanup stack
when the borrowed value is cleaned up on the formal-access stack.
Michael, Andy, and I discussed various ways to fix this, but it seems
clear to me that it's not in any way specific to coroutine accesses.
rdar://35399664
There are two general constructor forms here:
- One took the number of parameter lists, to be filled in later.
Now, this takes a boolean indicating if there is an implicit
'self'.
- The other one took the actual parameter lists and filled them
in right away. This now takes a separate 'self' ParamDecl and
ParameterList.
Instead of storing the number of parameter lists, an
AbstractFunctionDecl now only needs to store if there is a 'self'
or not.
I've updated most places that construct AbstractFunctionDecls to
properly use these new forms. In the ClangImporter, there is
more code that remains to be untangled, so we continue to build
multiple ParameterLists and unpack them into a ParamDecl and
ParameterList at the last minute.
