| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Automatically taint InferCtxt when errors are emitted
r? `@nnethercote`
Basically `InferCtxt::dcx` now returns a `DiagCtxt` that refers back to the `Cell<Option<ErrorGuaranteed>>` of the `InferCtxt` and thus when invoking `Diag::emit`, and the diagnostic is an error, we taint the `InferCtxt` directly.
That change on its own has no effect at all, because `InferCtxt` already tracks whether errors have been emitted by recording the global error count when it gets opened, and checking at the end whether the count changed. So I removed that error count check, which had a bit of fallout that I immediately fixed by invoking `InferCtxt::dcx` instead of `TyCtxt::dcx` in a bunch of places.
The remaining new errors are because an error was reported in another query, and never bubbled up. I think they are minor enough for this to be ok, and sometimes it actually improves diagnostics, by not silencing useful diagnostics anymore.
fixes #126485 (cc `@olafes)`
There are more improvements we can do (like tainting in hir ty lowering), but I would rather do that in follow up PRs, because it requires some refactorings.
|
|
|
|
Implement new effects desugaring
cc `@rust-lang/project-const-traits.` Will write down notes once I have finished.
* [x] See if we want `T: Tr` to desugar into `T: Tr, T::Effects: Compat<true>`
* [x] Fix ICEs on `type Assoc: ~const Tr` and `type Assoc<T: ~const Tr>`
* [ ] add types and traits to minicore test
* [ ] update rustc-dev-guide
Fixes #119717
Fixes #123664
Fixes #124857
Fixes #126148
|
|
|
|
|
|
|
|
|
|
TyCtxt
|
|
Allow constraining opaque types during various unsizing casts
allows unsizing of tuples, arrays and Adts to constraint opaque types in their generic parameters to concrete types on either side of the unsizing cast.
Also allows constraining opaque types during trait object casts that only differ in auto traits or lifetimes.
cc #116652
|
|
Add `SliceLike` to `rustc_type_ir`, use it in the generic solver code (+ some other changes)
First, we split out `TraitRef::new_from_args` which takes *just* `ty::GenericArgsRef` from `TraitRef::new` which takes `impl IntoIterator<Item: Into<GenericArg>>`. I will explain in a minute why.
Second, we introduce `SliceLike`, which allows us to be generic over `List<T>` and `[T]`. This trait has an `as_slice()` and `into_iter()` method, and some other convenience functions. However, importantly, since types like `I::GenericArgs` now implement `SliceLike` rather than `IntoIter<Item = I::GenericArg>`, we can't use `TraitRef::new` on this directly. That's where `new_from_args` comes in.
Finally, we adjust all the code to use these slice operators. Some things get simpler, some things get a bit more annoying since we need to use `as_slice()` in a few places. 🤷
r? lcnr
|
|
AliasTy/AliasTerm/TraitRef/projection
|
|
|
|
|
|
Clean up some comments near `use` declarations
#125443 will reformat all `use` declarations in the repository. There are a few edge cases involving comments on `use` declarations that require care. This PR cleans up some clumsy comment cases, taking us a step closer to #125443 being able to merge.
r? ``@lqd``
|
|
Actually taint InferCtxt when a fulfillment error is emitted
And avoid checking the global error counter
fixes #122044
fixes #123255
fixes #123276
fixes #125799
|
|
Most modules have such a blank line, but some don't. Inserting the blank
line makes it clearer that the `//!` comments are describing the entire
module, rather than the `use` declaration(s) that immediately follows.
|
|
of the bound that binds the parameter's type
|
|
|
|
|
|
|
|
Uplift next trait solver to `rustc_next_trait_solver`
🎉
There's so many FIXMEs! Sorry! Ideally this merges with the FIXMEs and we track and squash them over the near future.
Also, this still doesn't build on anything other than rustc. I still need to fix `feature = "nightly"` in `rustc_type_ir`, and remove and fix all the nightly feature usage in the new trait solver (notably: let-chains).
Also, sorry `@lcnr` I know you asked for me to separate the commit where we `mv rustc_trait_selection/solve/... rustc_next_trait_solver/solve/...`, but I had already done all the work by that point. Luckily, `git` understands the file moves so it should still be relatively reviewable.
If this is still very difficult to review, then I can do some rebasing magic to try to separate this out. Please let me know!
r? lcnr
|
|
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #125112 (Document behavior of `create_dir_all` wrt. empty path)
- #126127 (Spell out other trait diagnostic)
- #126309 (unify git command preperation)
- #126539 (Update `Arc::try_unwrap()` docs)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Spell out other trait diagnostic
I recently saw somebody confused about the diagnostic thinking it was suggesting to add an `as` cast. This change is longer but I think it's clearer
|
|
Only compute vtable information during codegen
This PR removes vtable information from the `Object` and `TraitUpcasting` candidate sources in the trait solvers, and defers the computation of relevant information to `Instance::resolve`. This is because vtables really aren't a thing in the trait world -- they're an implementation detail in codegen.
Previously it was just easiest to tangle this information together since we were already doing the work of looking at all the supertraits in the trait solver, and specifically because we use traits to represent when it's possible to call a method via a vtable (`Object` candidate) and do upcasting (`Unsize` candidate). but I am somewhat suspicious we're doing a *lot* of extra work, especially in polymorphic contexts, so let's see what perf says.
|
|
|
|
Use a consistent way to filter out bounds instead of splitting it into three places
just a small cleanup, no logic change.
Initially the code had me looking for why anything was special here, only to realize there's nothing interesting going on
|
|
|
|
|
|
|
|
places
|
|
|
|
Move `MatchAgainstFreshVars` to old solver
Small change I noticed when trying to uplift the relations to the new trait solver.
|
|
Harmonize using root or leaf obligation in trait error reporting
When #121826 changed the error reporting to use root obligation and not the leafmost obligation, it didn't actually make sure that all the other diagnostics helper functions used the right obligation.
Specifically, when reporting similar impl candidates we are looking for impls of the root obligation, but trying to match them against the trait ref of the leaf obligation.
This does a few other miscellaneous changes. There's a lot more clean-up that could be done here, but working with this code is really grief-inducing due to how messy it has become over the years. Someone really needs to show it love. 😓
r? ``@estebank``
Fixes #126129
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For E0277 suggest adding `Result` return type for function when using QuestionMark `?` in the body.
Adding suggestions for following function in E0277.
```rust
fn main() {
let mut _file = File::create("foo.txt")?;
}
```
to
```rust
fn main() -> Result<(), Box<dyn std::error::Error>> {
let mut _file = File::create("foo.txt")?;
return Ok(());
}
```
According to the issue #125997, only the code examples in the issue are targeted, but the issue covers a wider range of situations.
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
|
|
Make `ObligationEmittingRelation`s emit `Goal` rather than `Obligation`
Helps avoid needing to uplift `Obligation` into the solver. We still can't get rid of `ObligationCause`, but we can keep it as an associated type for `InferCtxtLike` and just give it a `dummy` function.
There's some shuttling between `Goal` and `Obligation` that may be perf-sensitive... Let's see what rust-timer says.
r? lcnr
|
|
QuesionMark `?` in the body.
|
|
Expand list of trait implementers in E0277 when calling rustc with --verbose
Fixes: https://github.com/rust-lang/rust/issues/125984
- Build `rustc` use `./x build`.
- Test result
<img width="634" alt="image" src="https://github.com/rust-lang/rust/assets/15009201/89377059-2316-492b-a38a-fa33adfc9793">
- vim test.rs
```rust
trait Reconcile {
fn reconcile(&self);
}
// Implementing the trait for some types
impl Reconcile for bool {
fn reconcile(&self) {
println!("Reconciling bool");
}
}
impl Reconcile for i8 {
fn reconcile(&self) {
println!("Reconciling i8");
}
}
impl Reconcile for i16 {
fn reconcile(&self) {
println!("Reconciling i16");
}
}
impl Reconcile for i32 {
fn reconcile(&self) {
println!("Reconciling i32");
}
}
impl Reconcile for i64 {
fn reconcile(&self) {
println!("Reconciling i64");
}
}
impl Reconcile for u8 {
fn reconcile(&self) {
println!("Reconciling u8");
}
}
impl Reconcile for u16 {
fn reconcile(&self) {
println!("Reconciling u16");
}
}
impl Reconcile for u32 {
fn reconcile(&self) {
println!("Reconciling u32");
}
}
impl Reconcile for i128 {
fn reconcile(&self) {
println!("Reconciling u32");
}
}
impl Reconcile for u128 {
fn reconcile(&self) {
println!("Reconciling u32");
}
}
fn process<T: Reconcile>(item: T) {
item.reconcile();
}
fn main() {
let value = String::from("This will cause an error");
process(value); // This line will cause a compilation error
}
```
|
|
|
|
Do not define opaque types when selecting impls
fixes #126117
r? `@lcnr` for inconsistency with next solver
|
|
opaque types."
This reverts commit 29a630eb72ffb94c3708947afae1e948ad3cb189.
|
