rustc: disallow cloning HIR nodes. #61968
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
rust-highfive
added
the
S-waiting-on-review
|
@bors try (for perf) |
bors
added a commit
that referenced
this pull request
Jun 19, 2019
rustc: disallow cloning HIR nodes.
Besides being inefficient, cloning also risks creating broken HIR (without properly recreating all the IDs and whatnot, in which case you might as well reconstruct the entire node without ever `Clone`-ing anything).
We detect *some* detrimental situations (based on the occurrence of `HirId`s, I believe?), but it's better to statically disallow it, IMO.
One of the examples that is fixed by this PR is `tcx.hir().fn_decl{,_by_hir_id}`, which was cloning an entire `hir::FnDecl` *every single time it was called*.
r? @petrochenkov cc @rust-lang/compiler
|
☀️ Try build successful - checks-travis |
|
@rust-timer build 748a202 |
|
Success: Queued 748a202 with parent e79b2a1, comparison URL. |
petrochenkov
added
S-waiting-on-perf
|
Nice. |
|
r=me when the perf run is complete |
|
Finished benchmarking try commit 748a202, comparison URL. |
|
@bors r=petrochenkov |
|
📌 Commit 673c3fc has been approved by |
bors
added
the
S-waiting-on-bors
Centril
added a commit
to Centril/rust
that referenced
this pull request
Jun 20, 2019
rustc: disallow cloning HIR nodes.
Besides being inefficient, cloning also risks creating broken HIR (without properly recreating all the IDs and whatnot, in which case you might as well reconstruct the entire node without ever `Clone`-ing anything).
We detect *some* detrimental situations (based on the occurrence of `HirId`s, I believe?), but it's better to statically disallow it, IMO.
One of the examples that is fixed by this PR is `tcx.hir().fn_decl{,_by_hir_id}`, which was cloning an entire `hir::FnDecl` *every single time it was called*.
r? @petrochenkov cc @rust-lang/compiler
|
Uhhh I thought @Zoxc had concerns regarding this, but now it's already in a rollup. |
|
Apologies-- I missed that there was discussion happening about this elsewhere. |
bors
added a commit
to rust-lang/rust-clippy
that referenced
this pull request
Jun 21, 2019
Fix breakage due to rust-lang/rust#61968 <!-- Thank you for making Clippy better! We're collecting our changelog from pull request descriptions. If your PR only updates to the latest nightly, you can leave the `changelog` entry as `none`. Otherwise, please write a short comment explaining your change. If your PR fixes an issue, you can add "fixes #issue_number" into this PR description. This way the issue will be automatically closed when your PR is merged. If you added a new lint, here's a checklist for things that will be checked during review or continuous integration. - [ ] Followed [lint naming conventions][lint_naming] - [ ] Added passing UI tests (including committed `.stderr` file) - [ ] `cargo test` passes locally - [ ] Executed `util/dev update_lints` - [ ] Added lint documentation - [ ] Run `cargo fmt` Note that you can skip the above if you are just opening a WIP PR in order to get feedback. Delete this line and everything above before opening your PR --> changelog: none
Manishearth
added a commit
to Manishearth/rust
that referenced
this pull request
Jul 2, 2019
rustc: use a separate copy of P for HIR than for AST. Note: this currently includes/is based on top of rust-lang#61987. Like rust-lang#61968, but goes one step further and uses a separate `P<...>` for the HIR, with no `Clone`, or the ability to mutate after allocation. There is still `into_inner`/`into_iter`, but they're only exposed for `hir::lowering`, and they would take more work to untangle. r? @petrochenkov cc @rust-lang/compiler
bors
added a commit
that referenced
this pull request
Jul 3, 2019
rustc: use a separate copy of P for HIR than for AST. Note: this currently includes/is based on top of #61987. Like #61968, but goes one step further and uses a separate `P<...>` for the HIR, with no `Clone`, or the ability to mutate after allocation. There is still `into_inner`/`into_iter`, but they're only exposed for `hir::lowering`, and they would take more work to untangle. r? @petrochenkov cc @rust-lang/compiler
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Besides being inefficient, cloning also risks creating broken HIR (without properly recreating all the IDs and whatnot, in which case you might as well reconstruct the entire node without ever
Clone-ing anything).We detect some detrimental situations (based on the occurrence of
HirIds, I believe?), but it's better to statically disallow it, IMO.One of the examples that is fixed by this PR is
tcx.hir().fn_decl{,_by_hir_id}, which was cloning an entirehir::FnDeclevery single time it was called.r? @petrochenkov cc @rust-lang/compiler