Normalize opaques with late-bound vars again
We have a hack in the compiler where if an opaque has escaping late-bound vars, we skip revealing it even though we *could* reveal it from a technical perspective. First of all, this is weird, since we really should be revealing all opaques in `Reveal::All` mode. Second of all, it causes subtle bugs (linked below).
I attempted to fix this in #100980, which was unfortunately reverted due to perf regressions on codebases that used really deeply nested futures in some interesting ways. The worst of which was #103423, which caused the project to hang on build. Another one was #104842, which was just a slow-down, but not a hang. I took some time afterwards to investigate how to rework `normalize_erasing_regions` to take advantage of better caching, but that effort kinda fizzled out (#104133).
However, recently, I was made aware of more bugs whose root cause is not revealing opaques during codegen. That made me want to fix this again -- in the process, interestingly, I took the the minimized example from https://github.com/rust-lang/rust/issues/103423#issuecomment-1292947043, and it doesn't seem to hang any more...
Thinking about this harder, there have been some changes to the way we lower and typecheck async futures that may have reduced the pathologically large number of outlives obligations (see description of #103423) that we were encountering when normalizing opaques with bound vars the last time around:
* #104321 (lower `async { .. }` directly as a generator that implements `Future`, removing the `from_generator` shim)
* #104833 (removing an `identity_future` fn that was wrapping desugared future generators)
... so given that I can see:
* No significant regression on rust perf bot (https://github.com/rust-lang/rust/pull/107620#issuecomment-1600070317)
* No timeouts in crater run I did (https://github.com/rust-lang/rust/pull/107620#issuecomment-1605428952, rechecked failing crates in https://github.com/rust-lang/rust/pull/107620#issuecomment-1605973434)
... and given that this PR:
* Fixes#104601
* Fixes#107557
* Fixes#109464
* Allows us to remove a `DefiningAnchor::Bubble` from codegen (75a8f68183)
I'm inclined to give this another shot at landing this. Best case, it just works -- worst case, we get more examples to study how we need to improve the compiler to make this work.
r? types
Rollup of 5 pull requests
Successful merges:
- #112946 (Improve cgu naming and ordering)
- #113048 (Fix build on Solaris where fd-lock cannot be used.)
- #113100 (Fix display of long items in search results)
- #113107 (add check for ConstKind::Value(_) to in_operand())
- #113119 (rustdoc: Reduce internal function visibility.)
r? `@ghost`
`@rustbot` modify labels: rollup
Rollup of 7 pull requests
Successful merges:
- #112670 (privacy: Type privacy lints fixes and cleanups)
- #112929 (Test that we require implementing trait items whose bounds don't hold in the current impl)
- #113054 (Make `rustc_on_unimplemented` std-agnostic)
- #113137 (don't suggest `move` for borrows that aren't closures)
- #113139 (style-guide: Clarify let-else further)
- #113140 (style-guide: Add an example of formatting a multi-line attribute)
- #113143 (style-guide: Narrow guidance about references and dereferencing)
r? `@ghost`
`@rustbot` modify labels: rollup
style-guide: Narrow guidance about references and dereferencing
The style guide advises "prefer dereferencing to taking references", but
doesn't give guidance on when that "preference" should get overridden by
other considerations. Give an example of when it's fine to ignore
that advice.
style-guide: Add an example of formatting a multi-line attribute
We already say to format attributes like functions, but we didn't have
an example of formatting a multi-line attribute.
style-guide: Clarify let-else further
Give some additional examples with multi-line patterns.
Make it clearer to go on to the next case if the conditions aren't met.
Test that we require implementing trait items whose bounds don't hold in the current impl
I initially tried to make most of these pass, but that's a big can of worms, so I'm just adding them as tests, considering we have no tests for these things.
The style guide advises "prefer dereferencing to taking references", but
doesn't give guidance on when that "preference" should get overridden by
other considerations. Give an example of when it's fine to ignore
that advice.
Make associated type bounds in supertrait position implied
`trait A: B<Assoc: C> {}` should be able to imply both `Self: B` and `<Self as B>::Assoc: C`. Adjust the way that we collect implied predicates to do so.
Fixes#112573Fixes#112568
add check for ConstKind::Value(_) to in_operand()
Added check for valtree value to close#113012 which fixes the issue, although I am not sure if adding the check there is sound or not cc `@oli-obk`
Refactor metadata emission to avoid visiting HIR
This PR refactors metadata emission to be based on tables and iteration over definitions.
In a first part, this PR moves information from the `EntryKind` enum to tables, until removing the `EntryKind` enum.
In a second part, the iteration scheme is refactored to avoid fetching HIR unless strictly necessary.
r? `@ghost`
Rollup of 6 pull requests
Successful merges:
- #111571 (Implement proposed API for `proc_macro_span`)
- #112236 (Simplify computation of killed borrows)
- #112867 (More `ImplSource` nits)
- #113019 (add note for non-exhaustive matches with guards)
- #113094 (Fix invalid HTML DIV tag used in HEAD)
- #113111 (add myself to review for t-types stuff)
r? `@ghost`
`@rustbot` modify labels: rollup
Try running a sync automatically
absolutely no clue if this works, but it happens after the zulip message, so worst case we'll see the failure after the cron job did everything it currently does.
add note for non-exhaustive matches with guards
Associated issue: #92197
When a match statement includes guards on every match arm (and is therefore necessarily non-exhaustive), add a note to the error E0004 diagnostic noting this.
