-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
remove proof tree formatting, make em shallow #125510
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lcnr
changed the title
remove proof tree formatter, make em shallow
remove proof tree formatting, make em shallow
May 24, 2024
rustbot
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
WG-trait-system-refactor
The Rustc Trait System Refactor Initiative (-Znext-solver)
labels
May 24, 2024
Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor |
This comment has been minimized.
This comment has been minimized.
rust-cloud-vms
bot
force-pushed
the
change-proof-trees-to-be-shallow
branch
from
May 24, 2024 18:41
36ea5f5
to
ebd9f35
Compare
compiler-errors
approved these changes
May 25, 2024
@bors r+ rollup (new solver only) |
bors
added
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
May 25, 2024
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this pull request
May 25, 2024
…low, r=compiler-errors remove proof tree formatting, make em shallow Debugging via tracing `RUSTC_LOG=rustc_trait_selection::solve=debug` is now imo slightly more readable then the actual proof tree formatter. Removing everything that's not needed for the `analyse` visitor allows us to remove a bunch of code. I personally believe that we should continue to use tracing over proof trees for debugging: - it eagerly prints, allowing us to debug ICEs - the proof tree builder ends up going out of sync with the actual runtime behavior, which is confusing - using shallow proof trees is a lot more performant as we frequently do not recurse into all nested goals when using an analyse visitor - this allows us to clean up the implementation and remove some code r? `@compiler-errors`
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 25, 2024
…kingjubilee Rollup of 9 pull requests Successful merges: - rust-lang#124080 (Some unstable changes to where opaque types get defined) - rust-lang#125271 (use posix_memalign on almost all Unix targets) - rust-lang#125433 (A small diagnostic improvement for dropping_copy_types) - rust-lang#125498 (Stop using the avx512er and avx512pf x86 target features) - rust-lang#125510 (remove proof tree formatting, make em shallow) - rust-lang#125513 (Don't eagerly monomorphize drop for types that are impossible to instantiate) - rust-lang#125514 (Structurally resolve before `builtin_index` in EUV) - rust-lang#125515 ( bootstrap: support target specific config overrides ) - rust-lang#125527 (Add manual Sync impl for ReentrantLockGuard) r? `@ghost` `@rustbot` modify labels: rollup
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this pull request
May 25, 2024
…low, r=compiler-errors remove proof tree formatting, make em shallow Debugging via tracing `RUSTC_LOG=rustc_trait_selection::solve=debug` is now imo slightly more readable then the actual proof tree formatter. Removing everything that's not needed for the `analyse` visitor allows us to remove a bunch of code. I personally believe that we should continue to use tracing over proof trees for debugging: - it eagerly prints, allowing us to debug ICEs - the proof tree builder ends up going out of sync with the actual runtime behavior, which is confusing - using shallow proof trees is a lot more performant as we frequently do not recurse into all nested goals when using an analyse visitor - this allows us to clean up the implementation and remove some code r? ``@compiler-errors``
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 25, 2024
…kingjubilee Rollup of 7 pull requests Successful merges: - rust-lang#125271 (use posix_memalign on almost all Unix targets) - rust-lang#125433 (A small diagnostic improvement for dropping_copy_types) - rust-lang#125498 (Stop using the avx512er and avx512pf x86 target features) - rust-lang#125510 (remove proof tree formatting, make em shallow) - rust-lang#125513 (Don't eagerly monomorphize drop for types that are impossible to instantiate) - rust-lang#125514 (Structurally resolve before `builtin_index` in EUV) - rust-lang#125527 (Add manual Sync impl for ReentrantLockGuard) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 25, 2024
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#125271 (use posix_memalign on almost all Unix targets) - rust-lang#125451 (Fail relating constants of different types) - rust-lang#125478 (Bump bootstrap compiler to the latest beta compiler) - rust-lang#125498 (Stop using the avx512er and avx512pf x86 target features) - rust-lang#125510 (remove proof tree formatting, make em shallow) - rust-lang#125513 (Don't eagerly monomorphize drop for types that are impossible to instantiate) - rust-lang#125514 (Structurally resolve before `builtin_index` in EUV) - rust-lang#125527 (Add manual Sync impl for ReentrantLockGuard) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 25, 2024
Rollup merge of rust-lang#125510 - lcnr:change-proof-trees-to-be-shallow, r=compiler-errors remove proof tree formatting, make em shallow Debugging via tracing `RUSTC_LOG=rustc_trait_selection::solve=debug` is now imo slightly more readable then the actual proof tree formatter. Removing everything that's not needed for the `analyse` visitor allows us to remove a bunch of code. I personally believe that we should continue to use tracing over proof trees for debugging: - it eagerly prints, allowing us to debug ICEs - the proof tree builder ends up going out of sync with the actual runtime behavior, which is confusing - using shallow proof trees is a lot more performant as we frequently do not recurse into all nested goals when using an analyse visitor - this allows us to clean up the implementation and remove some code r? ```@compiler-errors```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
WG-trait-system-refactor
The Rustc Trait System Refactor Initiative (-Znext-solver)
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Debugging via tracing
RUSTC_LOG=rustc_trait_selection::solve=debug
is now imo slightly more readable then the actual proof tree formatter. Removing everything that's not needed for theanalyse
visitor allows us to remove a bunch of code.I personally believe that we should continue to use tracing over proof trees for debugging:
r? @compiler-errors