| Age | Commit message (Collapse) | Author | Lines |
|---|
|
hidden types for opaque types
|
|
r=Dylan-DPC
Avoid some `&str` to `String` conversions with `MultiSpan::push_span_label`
This patch removes some`&str` to `String` conversions with `MultiSpan::push_span_label`.
|
|
Erase regions in New Abstract Consts
When an abstract const is constructed, we previously included lifetimes in the set of substitutes, so it was not able to unify two abstract consts if their lifetimes did not match but the values did, despite the values not depending on the lifetimes. This caused code that should have compiled to not compile.
Fixes #98452
r? ```@lcnr```
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #97423 (Simplify memory ordering intrinsics)
- #97542 (Use typed indices in argument mismatch algorithm)
- #97786 (Account for `-Z simulate-remapped-rust-src-base` when resolving remapped paths)
- #98277 (Fix trait object reborrow suggestion)
- #98525 (Add regression test for #79224)
- #98549 (interpret: do not prune requires_caller_location stack frames quite so early)
- #98603 (Some borrowck diagnostic fixes)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Make empty bounds lower to `WellFormed` and make `WellFormed` coinductive
r? rust-lang/types
|
|
Currently, `search_for_structural_match_violation` constructs an `infcx`
from a `tcx` and then only uses the `tcx` within the `infcx`. This is
wasteful because `infcx` is a big type.
This commit changes it to use the `tcx` directly. When compiling
`pest-2.1.3`, this changes the memcpy stats reported by DHAT for a `check full`
build from this:
```
433,008,916 bytes (100%, 99,787.93/Minstr) in 2,148,668 blocks (100%, 495.17/Minstr), avg size 201.52 bytes
```
to this:
```
101,422,347 bytes (99.98%, 25,243.59/Minstr) in 1,318,407 blocks (99.96%, 328.15/Minstr), avg size 76.93 bytes
```
This translates to a 4.3% reduction in instruction counts.
|
|
Because the `infcx` isn't needed. This removes one lifetime from
`Search`.
|
|
|
|
|
|
Remove a back-compat hack on lazy TAIT
This PR's motivation is here: https://github.com/rust-lang/rust/issues/72614#issuecomment-1134595446
~~But removing a hack doesn't seem to reject the code on the issue, there're some more hacks?~~
r? ``@oli-obk``
|
|
|
|
|
|
small regions refactoring
these commits should be fairly self-contained
r? rust-lang/types
|
|
Fix span issues in object safety suggestions
Fixes #98500
|
|
see comment added to the field in `VerifyBoundCx`.
|
|
|
|
Perform coherence checking per impl.
r? `@ghost`
|
|
|
|
Reverse folder hierarchy
#91318 introduced a trait for infallible folders distinct from the fallible version. For some reason (completely unfathomable to me now that I look at it with fresh eyes), the infallible trait was a supertrait of the fallible one: that is, all fallible folders were required to also be infallible. Moreover the `Error` associated type was defined on the infallible trait! It's so absurd that it has me questioning whether I was entirely sane.
This trait reverses the hierarchy, so that the fallible trait is a supertrait of the infallible one: all infallible folders are required to also be fallible (which is a trivial blanket implementation). This of course makes much more sense! It also enables the `Error` associated type to sit on the fallible trait, where it sensibly belongs.
There is one downside however: folders expose a `tcx` accessor method. Since the blanket fallible implementation for infallible folders only has access to a generic `F: TypeFolder`, we need that trait to expose such an accessor to which we can delegate. Alternatively it's possible to extract that accessor into a separate `HasTcx` trait (or similar) that would then be a supertrait of both the fallible and infallible folder traits: this would ensure that there's only one unambiguous `tcx` method, at the cost of a little additional boilerplate. If desired, I can submit that as a separate PR.
r? ````@jackh726````
|
|
r=eholk
Address review comments from #98259
It got approved so fast I didn't have time to make changes xD
r? ``@eholk``
|
|
Greatly improve error reporting for futures and generators in `note_obligation_cause_code`
Most futures don't go through this code path, because they're caught by
`maybe_note_obligation_cause_for_async_await`. But all generators do,
and `maybe_note` is imperfect and doesn't catch all futures. Improve the error message for those it misses.
At some point, we may want to consider unifying this with the code for `maybe_note_async_await`,
so that `async_await` notes all parent constraints, and `note_obligation` can point to yield points.
But both functions are quite complicated, and it's not clear to me how to combine them;
this seems like a good incremental improvement.
Helps with https://github.com/rust-lang/rust/issues/97332.
r? ``@estebank`` cc ``@eholk`` ``@compiler-errors``
|
|
|
|
|
|
It got merged so fast I didn't have time to make changes xD
|
|
#91318 introduced a trait for infallible folders distinct from the fallible version. For some reason (completely unfathomable to me now that I look at it with fresh eyes), the infallible trait was a supertrait of the fallible one: that is, all fallible folders were required to also be infallible. Moreover the `Error` associated type was defined on the infallible trait! It's so absurd that it has me questioning whether I was entirely sane.
This trait reverses the hierarchy, so that the fallible trait is a supertrait of the infallible one: all infallible folders are required to also be fallible (which is a trivial blanket implementation). This of course makes much more sense! It also enables the `Error` associated type to sit on the fallible trait, where it sensibly belongs.
There is one downside however: folders expose a `tcx` accessor method. Since the blanket fallible implementation for infallible folders only has access to a generic `F: TypeFolder`, we need that trait to expose such an accessor to which we can delegate. Alternatively it's possible to extract that accessor into a separate `HasTcx` trait (or similar) that would then be a supertrait of both the fallible and infallible folder traits: this would ensure that there's only one unambiguous `tcx` method, at the cost of a little additional boilerplate. If desired, I can submit that as a separate PR.
r? @jackh726
|
|
Add proper tracing spans to rustc_trait_selection::traits::error_reporting
While I was trying to figure out #97704 I did some of this to make the logs more legible, so I figured I'd do the whole module and open a PR with it. afaict this is an ongoing process in the compiler from the log->tracing transition? but lmk if there was a reason for the more verbose forms of logging as they are.
Also, for some of the functions with only one log in them, I put the function name as a message for that log instead of `#[instrument]`-ing the whole function with a span? but maybe the latter would actually be preferable, I'm not actually sure.
|
|
Obligation forest tweaks
A few minor improvements to the code.
r? `@nikomatsakis`
|
|
Incorrect pluralisation of `crate`
|
|
`note_obligation_cause_code`
Most futures don't go through this code path, because they're caught by
`maybe_note_obligation_cause_for_async_await`. But all generators do,
and `maybe_note` is imperfect and doesn't catch all futures. Improve the error message for those it misses.
At some point, we may want to consider unifying this with the code for `maybe_note_async_await`,
so that `async_await` notes all parent constraints, and `note_obligation` can point to yield points.
But both functions are quite complicated, and it's not clear to me how to combine them;
this seems like a good incremental improvement.
|
|
Rename `impl_constness` to `constness`
The current code is a basis for `is_const_fn_raw`, and `impl_constness`
is no longer a valid name, which is previously used for determining the
constness of impls, and not items in general.
r? `@oli-obk`
|
|
The current code is a basis for `is_const_fn_raw`, and `impl_constness`
is no longer a valid name, which is previously used for determining the
constness of impls, and not items in general.
|
|
Make `ExprKind::Closure` a struct variant.
Simple refactor since we both need it to introduce additional fields in `ExprKind::Closure`.
r? ``@Aaron1011``
|
|
|
|
|
|
Rename the `ConstS::val` field as `kind`.
And likewise for the `Const::val` method.
Because its type is called `ConstKind`. Also `val` is a confusing name
because `ConstKind` is an enum with seven variants, one of which is
called `Value`. Also, this gives consistency with `TyS` and `PredicateS`
which have `kind` fields.
The commit also renames a few `Const` variables from `val` to `c`, to
avoid confusion with the `ConstKind::Value` variant.
r? `@BoxyUwU`
|
|
Remove RegionckMode in favor of calling new skip_region_resolution
Simple cleanup. We can skip a bunch of stuff for places where NLL does the region checking, so skip earlier.
r? rust-lang/types
|
|
And likewise for the `Const::val` method.
Because its type is called `ConstKind`. Also `val` is a confusing name
because `ConstKind` is an enum with seven variants, one of which is
called `Value`. Also, this gives consistency with `TyS` and `PredicateS`
which have `kind` fields.
The commit also renames a few `Const` variables from `val` to `c`, to
avoid confusion with the `ConstKind::Value` variant.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #97595 (Remove unwrap from get_vtable)
- #97597 (Preserve unused pointer to address casts)
- #97819 (Recover `import` instead of `use` in item)
- #97823 (Recover missing comma after match arm)
- #97851 (Use repr(C) when depending on struct layout in ptr tests)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Remove unwrap from get_vtable
This avoids ICE on issue #97381 I think the bug is a bit deeper though, it compiles fine when `v` is `&v` which makes me think `Deref` is causing some issue with borrowck but it's fine I guess since this thing crashes since `nightly-2020-09-17` 😅
|
|
Folding revamp
r? `@ghost`
|
