| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Suggest `if let`/`let_else` for refutable pat in `let`
r? `````@oli-obk`````
|
|
Tweak move error
Point at method definition that causes type to be consumed.
Fix #94056.
|
|
|
|
|
|
`span_label`
This makes the order of the output always consistent:
1. Place of the `match` missing arms
2. The `enum` definition span
3. The structured suggestion to add a fallthrough arm
|
|
Given
```rust
match Some(42) {
Some(0) => {}
}
```
suggest
```rust
match Some(42) {
Some(0) => {}
None | Some(_) => todo!(),
}
```
|
|
Given
```rust
match Some(42) {}
```
suggest
```rust
match Some(42) { None | Some(_) => todo!(), }
```
|
|
Point at method definition that causes type to be consumed.
Fix #94056.
|
|
|
|
Clarify error on casting larger integers to char
Closes #91836 with changes to E0604.md and a `span_help`.
|
|
|
|
|
|
|
|
|
|
* Point at RHS of associated type in obligation span
* Point at `impl` assoc type on projection error
* Reduce verbosity of recursive obligations
* Point at source of binding lifetime obligation
* Tweak "required bound" note
* Tweak "expected... found opaque (return) type" labels
* Point at set type in impl assoc type WF errors
|
|
|
|
* Do not emit unnecessary E0308 after E0070
* Show fewer errors on `while let` missing `let`
* Hide redundant E0308 on `while let` missing `let`
* Point at binding definition when possible on invalid assignment
* do not point at closure twice
* do not suggest `if let` for literals in lhs
* account for parameter types
|
|
|
|
|
|
Be more thorough in using `ItemObligation` and `BindingObligation` when
evaluating obligations so that we can point at trait bounds that
introduced unfulfilled obligations. We no longer incorrectly point at
unrelated trait bounds (`substs-ppaux.verbose.stderr`).
In particular, we now point at trait bounds on method calls.
We no longer point at "obvious" obligation sources (we no longer have a
note pointing at `Trait` saying "required by a bound in `Trait`", like
in `associated-types-no-suitable-supertrait*`).
Address part of #89418.
|
|
ken-matsui:clarify-error-messages-caused-by-reexporting-pub-crate-visibility-to-outside, r=oli-obk
Clarify error messages caused by re-exporting `pub(crate)` visibility to outside
This PR clarifies error messages and suggestions caused by re-exporting pub(crate) visibility outside the crate.
Here is a small example ([Rust Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=e2cd0bd4422d4f20e6522dcbad167d3b)):
```rust
mod m {
pub(crate) enum E {}
}
pub use m::E;
fn main() {}
```
This code is compiled to:
```
error[E0365]: `E` is private, and cannot be re-exported
--> prog.rs:4:9
|
4 | pub use m::E;
| ^^^^ re-export of private `E`
|
= note: consider declaring type or module `E` with `pub`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0365`.
```
However, enum `E` is actually public to the crate, not private totally—nevertheless, rustc treats `pub(crate)` and private visibility as the same on the error messages. They are not clear and should be segmented distinctly.
By applying changes in this PR, the error message below will be the following message that would be clearer:
```
error[E0365]: `E` is only public to inside of the crate, and cannot be re-exported outside
--> prog.rs:4:9
|
4 | pub use m::E;
| ^^^^ re-export of crate public `E`
|
= note: consider declaring type or module `E` with `pub`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0365`.
```
|
|
|
|
Suggest removal of arguments for unit variant, not replacement
|
|
|
|
Stabilize `const_raw_ptr_deref` for `*const T`
This stabilizes dereferencing immutable raw pointers in const contexts.
It does not stabilize `*mut T` dereferencing. This is behind the
same feature gate as mutable references.
closes https://github.com/rust-lang/rust/issues/51911
|
|
|
|
|
|
This stabilizes dereferencing immutable raw pointers in const contexts.
It does not stabilize `*mut T` dereferencing. This is placed behind the
`const_raw_mut_ptr_deref` feature gate.
|
|
Emit description of the ambiguity as a note.
Co-authored-by: Noah Lev <camelidcamel@gmail.com>
Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
|
|
|
|
Update E0637 description to mention `&` w/o an explicit lifetime name
Deal with https://github.com/rust-lang/rust/issues/89824#issuecomment-941598647. Another solution would be splitting the error code into two as (I think) it's a bit unclear to users why they have the same error code.
|
|
Some "parenthesis" and "parentheses" fixes
"Parenthesis" is the singular (e.g. one `(` or one `)`) and "parentheses" is the plural (multiple `(` or `)`s) and this is not hard to mix up so here are some fixes for that.
Inspired by #89958
|
|
|
|
|
|
|
|
Remove textual span from diagnostic string
This is an unnecessary repetition, as the diagnostic prints the span anyway in the source path right below the message.
I further removed the identification of the node, as that does not give any new information in any of the cases that are changed in tests.
EDIT: also inserted a suggestion that other diagnostics were already emitting
|
|
|
|
|
|
The test is copied from `src/test/ui/crate-loading/crateresolve1.rs` and
its auxiliary tests. I added it to the `compile_fail` code example check
exemption list since it's hard if not impossible to reproduce this error
in a standalone code example.
|
|
same
|
|
Fix suggestion to borrow when casting from pointer to reference
Fixes #89497.
|
|
Practice diagnostic message convention
Detected by #89455.
r? ```@estebank```
|
|
|
|
|
|
A subset of places referred to 'super-trait', so this changes them
to all use 'supertrait'. This matches 'supertype' and some other
usages. An exception is 'auto-trait' which is consistently used
in that manner.
|
|
r=estebank
Suggest similarly named associated items in trait impls
Fix #85942
Previously, the compiler didn't suggest similarly named associated items unlike we do in many situations. This patch adds such diagnostics for associated functions, types, and constants.
|
|
Rollup of 13 pull requests
Successful merges:
- #87428 (Fix union keyword highlighting in rustdoc HTML sources)
- #88412 (Remove ignore-tidy-undocumented-unsafe from core::slice::sort)
- #89098 (Fix generics where bounds order)
- #89232 (Improve help for recursion limit errors)
- #89294 (:arrow_up: rust-analyzer)
- #89297 (Remove Never variant from clean::Type enum)
- #89311 (Add unit assignment to MIR for `asm!()`)
- #89313 (PassWrapper: handle function rename from upstream D36850)
- #89315 (Clarify that `CString::from_vec_unchecked` appends 0 byte.)
- #89335 (Optimize is_sorted for Range and RangeInclusive)
- #89366 (rustdoc: Remove lazy_static dependency)
- #89377 (Update cargo)
- #89378 (Update books)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Improve help for recursion limit errors
- Tweak help message and suggested limit (handle `0` case).
- Add test for #75602 (it was already fixed, maybe can be resolved too).
Fixes #76424
|
|
Use larger span for adjustment THIR expressions
Currently, we use a relatively 'small' span for THIR
expressions generated by an 'adjustment' (e.g. an autoderef,
autoborrow, unsizing). As a result, if a borrow generated
by an adustment ends up causing a borrowcheck error, for example:
```rust
let mut my_var = String::new();
let my_ref = &my_var
my_var.push('a');
my_ref;
```
then the span for the mutable borrow may end up referring
to only the base expression (e.g. `my_var`), rather than
the method call which triggered the mutable borrow
(e.g. `my_var.push('a')`)
Due to a quirk of the MIR borrowck implementation,
this doesn't always get exposed in migration mode,
but it does in many cases.
This commit makes THIR building consistently use 'larger'
spans for adjustment expressions. These spans are recoded
when we first create the adjustment during typecheck. For
example, an autoref adjustment triggered by a method call
will record the span of the entire method call.
The intent of this change it make it clearer to users
when it's the specific way in which a variable is
used (for example, in a method call) that produdes
a borrowcheck error. For example, an error message
claiming that a 'mutable borrow occurs here' might
be confusing if it just points at a usage of a variable
(e.g. `my_var`), when no `&mut` is in sight. Pointing
at the entire expression should help to emphasize
that the method call itself is responsible for
the mutable borrow.
In several cases, this makes the `#![feature(nll)]` diagnostic
output match up exactly with the default (migration mode) output.
As a result, several `.nll.stderr` files end up getting removed
entirely.
|
