...because "build configuration" is already the name of an Xcode feature.
- '#if' et al are "conditional compilation directives".
- The condition is a "conditional compilation expression", or just
"condition" if it's obvious.
- The predicates are "platform conditions" (including 'swift(>=...)')
- The options set with -D are "custom conditional compilation flags".
(Thanks, Kevin!)
I left "IfConfigDecl" as is, as well as SourceKit's various "BuildConfig"
settings because some of them are part of the SourceKit request format.
We can change these in follow-up commits, or not.
rdar://problem/19812930
Introduce a new "swift" build configuration that guards declarations
and statements with a language version - if the current language version
of the compiler is at least that version, the block will parse as normal.
For inactive blocks, the code will not be parsed an no diagnostics will
be emitted there.
Example:
#if swift(>=2.2)
print("Active")
#else
this code will not parse or emit diagnostics
#endif
https://github.com/apple/swift-evolution/blob/master/proposals/0020-if-swift-version.md
rdar://problem/19823607
r32195 introduced new behavior when there was an error with a build
config: if there was an error, never parse. This was to prevent noise
when a block of code guarded by a _compiler_version clause was
syntatically wrong/misspelled, making it active when it shouldn't have
been. This supressed parsing blocks guarded by other build configs,
which is kind of a regression since, until _compiler_version, all build
configs were always parsed, even if their clauses are inactive. Skipping
parsing may hinder indentation, code folding, and parse-aware
highlighting.
If there is a valid switch on _compiler_version, continue to
skip parsing and supress Lex diagnostics for inactive blocks. If there
is an error evaluating a build config, parse all of its blocks.
rdar://problem/22730282
Swift SVN r32205
This configuration clause will suppress lex diagnostics and skip parsing
altogether if the code under the clause isn't active - the compiler must
have a repository version greater than or equal to the version given to
_compiler_version.
This option is only meant to be used sparingly and not to track the
Swift *language* version.
Example, if using a compiler versioned 700.0.28:
#if _compiler_version("700.0.23")
print("This code will compile for versions 700.0.23 and later.")
#else
This + code + will + not + be + parsed
#endif
Included are new diagnostics for checking that the version is formatted
correctly and isn't empty.
New tests:
- Compiler version comparison unit tests
- Build configuration diagnostics
- Skipping parsing of code under inactive clauses
rdar://problem/22730282
Swift SVN r32195
This finally fixes a few code completion test cases.
This also regresses the error message in one parsing testcase because
previously we would just happily skip those tokens, but now error handling path
is a little bit different and these tokens hit different error handling code.
This can be fixed by parsing a tuple for the selector argument and complaining
if the tuple had more than one element.
Swift SVN r7389
This will allow us to do code completion inside lists (e.g., tuples) *and* get
parser recovery instead of stopping at the code completion token immediately.
Swift SVN r7366
This allows the parser to recover, create an AST node, return it to the caller
*and* signal the caller that there was an error to trigger recovery in the
caller. Until now the error was signalled with a nullptr result (any non-null
result was considered a success and no recovery was done in that case).
This also allows us to signal the caller if there was a code completion token
inside the production we tried to parse to trigger delayed parsing in the
caller while doing recovery in the callee. Until now we could not do recovery
in the callee so that the caller could find the code completion token.
Right now we don't take any advantage of these features. This commit just
replaces some uses of NullablePtr with ParserResult.
Swift SVN r7332
