| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
Rollup of 11 pull requests
Successful merges:
- #104592 (Ensure async trait impls are async (or otherwise return an opaque type))
- #105623 (Fix `-Z print-type-sizes` for generators with discriminant field ordered first)
- #105627 (Auto traits in `dyn Trait + Auto` are suggestable)
- #105633 (Make `report_projection_error` more `Term` agnostic)
- #105683 (Various cleanups to dest prop)
- #105692 (Add regression test for #104678)
- #105707 (rustdoc: remove unnecessary CSS `kbd { cursor: default }`)
- #105715 (Do not mention long types in E0599 label)
- #105722 (more clippy::complexity fixes)
- #105724 (rustdoc: remove no-op CSS `.scrape-example .src-line-numbers { margin: 0 }`)
- #105730 (rustdoc: remove no-op CSS `.item-info:before { color }`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Do not mention long types in E0599 label
The type is already mentioned in the main message and the list of unmet bounds.
|
|
Add regression test for #104678
Closes #104678
r? `````@compiler-errors`````
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
Make `report_projection_error` more `Term` agnostic
Fixes #105632
|
|
Auto traits in `dyn Trait + Auto` are suggestable
Not sure why I had made the `IsSuggestableVisitor` have that rule to not consider `dyn Trait + Auto` to be suggestable.
It's possible that this was done because of the fact that we don't print the right parentheses for `&(dyn Trait + Auto)`, but that's a problem with printing these types in general that we probably have tracked somewhere else...
|
|
Fix `-Z print-type-sizes` for generators with discriminant field ordered first
Fixes #105589
Fixes #105591
|
|
Ensure async trait impls are async (or otherwise return an opaque type)
As a workaround for the full `#[refine]` semantics not being implemented
yet, forbit returning a concrete future type like `Box<dyn Future>` or a
manually implemented Future.
`-> impl Future` is still permitted; while that can also cause
accidental refinement, that's behind a different feature gate
(`return_position_impl_trait_in_trait`) and that problem exists
regardless of whether the trait method is async, so will have to be
solved more generally.
Fixes https://github.com/rust-lang/rust/issues/102745
|
|
|
|
Highlight conflicting param-env candidates, again
Un-reverts #98794 (i.e. reverts #99290).
The previous time I attempted to land this PR, it was because of an incremental issue (#99233). The repro instructions in the issue is no longer manifest the ICE -- I think it's because this ambiguity code was refactored (I think by `@lcnr)` to no longer store the ambiguities in the fulfillment error, but instead recompute them on the fly.
The main motivation for trying to re-land this is that it fixes #105131 by highlighting the root-cause of the issue, which is conflicting param-env candidates:
```
error[E0283]: type annotations needed: cannot satisfy `Self: Gen<'source>`
|
note: multiple `impl`s or `where` clauses satisfying `Self: Gen<'source>` found
--> $DIR/conflicting-bounds.rs:3:1
|
LL | pub trait Gen<'source> {
| ^^^^^^^^^^^^^^^^^^^^^^
...
LL | Self: for<'s> Gen<'s, Output = T>;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0283`.
```
Fixes #105131.
Fixes (again) #98786
|
|
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
Fix #35825.
|
|
Find the right lower bound region in the scenario of partial order relations
Fixes #104639
|
|
As a workaround for the full `#[refine]` semantics not being implemented
yet, forbit returning a concrete future type like `Box<dyn Future>` or a
manually implemented Future.
`-> impl Future` is still permitted; while that can also cause
accidental refinement, that's behind a different feature gate
(`return_position_impl_trait_in_trait`) and that problem exists
regardless of whether the trait method is async, so will have to be
solved more generally.
Fixes #102745
|
|
The type is already mentioned in the main message and the list of unmet
bounds.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add a test for #92481
The test was copied ad-hoc from #92481, but I can't get the test to pass, because of needing to get twice the same error on the last line of the source.
Closes #92481
|
|
.. and ..= are valid expressions, however when used in a let statement
it is not parsed.
|
|
|
|
|
|
|
|
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
r=wesleywiser
fold instead of obliterating args
Fixes #105608
we call `const_eval_resolve` on the following constant:
```
def: playground::{impl#0}::and::{constant#0},
substs: [
ConstKind::Unevaluated {
def: playground::{impl#0}::and::{constant#0},
substs: [
ConstKind::Value(0x0),
_,
]
}
_,
],
```
when expanded out to `ConstKind::Expr` there are no infer vars so we attempt to evaluate it after replacing infer vars with garbage, however the current logic for replacing with garbage replaces _the whole arg containing the infer var_ rather than just the infer var. This means that after garbage replacement has occured we attempt to evaluate:
```
def: playground::{impl#0}::and::{constant#0},
substs: [
PLACEHOLDER,
PLACEHOLDER,
],
```
Which then leads to ctfe being unable to evaluate the const. With this PR we attempt to evaluate:
```
def: playground::{impl#0}::and::{constant#0},
substs: [
ConstKind::Unevaluated {
def: playground::{impl#0}::and::{constant#0},
substs: [
ConstKind::Value(0x0),
PLACEHOLDER,
]
}
PLACEHOLDER,
],
```
which ctfe _can_ handle.
I am not entirely sure why this function is supposed to replace params with placeholders rather than just inference vars :thinking:
|
|
r=compiler-errors
Suggest dereferencing receiver arguments properly
Fixes #105429
|
|
Suggest `collect`ing into `Vec<_>`
Fix #105510.
|
|
Suggest impl in the scenario of typo with fn
Fixes #105366
|
|
Illegal sized bounds: only suggest mutability change if needed
In a scenario like
```rust
struct Type;
pub trait Trait {
fn function(&mut self)
where
Self: Sized;
}
impl Trait for Type {
fn function(&mut self) {}
}
fn main() {
(&mut Type as &mut dyn Trait).function();
}
```
the problem is Sized, not the mutability of self. Thus don't emit the "you need &T instead of &mut T" note, or the other way around, as all it does is just invert the mutability of whatever was supplied.
Fixes #103622.
|
|
Refine when invalid prefix case error arises
Fix cases where the "invalid base prefix for number literal" error arises with suffixes that look erroneously capitalized but which are actually invalid.
|
|
|
|
Properly handle postfix inc/dec in standalone and subexpr scenarios
Fixes #104867
r? `@estebank`
|
|
detect the pattern at the general site parse_impl_ty()
this will fix #102598
|
|
Rollup of 7 pull requests
Successful merges:
- #105147 (Allow unsafe through inline const)
- #105438 (Move some codegen-y methods from `rustc_hir_analysis::collect` -> `rustc_codegen_ssa`)
- #105464 (Support #[track_caller] on async closures)
- #105476 (Change pattern borrowing suggestions to be verbose and remove invalid suggestion)
- #105500 (Make some diagnostics not depend on the source of what they reference being available)
- #105628 (Small doc fixes)
- #105659 (Don't require owned data in `MaybeStorageLive`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Make some diagnostics not depend on the source of what they reference being available
r? `@estebank`
follow up to https://github.com/rust-lang/rust/pull/104449
|
|
Change pattern borrowing suggestions to be verbose and remove invalid suggestion
Synthesize a more accurate span and use verbose suggestion output to
make the message clearer.
Do not suggest borrowing binding in pattern in let else. Fix #104838.
|
|
Support #[track_caller] on async closures
Follow up on #105180
r? ```@compiler-errors```
cc ```@cjgillot```
|
|
Allow unsafe through inline const
Handle similar to closures.
Address https://github.com/rust-lang/rust/pull/104087#issuecomment-1324173328
Note that this PR does not fix the issue for `unsafe { [0; function_requiring_unsafe()] }`. This is fundamentally unfixable for MIR unsafeck IMO.
This PR also does not fix unsafety checking for inline const in pattern position. It actually breaks it, allowing unsafe functions to be used in inline const in pattern position without unsafe blocks. Inline const in pattern position is not visible in MIR so ignored by MIR unsafety checking (currently it is also not checked by borrow checker, which is the reason why it's considered an incomplete feature).
`@rustbot` label: +T-lang +F-inline_const
|
|
fix a stderr
|
|
|