Declare rules_swift max_compatibility_version = 2, set rules_swift to 1.18.0 #2725
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
don't we have to port these? https://github.com/apple/swift-syntax/blob/70e374101af89aaf998d04587455f0f8d4970751/BUILD.bazel#L310 I think we have to bump rules_apple as well here? |
|
hrm i guess we kept tags compat? because this does build for me locally after bumping rules_apple, also can you buildifier the module.bazel |
I didn't intent to bump Buildifier: ✅ |
|
@swift-ci please test |
keith
approved these changes
Jul 15, 2024
|
@swift-ci Please test Windows |
antigluten
added a commit
to antigluten/swift-syntax
that referenced
this pull request
Jul 18, 2024
[SwiftIfConfig] Add a new library for evaluating `#if` conditions.
Building on top of the parser and operator-precedence parsing library,
introduce a new library that evaluates `#if` conditions against a
particular build configuration. The build configuration is described
by the aptly named `BuildConfiguration` protocol, which has queries
for various build settings (e.g., configuration flags), compiler
capabilities (features and attributes), and target information (OS,
architecture, endianness, etc.).
At present, the only user-facing operation is the `IfConfigState`
initializer, which takes in an expression (the `#if` condition) and a
build configuration, then evaluates that expression against the build
condition to determine whether code covered by that condition is
active, inactive, or completely unparsed. This is a fairly low-level
API, meant to be a building block for more useful higher-level APIs
that query which `#if` clause is active and whether a particular syntax
node is active.
Add higher-level APIs for querying active code state
`IfConfigDeclSyntax.activeClause(in:)` determines which clause is
active within an `#if` syntax node.
`SyntaxProtocol.isActive(in:)` determines whether a given syntax node
is active in the program, based on the nested stack of `#if`
configurations.
Add support for evaluating `swift` and `compiler` conditionals
These were introduced by SE-0212.
Implement support for archaic `_compiler_version("X.Y.Z.W.V")` check
Add support for `canImport` configuration checks.
This is the last kind of check! Remove the `default` fallthrough from
the main evaluation function.
Improve documentation for `#if` configuration functions
Add `ActiveSyntax(Any)Visitor` visitor classes.
The `ActiveSyntax(Any)Visitor` visitor classes provide visitors that
only visit the regions of a syntax tree that are active according to
a particular build configuration, meaning that those nodes would be
included in a program that is built with that configuration.
Add/cleanup some TODO comments
Add an API to rewrite a syntax tree by removing inactive regions.
The operation `SyntaxProtocol.removingInactive(in:)` returns a syntax
tree derived from `self` that has removed all inactive syntax nodes based
on the provided configuration.
Implement inactive clause rewriting support for postfix `#if`
Postfix `#if` expressions have a different syntactic form than
other `#if` clauses because they don't fit into a list-like position in
the grammar. Implement a separate, recursive folding algorithm to handle
these clauses.
Add overview documentation for the SwiftIfConfig library
Add CMake build system for SwiftIfConfig
Format source
Improve documentation for BuildConfiguration
Improve documentation for internal `IfConfigFunctions`.
Address a number of review comments (thanks, Alex!)
[Build configuration] Drop optionality from protocol requirement result types
The optional return was used to mean "don't know", but was always
treated as false. Instead, make all of the result types non-optional,
and allow these operations to throw to indicate failure.
While here, drop the "syntax" parameters to all of these functions. We
shouldn't be working with syntax inside the build configuration.
Simplify `isActive(in:)` using Alex Hoppen's suggestion
Use preconditionFailure
Use editor placeholder for placeholder expression
Minor cleanups
Minor cleanups to the #if rewriter
Rework use of deprecated APIs
Teach active-clause visitors to handle diagnostics
When the active-clause visitors encounter an error during evaluation of
the `#if` conditions, translate the errors into diagnostics and and
visit all of the clauses (because we don't know which is active). This
behavior is configurable by ActiveSyntax(Any)Visitor subclasses.
Add SwiftIfConfig to the set of documentation targets
Fix typo in the release notes
Adapt to optionality changes on main
Add a method `Error.asDiagnostics(at:)` to unpack errors into diagnostics
This is a useful convenience function to handle cases where we have a
thrown error from some API and we want to translate it into a
diagnostic that we need to emit at a particular location.
Handle errors while removing inactive regions
When removing inactive regions via a visitor, accumulate any diagnostics
produced during this process so they can be reported. Introduce a test
harness so we can test these diagnostics more easily.
Handle diagnostics through #if condition evaluation
Allow #if condition evaluation to produce proper diagnostics, including
warnings, while performing the evaluation. This covers both
warnings/errors directly coming from #if handling and also those
thrown as errors by the build configuration.
Introduce assertion functions to make it a lot easier to properly test
the tests with calls to these assertions.
Add the remaining diagnostics that were FIXME'd because we couldn't
report them properly before.
Teach #if condition evaluation to reason about "versioned" checks
When a check is "versioned" and fails, we allow the failed #if block to
have syntactic errors in it. Start to reflect this distinction when
determining the `IfConfigState` for a particular condition, so that we
finally use the "unparsed" case.
Rework `isActive(in: configuration)` to distinguish inactive vs. unparsed
Update the interface of this function to return an `IfConfigState` rather
than just a `Bool`. Then, check the enclosing versioned conditions to
distinguish between inactive vs. unparsed. Finally, add a marker-based
assertion function that makes it easy to test the active state of any
location in the source code. Use the new test to flush out an obvious
bug in my original implementation of `isActive(in: configuration)`.
NFC: Split out IfConfigError and the VersionTuple parsing into their own files
Clarify documentation a little bit
Update CMake build for SwiftIfConfig changes
Add a new API to compute the "configured regions" of a syntax tree
This API produces information similar to the "active regions" API used
within the compiler and by SourceKit, a sorted array that indicates the #if
clauses that are active or inactive (including distinguishing inactive
vs. unparsed). When this array has already been computed for a syntax tree,
one can then use the new `SyntaxProtocol.isActive(inConfiguredRegions:)`
function to determine whether a given node is active. This can be more
efficient than the existing `SyntaxProtocol.isActive(in:)` when querying
for many nodes.
Test the new functionality by cross-checking the two `isActive`
implementations against each other on existing tests.
DocC cleanups
Test active code regions with postfix #if
Rename IfConfigState -> ConfiguredRegionState
The new name better describes that we're talking about regions that
have to do with the build configuration.
Handle invalid `#if` conditions as "unparsed" regions consistently
When determining active regions, treat clauses with invalid conditions
as "unparsed" regions, but don't abort the computation by throwing. This
provides behavior that is more consistent with the compiler, and is also
generally easy for most clients. Those clients that want to report
diagnostics can certainly do so, but are not forced to work with
throwing APIs for invalid code.
While here, improve the active syntax rewriting operation by making it
a two-pass operation. The first pass emits diagnostics and determines
whether there is any rewriting to do, and the second pass performs the
rewriting. This fixes an existing bug where the diagnostic locations
were wrong because we were emitting them against partially-rewritten
trees.
Reshuffle and rename some source files in SwiftIfConfig
Rename source files in SwiftIfConfig to better reflect what they do, move
the public APIs up to the tops of files, and split the massive
IfConfigEvaluation.swift into several files. The file itself defines the
core logic for doing the evaluation (which is internal to the library),
and other source files provide public APIs on top of it.
Add support for _hasAtomicBitWidth to evaluation
Declare rules_swift max_compatibility_version = 2, set rules_swift to 1.18.0 (swiftlang#2725)
Add an article about using `SWIFTSYNTAX_ENABLE_RAWSYNTAX_VALIDATION`
[MacroExamples] Update invalid URL example
Workaround for a Foundation bug that can return non-nil URL for
"https://not a url.com".
[Syntax] Mark the parameter of casting initializers '__shared'
Initializer parameters are "+1" in caller site, but these casting
initializers only uses the ._syntaxNode and don't store the parameter itself.
CONTRIBUTING.md: Update for new Swift.org section about release branch PRs
Code action to convert between computed property and stored property
improve diagnostic for unnamed closure parameters
- instead of treating as unrecognized, try to parse the remaining tokens as a type even if the preceding colon is missing
cc
luispadron
pushed a commit
to luispadron/swift-syntax
that referenced
this pull request
Aug 8, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This enables repos using
rules_swift2.0+ to work with swift-syntax.swift-syntax does not use any features unique to 1.x, nor have any implicit dependencies on 1.x rules. Tested via overriding
rules_appleto shac8a6f615e37c8781e28c65dafed03ecb378281b3, which sets rules_swift to 2.1.0.