Skip to content

Remove (lots of) dead code #83185

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Merged
merged 6 commits into from
Mar 29, 2021
Merged

Remove (lots of) dead code #83185

merged 6 commits into from
Mar 29, 2021

Conversation

jyn514
Copy link
Member

@jyn514 jyn514 commented Mar 16, 2021

Builds on

Found with https://github.com/est31/warnalyzer.
See #77739 for a similar change in the past.

Dubious changes:

  • Maybe some of the dead code in rustc_data_structures should be kept, in case someone wants to use it in the future?

TODO:

cc @est31

@jyn514 jyn514 added C-cleanup Category: PRs that clean code up or issues documenting cleanup. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 16, 2021
@rust-highfive
Copy link
Contributor

r? @oli-obk

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 16, 2021
@rust-log-analyzer

This comment has been minimized.

@jyn514 jyn514 force-pushed the remove-dead-code branch 2 times, most recently from 86e1dd2 to 08e596a Compare March 16, 2021 06:22
@jyn514
Copy link
Member Author

jyn514 commented Mar 16, 2021

@bors try @rust-timer queue

I expect this to help hello-world, but not much else.

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Mar 16, 2021
@bors
Copy link
Collaborator

bors commented Mar 16, 2021

⌛ Trying commit 08e596a84bea96a0d8c3799c36724c012bb9154b with merge cee392aca3bbc45102766189904bd3c29f498f19...

@rust-log-analyzer

This comment has been minimized.

@jyn514 jyn514 force-pushed the remove-dead-code branch from 08e596a to c6d3f5e Compare March 16, 2021 06:29
@rust-log-analyzer

This comment has been minimized.

@jyn514 jyn514 force-pushed the remove-dead-code branch 2 times, most recently from 3dd122c to aa09c5b Compare March 16, 2021 06:38
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@thomcc
Copy link
Member

thomcc commented Mar 16, 2021

Hmm, it seems likely that the resolution of some of our floating point bugs will require more architecture-awareness of floats, rather than less, but I guess if we aren't using it we could just resurrect the code from git history if that time comes...

@oli-obk
Copy link
Contributor

oli-obk commented Mar 16, 2021

Is anyone else using rustc_apfloat? I feel weird completely deleting x87 support.

Please don't touch rustc_apfloat without conferring with @eddyb . They manually transpiled llvm's apfloat to Rust and this is the result. We should not touch that library afaik.

@eddyb
Copy link
Member

eddyb commented Mar 16, 2021

So the whole deal with rustc_apfloat is that it's supposed to become a long-lived "faithful translation" that tracks upstream (i.e. backporting newer bug fixes), and also we try to also upstream any bug fixes we come up with.

It shouldn't even be in-tree IMO, see also #55993 - people have wanted to use it elsewhere, too.

But I haven't been able to do as much as I want with it because it's been stuck in licensing limbo for years.

I don't dare to touch it at all, really, while the licensing situation is up in the air, in the fear that it will prolong the limbo (originally I was assured there were no licensing issues and whoever told me that was wrong, so I don't want that to happen again) and I'd strongly advise anyone else against messing with it.

(Can we add a rule somewhere that makes rust-highfive ping me whenever someone touches compiler/rustc_apfloat?)

Once the licensing situation is sorted out, and we can move it out of tree, publish on crates.io, etc. I want to take this "two main branches" approach, to cleanly separate what's "tracking LLVM upstream" and what's our own patches: #55993 (comment)

Comment on lines -11 to -15
impl<'tcx> ImpliedOutlivesBounds<'tcx> {
pub fn new(ty: Ty<'tcx>) -> Self {
ImpliedOutlivesBounds { ty }
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @nikomatsakis unsure what's going on here.

@jyn514
Copy link
Member Author

jyn514 commented Mar 28, 2021

I added back all the functions @oli-obk asked I keep, this should be ready for another round of review.

@jyn514 jyn514 added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 28, 2021
@oli-obk
Copy link
Contributor

oli-obk commented Mar 29, 2021

Except for the sync stuff, everything lgtm. I have no strong opinion, but since I have good hopes that the work on parallel compiler will continue this year, I'm worried this removes things we'll just need to add again. I don't know who to ping about it right now though

@jyn514
Copy link
Member Author

jyn514 commented Mar 29, 2021

Except for the sync stuff, everything lgtm. I have no strong opinion, but since I have good hopes that the work on parallel compiler will continue this year, I'm worried this removes things we'll just need to add again. I don't know who to ping about it right now though

It looks like SerialScope was added as part of #50235, and AtomicCell as part of #62577.

cc @Zoxc - do these changes to rustc_data_structures::sync look ok?

There isn't currently a good reviewer for these, and I don't want to
remove things that will just be added again. I plan to make a separate
PR for these changes so the rest of the cleanup can land.
@jyn514
Copy link
Member Author

jyn514 commented Mar 29, 2021

I reverted the sync changes, I'll make a separate PR for them so they don't hold up everything else.

@bors r=oli-obk

@bors
Copy link
Collaborator

bors commented Mar 29, 2021

📌 Commit 526bb10 has been approved by oli-obk

@bors 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 Mar 29, 2021
@bors
Copy link
Collaborator

bors commented Mar 29, 2021

⌛ Testing commit 526bb10 with merge 48691ea...

@bors
Copy link
Collaborator

bors commented Mar 29, 2021

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 48691ea to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Mar 29, 2021
@bors bors merged commit 48691ea into rust-lang:master Mar 29, 2021
@rustbot rustbot added this to the 1.53.0 milestone Mar 29, 2021
@jyn514 jyn514 deleted the remove-dead-code branch March 29, 2021 22:29
dtolnay added a commit to dtolnay/syn that referenced this pull request Mar 30, 2021
bors added a commit to rust-lang-ci/rust that referenced this pull request May 9, 2021
Remove dead or useless code from Session

This is a more principled follow-up to rust-lang#83185 (comment).

- Rename `Parser::span_fatal_err` -> `Parser::span_err`
- Remove some unnecessary uses of `struct_span_fatal`
- Make `Diagnostic::span_fatal` unconditionally raise an error
- Add `impl Deref<Target = Handler>` for Session and remove all functions that are exactly the same as their Handler counterparts
- Note why `Handler::fatal` is different from `Sesssion::fatal`
- Remove unused `opt_span_warn` function

r? `@oli-obk` or `@estebank`
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Jun 4, 2021
Remove unused code from `rustc_data_structures::sync`

Found using https://github.com/est31/warnalyzer. Follow-up to rust-lang#83185.

r? `@Zoxc` cc `@oli-obk`
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Sep 17, 2021
Make diagnostics clearer for `?` operators

Re-submission of rust-lang#75029, fixes rust-lang#71309
This also revives the `content` methods removed by rust-lang#83185.
r? `@estebank`
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. merged-by-bors This PR was explicitly merged by bors. 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.