* Pack the bits for IfConfigDecls into Decl
* Don't open symbols into a module when evaluating canImport statements
The module loaders now have API to check whether a given module can be
imported without importing the referenced module. This provides a
significant speed boost to condition resolution and no longer
introduces symbols from the referenced module into the current context
without the user explicitly requesting it.
The definition of ‘canImport’ does not necessarily mean that a full
import without error is possible, merely that the path to the import is
visible to the compiler and the module is loadable in some form or
another.
Note that this means this check is insufficient to guarantee that you
are on one platform or another. For those kinds of checks, use
‘os(OSNAME)’.
Fixes SR-2757.
Variables in capture lists are treated as 'let' constants, which can
result in misleading, incorrect diagnostics. Mark them as such in order
to produce better diagnostics, by adding an extra parameter to the
VarDecl initializer.
Alternatively, these variables could be marked as implicit, but that
results in other diagnostic problems: capture list variables that are
never used produce warnings, but these warnings aren't normally emitted for
implicit variables. Other assertions in the compiler also misfire when
these variables are treated as implicit.
Another alternative would be to walk up the AST and determine whether
the `VarDecl`, but there doesn't appear to be a way to do so.
Being lazy here just means we don’t validate the entire if
configuration. We need to be able to emit diagnostics even in
condition clauses with indeterminate expressions.
Addresses SR-2605.
If you're refactoring a `guard` into an `if`, it's easy to
accidentally end up with invalid code like this in the transition:
```
if condition else {
}
```
The parser rightly complains about the `else`, but has poor recovery
afterward, interpreting the following brace as a closure, which may in
turn lead to other unhelpful errors after:
```
error: expected '{' after 'if' condition
if condition else {
^
error: braced block of statements is an unused closure
if condition else {
^
```
Improve the diagnostics to instead explicitly detect this pattern and
mark it as an error.
This completely removes Parse’s ability to make any judgement calls
about compilation conditions, instead the parser-relevant parts of
‘evaluateConditionalCompilationExpr’ have been moved into
‘classifyConditionalCompilationExpr’ where they exist to make sure only
decls that we want to parse actually parse later.
The condition-evaluation parts have been moved into NameBinding in the
form of a Walker that evaluates and collapses IfConfigs. This walker
is meant as an homage to PlaygroundLogger. It should probably be
factored out into a common walker at some point in the future.
Implemented in the naive way by way of the current ASTContext’s
‘LoadedModules’. In theory this list should be in one-to-one
correspondence with the definition of “importable” as any module that
is required for compilation is loaded *before* we start parsing the
file. This means we don’t have to load the module, just check that
it’s in the set of loaded modules.
Note that this approach will most likely fall apart if submodules are
introduced and are lazily loaded. At that point this will need to be
refactored into a format that defers the checking of conditions
sometime before or during typechecking (after namebinding).
parseBraceItems() has specific logic for pasing conditional compilation blocks.
Withoutout that, decralations in the block cannot be propagated to outside.
For instance:
FOO: #if true
func foo() {}
#endif
foo() // error: use of unresolved identifier 'foo'
The tentantive parse is used for diagnostic purposes but can cause code-completion to delay the same decl twice.
The range of CodeCompletionExpr was previously character range which invalidated invariants of the AST.
Fixes:
validation-test/IDE/crashers_fixed/084-swift-parser-consumedecl.swift
validation-test/IDE/crashers_fixed/104-swift-gettypeofcompletioncontextexpr.swift
For constructing the dummy expression for missing initializer,
use the end location of the pattern instead of the location of the
current token.
Previous behavior used to build AST like:
{ if let x [eof]
|---| Pattern range
|---| Dummy introducer range
|------------| IfStmt range
|--------| BraceStmt range
Now:
{ if let x [eof]
|---| Pattern range
| Dummy introducer range
|------| IfStmt range
|--------| BraceStmt range
These APIs return SourceLocs, and eventually the Parser should consume
tokens, which now include source trivia such as whitespace and comments,
and package them into a purely syntactic tree. Just a tiny step. NFC.
Store leading a trailing "trivia" around a token, such as whitespace,
comments, doc comments, and escaping backticks. These are syntactically
important for preserving formatting when printing ASTs but don't
semantically affect the program.
Tokens take all trailing trivia up to, but not including, the next
newline. This is important to maintain checks that statements without
semicolon separators start on a new line, among other things.
Trivia are now data attached to the ends of tokens, not tokens
themselves.
Create a new Syntax sublibrary for upcoming immutable, persistent,
thread-safe ASTs, which will contain only the syntactic information
about source structure, as well as for generating new source code, and
structural editing. Proactively move swift::Token into there.
Since this patch is getting a bit large, a token fuzzer which checks
for round-trip equivlence with the workflow:
fuzzer => token stream => file1
=> Lexer => token stream => file 2 => diff(file1, file2)
Will arrive in a subsequent commit.
This patch does not change the grammar.
This flag switches the "effective language version" of the compiler,
at least to any version supported (as of this change: "3" or "3.0").
At the moment nothing uses it except the language version build
configuration statements (#if swift(...)) and various other places
that report, encode, or otherwise check version numbers.
In the future, it's intended as scaffolding for backwards compatibility.
Fixes SR-2582
The scope map relies fairly deeply on having reasonable source ranges
for AST nodes. Fix the construction and query of source ranges in a
few places throughout the parser and AST to provide stronger
invariants.
Introduce several new factory methods to create CallExprs, and hide
the constructor. The primary reason for this refactor is to start
moving clients over to the factory method that takes the call
arguments separately from the argument labels. Internally, it
repackages those arguments into a TupleExpr or ParenExpr (as
appropriate) so the result ASTs are the same. However, this will make
it easier for us to tease out the arguments themselves in the
implementation of SE-0111.
...by canonicalizing it to the known platform name. This isn't a
wonderful answer, but it preserves the invariant that a platform
condition has at most one value.
A later commit will switch which one is the default.
In the condition expressions of if, while and guard statements we were
throwing away the AST if there was a parse error in the condition, or
the brace statement was missing. This led to poor code-completion for
unresolved members (enums, options sets) because we couldn't find the
parent expression to type-check.
There are a few minor diagnostic changes because we now do more
type-checking of these conditions, particularly if they end up
containing an unused closure.
SR-2001
known as #sourceLocation. #setline was an intermediate but never endorsed state.
Upgrade the migration diagnostics for SE-0066 and SE-0049 to be errors instead of warnings.
The verifier now asserts that Throws, ThrowsLoc and isBodyThrowing()
match up.
Also, add /*Label=*/ comments where necessary to make the long argument
lists easier to read, and cleaned up some inconsistent naming conventions.
I caught a case where ClangImporter where we were passing in a loc as
StaticLoc instead of FuncLoc, but probably this didn't affect anything.
Improve the error recovery so that we get back either a RepeatWhileStmt,
or at least a BraceStmt, which code-completion can use to dig out the
local variables.
rdar://problem/25912182
This fixit checks if a decl with the identical name can be found in the parent type
context; if can, we add "self." to try to resolve the issue. rdar://25389852
