`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
Basic should not be allowed to link Parse, yet it was doing so
to allow Version to provide a constructor that would conveniently
parse a StringRef. This entrypoint also emitted diagnostics, so it
pulled in libAST.
Sink the version parser entrypoint down into Parse where it belongs
and point all the clients to the right place.
When the source code is invalid, this allows us to represent tokens that could not be used to form a valid syntax tree with more fidelity.
This commit does not start using GarbageNodes yet, it just sets everything up for them.
Introduce support for parsing declaration attributes that occur within
example:
#if hasAttribute(frozen)
@frozen
#endif
public struct X { ... }
will apply to "frozen" attribute to the struct `X`, but only when the
compiler supports the "frozen" attribute.
Correctly determining whether a particular `#if` block contains
attributes to be associated with the following declaration vs.
starting a new declaration requires arbitrary lookahead. The parser
will ensure that at least one of the branches of the `#if` contains an
attribute, and that none of the branches contains something that does
not fit the attribute grammar, before committing to parsing the `#if`
clause as part of the declaration attributes. This lookahead does
occur at the top level (e.g., in the parsing of top-level declarations
and code), but should only need to scan past the first `#if` line to
the following token in the common case.
Unlike other `#if` when used to wrap statements or declarations, we
make no attempt to record the `#if` not taken anywhere in the AST.
This reflects a change in attitude in the design of the AST, because
we have found that trying to represent this information there (e.g.,
via `IfConfigDecl`) complicates clients while providing little value.
This information is best kept in the syntax tree, only.
When we encounter a check like `#if compiler(>=6.0) && something` or
`#if swift(<6.0) || something`, and the left-hand term is a versioning
check that determines the result of the whole condition, then we will
not attempt to validate the right-hand term. This allows us to use
versioned checks along with new discovery features (say, if we add an
`#if attribute(x)`) without having to next conditions.
Introduce the `-enable-upcoming-feature X` command-line argument to
allow one to opt into features that will be enabled in an upcoming language
mode. Stage in several features this way (`ConciseMagicFile`,
`ForwardTrailingClosures`, `BareSlashRegexLiterals`).
The `SWIFT_COMPILER_VERSION` define is used to stamp a vendor’s version number into a Swift compiler binary. It can be queried from Swift code using `#if _compiler_version` and from Clang by using a preprocessor definition called `__SWIFT_COMPILER_VERSION`. These are unsupported compiler-internal features used primarily by Apple Swift.
In Swift 1.0 through 5.5, Apple Swift used a scheme for `SWIFT_COMPILER_VERSION` where the major version matched the embedded clang (e.g. 1300 for Apple Clang 13.0.0) and the minor version was ignored. Starting in Swift 5.6, Apple Swift started using major and minor version numbers that matched the Swift.org version number. This makes them easier to understand, but it means that version 1300.0.x was followed by version 5.6.x. Not only did version numbers go backwards, but also the old logic to ignore minor versions was now a liability, because it meant you would not be able to target a change to 5.7.x compilers but not 5.6.x compilers.
This commit addresses the problem by:
* Modifying the existing `#if _compiler_version(string-literal)` feature so it transforms the major version into a major and minor that will compare correctly to new version numbers. For instance, “1300.*” is transformed into “1.300”, which will compare correctly to a “5.6” or “5.7” version even if it doesn’t really capture the fact that “1300” was a Swift 5.5 compiler. As a bonus, this allows you to use the feature to backwards-compatibly test new compilers using the existing feature: “5007.*” will be seen by compilers before 5.7 as an unknown future version, but will be seen by 5.7 compilers as targeting them.
* Modifying the `__SWIFT_COMPILER_VERSION` clang define similarly so that, to preprocessor conditions written for the old scheme, a 5.7 compiler will appear to have major version 5007.
* Adding a new variant of `#if _compiler_version` with the same syntax as `#if swift` and `#if compiler`—that is, taking a comparison operator and a bare set of dotted version numbers, rather than a string literal. Going forward, this will be how version checks are written once compatibility with compilers before this change is no longer a concern.
These changes are only lightly tested because tests have to work without any compiler version defined (the default in most configurations), but I’ve tested what I can.
Fixes rdar://89841295.
Split up the expr list parsing members such that
there are separate entry points for tuple and
argument list parsing, and start using the argument
list parsing member for call and subscripts.
Abstract away the TupleExpr gunk and expose
`getLHS` and `getRHS` accessors. This is in
preparation for completely expunging the use
of TupleExpr as an argument list.
canImport should be able to take an additional parameter labeled by either version or
underlyingVersion. We need underlyingVersion for clang modules with Swift overlays because they
have separate version numbers. The library users are usually interested in checking the importability
of the underlying clang module instead of its Swift overlay.
Part of rdar://73992299
Introduce some basic support for defining specific language features
that can be checked by name, e.g.,
#if $AsyncAwait
// use the feature
#endif
For backward compatibility with older compilers, to actually prevent
the parser from parsing, one will have to do a Swift compiler version
check, even though the version number doesn't matter. For example:
#if compiler(>=5.3) && $AsyncAwait
// use the feature
#endif
We have two ways of knowing if we're inside of an inactive #if clause.
Refactor the only two places that called getScopeInfo().isInactiveConfigBlock()
to check InInactiveClauseEnvironment instead.
This removes the last remaining usage of Scope that's not related to
parse-time name lookup.
Currently when parsing a SourceFile, the parser
gets handed pointers so that it can write the
interface hash and collected tokens directly into
the file. It can also call `setSyntaxRoot` at
the end of parsing to set the syntax tree.
In preparation for the removal of
`performParseOnly`, this commit formalizes these
values as outputs of `ParseSourceFileRequest`,
ensuring that the file gets parsed when the
interface hash, collected tokens, or syntax tree
is queried.
Remove the `EvaluateConditionals` flags from the
parser, and instead query the source file.
This commit also changes ParserUnit such that it
doesn't evaluate #if conditions by default, as
none of its clients appear to require it. The
only client that wasn't explicitly disabling #if
evaluation and is processing the resulting AST is
swift-indent, so this commit also adds a test to
ensure it continues to work correctly with #if
decls.
Add support for conditional compilation under macCatalyst
Developers can now detect whether they are compiling for macCatalyst at
compile time with:
#if targetEnvironment(macCatalyst)
// Code only compiled under macCatalyst.
#end
For example, for "#if os(simulator)", offer a fixit to change
"os" to "targetEnvironment", instead of offering to change "simulator".
Resolves SR-11037.
Instead of creating the AST directly in the parser (and libSyntax or
SwiftSyntax via SyntaxParsingContext), make Parser to explicitly create
a tree of ParsedSyntaxNodes. Their OpaqueSyntaxNodes can be either
libSyntax or SwiftSyntax. If AST is needed, it can be generated from the
libSyntax tree.
