Revert two unapproved changes to rustc_typeck. #59789
Conversation
rust-highfive
added
the
S-waiting-on-review
We could setup bors to require a github approval from a relevant team member on certain source paths. |
Sigh, resolve has a bunch of rustdoc-specific (and diagnostics-specific) hacks that don't work entirely correctly, but at least they don't affect the normal compiler run. |
All of them have been approved except for the two last ones (and on the last one I did ping the compiler team!). If not happy with the PR, you can comment on it. By merging this PR, you'll reintroduce bugs in rustdoc. I'm against this changes. The process hasn't been followed, I'm sorry about that, but instead, wouldn't it be better to fix the librustc_typeck bad changes I made directly? As far as I can tell, it doesn't break anything in the rustc internals whereas reverting will break rustdoc again. |
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
I opened #59790 for further discussion. This PR should of course not break rustdoc, but address the original issues in a manner not affecting regular compilation. |
There should be an explicit review and approval, i.e. default to not merge non-rustc changes to rustc crates, instead of defaulting to merge in the absence of requested changes.
As I've explained in #59790 (comment), this is undocumented cruft, and as such it will cause confusion or even stop some refactors, if nobody checks the change history and just assumes the code is needed. And I obviously can't break @petrochenkov FWIW, I think rustdoc as a whole needs some refactors, and @rust-lang/rustdoc has to make due with the codebase they've inherited. I've offered a few times but ended up with not enough spare time to do said refactors (although maybe I should try again, e.g. the comments I left on #58894). Overall I'd rather stick the blame on the grandfathered codebase, and process breakdown, than individuals. |
|
If #59004 and #58894 were the PRs that introduced the problematic changes, we can revert them wholesale. They were an enhancement and cosmetic fix, respectively, and reverting them should not introduce any show-stopping bugs to rustdoc. It wouldn't hurt to get more eyes on rustdoc PRs more generally; i know i've been struggling to stay on top of my review queue, and having more hands would help keep everything going smoothly. |
|
@QuietMisdreavus no need, for #59004 I already have an equivalent replacement (since the data is already in |
|
@QuietMisdreavus Considering that #59004 is a big search improvement, it'd be quite the regression to revert. Luckily for me, it's not needed. 😌 |
|
@bors try (let's see if I made anything significantly slower) |
Revert two unapproved changes to rustc_typeck. There was a breakdown in process (#59004 (comment), #58894 (comment)) and two changes were made to `rustc_typeck`'s "collect" queries, for rustdoc, that were neither needed *nor* correct. I'm reverting them here, and will fix up rustdoc *somehow*, if necessary. cc @rust-lang/compiler How do we ensure this doesn't happen again? r? @nikomatsakis or @oli-obk
|
☀️ Try build successful - checks-travis |
|
@rust-timer build b2e5868 |
|
Success: Queued b2e5868 with parent 3750348, comparison URL. |
|
Finished benchmarking try commit b2e5868 |
|
cc @nikomatsakis @michaelwoerister @nnethercote How bad are the perf results? I could try to supply |
|
The worst-affected benchmarks are the short-running, less important ones. But it's still clearly a regression :( |
|
Here is a Cachegrind diff for a "Check CleanIncr" build of |
|
@bors try |
|
⌛ Trying commit 6cd0befb14ca0bdb991e34658a27bfd893b76ff0 with merge 731027337fee4c5fc708578f8be3f99e275dac67... |
|
@nnethercote Now the encoding/decoding should be the same as before in most cases. |
|
Finished benchmarking try commit 0ba7f2605ec9d9c443d7d70bc109b69a79c0f79d, comparison URL. |
|
Ping from triage? |
|
@bors r+ |
|
📌 Commit d594fc2 has been approved by |
bors
added
S-waiting-on-bors
|
⌛ Testing commit d594fc2 with merge 428fc5295fdf13884968104e1e2d9bf9e74f9020... |
|
Your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
💔 Test failed - checks-azure |
bors
added
S-waiting-on-review
|
@bors retry |
bors
added
S-waiting-on-bors
Revert two unapproved changes to rustc_typeck. There was a breakdown in process (rust-lang#59004 (comment), rust-lang#58894 (comment)) and two changes were made to `rustc_typeck`'s "collect" queries, for rustdoc, that were neither needed *nor* correct. I'm reverting them here, and will fix up rustdoc *somehow*, if necessary. cc @rust-lang/compiler How do we ensure this doesn't happen again? r? @nikomatsakis or @oli-obk
Rollup of 5 pull requests Successful merges: - #59789 (Revert two unapproved changes to rustc_typeck.) - #65752 (Use structured suggestions for missing associated items) - #65884 (syntax: ABI-oblivious grammar) - #65974 (A scheme for more macro-matcher friendly pre-expansion gating) - #66017 (Add future incompatibility lint for `array.into_iter()`) Failed merges: - #66056 (rustc_metadata: Some reorganization of the module structure) r? @ghost
There was a breakdown in process (#59004 (comment), #58894 (comment)) and two changes were made to
rustc_typeck's "collect" queries, for rustdoc, that were neither needed nor correct.I'm reverting them here, and will fix up rustdoc somehow, if necessary.
cc @rust-lang/compiler How do we ensure this doesn't happen again?
r? @nikomatsakis or @oli-obk