ANN: allow leading | in nested or patterns #9238
Conversation
afetisov
changed the title
|
👍 |
| if (parent is RsPat) { | ||
| val firstChild = orPat.firstChild | ||
| if (firstChild?.elementType == RsElementTypes.OR) { | ||
| holder.createErrorAnnotation( | ||
| firstChild, | ||
| "a leading `|` is only allowed in a top-level pattern", | ||
| RemoveElementFix(firstChild) | ||
| ) | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
Actually, it would be nice to produce this error if or_patterns compiler feature is not available since we support old compiler versions
There was a problem hiding this comment.
I thought about it, but the compiler is so old that I decided it wasn't worth mentioning (and doesn't worth postponing this PR merging). But, well, yes, it would be nice
There was a problem hiding this comment.
Do we? I vaguely recall that somewhere in the docs there was something like "support last 6 compiler versions", but I couldn't find it now. Additionally, supporting old versions, particularly nightly versions, is problematic since the compiler changes a lot. Fundamental traits change, lang items change, semantics change (e.g. the new try trait v.2). Also the IDE is so severely lacking in error diagnostics (even the borrow checker isn't implemented) that it feels weird to track stabilized features.
There was a problem hiding this comment.
I vaguely recall that somewhere in the docs there was something like "support last 6 compiler versions", but I couldn't find it now
We have never introduced such policies. Currently, we consider that 1.41 is the oldest compiler version the plugin supports - at least, we run tests with it. Of course, some features are not supported for old compilers for different reasons but anyway
Additionally, supporting old versions, particularly nightly versions, is problematic since the compiler changes a lot
I think the current approach (org.rust.lang.core.CompilerFeature#check) works well enough and it's quite easy to use. Yeah, it won't work with the feature which is just stabilized and the newest nightly compiler, but the main idea (in general) is to support old stable compilers since not all users update their compiler
it feels weird to track stabilized features.
I don't see any problem here since infrastructure for compiler features is already implemented, and it doesn't require a lot of effort to support all versions
even the borrow checker isn't implemented
Note, we consider it as one of the most complex compiler errors from implementation point of view, so it's not "even". But it's reasonable enough to say the same thing about "unresolved references" 😅
There was a problem hiding this comment.
It's complex, yes. It's also the core feature of the language.
I think the current approach (org.rust.lang.core.CompilerFeature#check) works well enough and it's quite easy to use.
The change in the PR never had a feature gate. It was just a temporary restriction of the nightly compiler, and it landed on stable together with general or-patterns.
Tracking the nightly compiler implementation is infeasible, it changes all the time.
Also, false negative inspections are a much smaller issue than false positives, since the user will likely run Clippy or cargo check anyway.
|
Build succeeded: |
Fixes #9001
Nested or-patterns were stabilized in Rust 1.53. The final design allows leading vertical bar
|in nested or-patterns, just like toplevel or-patterns. This was previously an explicit error, also implemented in the plugin.This PR reverts the deprecated error on nested patterns.
changelog: allow leading | in nested or-patterns