| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
```
error: unused variable: `Batery`
--> $DIR/binding-typo-2.rs:110:9
|
LL | Batery => {}
| ^^^^^^
|
help: if this is intentional, prefix it with an underscore
|
LL | _Batery => {}
| +
help: you might have meant to pattern match on the similarly named constant `Battery`
|
LL | Battery => {}
| +
```
|
|
When encountering a typo in a pattern that gets interpreted as an unused binding, look for unit struct/variant of the same type as the binding:
```
error: unused variable: `Non`
--> $DIR/binding-typo-2.rs:36:9
|
LL | Non => {}
| ^^^
|
help: if this is intentional, prefix it with an underscore
|
LL | _Non => {}
| +
help: you might have meant to pattern match on the similarly named variant `None`
|
LL - Non => {}
LL + std::prelude::v1::None => {}
|
```
|
|
structs/variants for suggestions
When encountering an or-pattern with a binding not available in all patterns, look for consts and unit struct/variants that have similar names as the binding to detect typos.
```
error[E0408]: variable `Ban` is not bound in all patterns
--> $DIR/binding-typo.rs:22:9
|
LL | (Foo, _) | (Ban, Foo) => {}
| ^^^^^^^^ --- variable not in all patterns
| |
| pattern doesn't bind `Ban`
|
help: you might have meant to use the similarly named unit variant `Bar`
|
LL - (Foo, _) | (Ban, Foo) => {}
LL + (Foo, _) | (Bar, Foo) => {}
|
```
For items that are not in the immedate scope, suggest the full path for them:
```
error[E0408]: variable `Non` is not bound in all patterns
--> $DIR/binding-typo-2.rs:51:16
|
LL | (Non | Some(_))=> {}
| --- ^^^^^^^ pattern doesn't bind `Non`
| |
| variable not in all patterns
|
help: you might have meant to use the similarly named unit variant `None`
|
LL - (Non | Some(_))=> {}
LL + (core::option::Option::None | Some(_))=> {}
|
```
|
|
|
|
```
error[E0408]: variable `Ban` is not bound in all patterns
--> f12.rs:9:9
|
9 | (Foo,Bar)|(Ban,Foo) => {}
| ^^^^^^^^^ --- variable not in all patterns
| |
| pattern doesn't bind `Ban`
|
help: you might have meant to use the similarly named previously used binding `Bar`
|
9 - (Foo,Bar)|(Ban,Foo) => {}
9 + (Foo,Bar)|(Bar,Foo) => {}
|
```
|
|
match exhaustiveness diagnostics: show a trailing comma on singleton tuple consructors in witness patterns (and clean up a little)
Constructor patterns of type `(T,)` are written `(pat,)`, not `(pat)`. However, exhaustiveness/usefulness diagnostics would print them as `(pat)` when e.g. providing a witness of non-exhaustiveness and suggesting adding arms to make matches exhaustive; this would result in an error when applied.
rust-analyzer already prints the trailing comma, so it doesn't need changing.
This also includes some cleanup in the second commit, with justification in the commit message.
|
|
|
|
|
|
|
|
Relocate tests in `tests/ui`
Part of #133895
Moved tests from a top-level directory into a more appropriate subdirectory.
If there is anything else that could be improved, please let me know!
r? jieyouxu
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #138632 (Stabilize `cfg_boolean_literals`)
- #139416 (unstable book; document `macro_metavar_expr_concat`)
- #139782 (Consistent with treating Ctor Call as Struct in liveness analysis)
- #139885 (document RUSTC_BOOTSTRAP, RUSTC_OVERRIDE_VERSION_STRING, and -Z allow-features in the unstable book)
- #139904 (Explicitly annotate edition for `unpretty=expanded` and `unpretty=hir` tests)
- #139932 (transmutability: Refactor tests for simplicity)
- #139944 (Move eager translation to a method on Diag)
- #139948 (git: ignore `60600a6fa403216bfd66e04f948b1822f6450af7` for blame purposes)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=davidtwco,Urgau,traviscross
Stabilize `cfg_boolean_literals`
Closes #131204
`@rustbot` labels +T-lang +I-lang-nominated
This will end up conflicting with the test in #138293 so whichever doesn't land first will need updating
--
# Stabilization Report
## General design
### What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized?
[RFC 3695](https://github.com/rust-lang/rfcs/pull/3695), none.
### What behavior are we committing to that has been controversial? Summarize the major arguments pro/con.
None
### Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those?
None
## Has a call-for-testing period been conducted? If so, what feedback was received?
Yes; only positive feedback was received.
## Implementation quality
### Summarize the major parts of the implementation and provide links into the code (or to PRs)
Implemented in [#131034](https://github.com/rust-lang/rust/pull/131034).
### Summarize existing test coverage of this feature
- [Basic usage, including `#[cfg()]`, `cfg!()` and `#[cfg_attr()]`](https://github.com/rust-lang/rust/blob/6d71251cf9e40326461f90f8ff9a7024706aea87/tests/ui/cfg/true-false.rs)
- [`--cfg=true/false` on the command line being accessible via `r#true/r#false`](https://github.com/rust-lang/rust/blob/6d71251cf9e40326461f90f8ff9a7024706aea87/tests/ui/cfg/raw-true-false.rs)
- [Interaction with the unstable `#[doc(cfg(..))]` feature](https://github.com/rust-lang/rust/tree/6d71251/tests/rustdoc-ui/cfg-boolean-literal.rs)
- [Denying `--check-cfg=cfg(true/false)`](https://github.com/rust-lang/rust/tree/6d71251/tests/ui/check-cfg/invalid-arguments.rs)
- Ensuring `--cfg false` on the command line doesn't change the meaning of `cfg(false)`: `tests/ui/cfg/cmdline-false.rs`
- Ensuring both `cfg(true)` and `cfg(false)` on the same item result in it being disabled: `tests/ui/cfg/both-true-false.rs`
### What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking?
The above mentioned issue; it should not block as it interacts with another unstable feature.
### What FIXMEs are still in the code for that feature and why is it ok to leave them there?
None
### Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization
- `@clubby789` (RFC)
- `@Urgau` (Implementation in rustc)
### Which tools need to be adjusted to support this feature. Has this work been done?
`rustdoc`'s unstable`#[doc(cfg(..)]` has been updated to respect it. `cargo` has been updated with a forward compatibility lint to enable supporting it in cargo once stabilized.
## Type system and execution rules
### What updates are needed to the reference/specification? (link to PRs when they exist)
A few lines to be added to the reference for configuration predicates, specified in the RFC.
|
|
Type ascription syntax was removed in 2023.
|
|
|
|
|
|
```
error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields
--> $DIR/attempted-access-non-fatal.rs:7:15
|
LL | let _ = 2.l;
| ^
|
help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix
|
LL - let _ = 2.l;
LL + let _ = 2.0f64;
|
```
|
|
span rendering
|
|
|
|
Much like the previous commit.
I think the removal of "the token" in each message is fine here. There
are many more error messages that mention tokens without saying "the
token" than those that do say it.
|
|
|
|
|
|
|
|
Go over all structured parser suggestions and make them verbose style.
When suggesting to add or remove delimiters, turn them into multiple suggestion parts.
|
|
|
|
|
|
|
|
|
|
|
|
Update tests
|
|
|
|
Rewrite exhaustiveness in one pass
This is at least my 4th attempt at this in as many years x) Previous attempts were all too complicated or too slow. But we're finally here!
The previous version of the exhaustiveness algorithm computed reachability for each arm then exhaustiveness of the whole match. Since each of these steps does roughly the same things, this rewrites the algorithm to do them all in one go. I also think this makes things much simpler.
I also rewrote the documentation of the algorithm in depth. Hopefully it's up-to-date and easier to follow now. Plz comment if anything's unclear.
r? `@oli-obk` I think you're one of the rare other people to understand the exhaustiveness algorithm?
cc `@varkor` I know you're not active anymore, but if you feel like having a look you might enjoy this :D
Fixes https://github.com/rust-lang/rust/issues/79307
|
|
Co-authored-by: Adrian <adrian.iosdev@gmail.com>
|
|
|
|
|
|
When parsing a closure without a body that is surrounded by a block,
suggest moving the opening brace after the closure head.
Fix #116608.
|
|
It will be iterated over, so we should avoid using `HashMap`.
|
|
|
|
|
|
|
|
|
|
My type ascription
Oh rip it out
Ah
If you think we live too much then
You can sacrifice diagnostics
Don't mix your garbage
Into my syntax
So many weird hacks keep diagnostics alive
Yet I don't even step outside
So many bad diagnostics keep tyasc alive
Yet tyasc doesn't even bother to survive!
|
|
|
|
|
|
The previous output was unintuitive to users.
|
|
|
|
|
