Skip to content

Don't skip argument parsing when running rustc with no arguments#135716

Merged
bors merged 1 commit into
rust-lang:masterfrom
Zalathar:usage-no-args
Jan 19, 2025
Merged

Don't skip argument parsing when running rustc with no arguments#135716
bors merged 1 commit into
rust-lang:masterfrom
Zalathar:usage-no-args

Conversation

@Zalathar

Copy link
Copy Markdown
Member

Setting up the argument parser to parse no arguments is a tiny bit of wasted work, but avoids an otherwise-unnecessary special case, in a scenario (printing a help message and quitting) where perf at this scale really doesn't matter anyway.

In particular, this lets us avoid having to deal with multiple different APIs to determine whether the compiler is nightly or not.


This special-case handling for rustc with no arguments is very very old (long predating 1.0), and used to be much simpler, without any need to set up boolean values to handle various conditional cases. So I don't think it was ever explicitly decided that having this special case was worth the extra complexity; it just started out simple and accumulated complexity over time.

Setting up the argument parser to parse no arguments is a tiny bit of wasted
work, but avoids an otherwise-unnecessary special case.

In particular, this lets us avoid having to deal with multiple different APIs
to determine whether the compiler is nightly or not.
@rustbot

rustbot commented Jan 19, 2025

Copy link
Copy Markdown
Collaborator

r? @fee1-dead

rustbot has assigned @fee1-dead.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot 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. labels Jan 19, 2025
@Zalathar

Copy link
Copy Markdown
Member Author

My main motivation for actually making this change is to reduce the number of calls to UnstableFeatures::from_environment in the codebase, in the hope that we can bring a bit more order to the code that determines whether the compiler is nightly or not.

@lqd

lqd commented Jan 19, 2025

Copy link
Copy Markdown
Member

Makes sense.

r? lqd @bors r+ rollup

@bors

bors commented Jan 19, 2025

Copy link
Copy Markdown
Collaborator

📌 Commit 93f69b2 has been approved by lqd

It is now in the queue for this repository.

@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 Jan 19, 2025
bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 19, 2025
…llaumeGomez

Rollup of 5 pull requests

Successful merges:

 - rust-lang#134858 (Provide structured suggestion for `#![feature(..)]` in more cases)
 - rust-lang#135679 (create an issue template for bootstrap)
 - rust-lang#135685 (Remove unused `item-row` CSS class)
 - rust-lang#135716 (Don't skip argument parsing when running `rustc` with no arguments)
 - rust-lang#135723 (Fix dev guide docs for error-pattern)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit dcc71c0 into rust-lang:master Jan 19, 2025
@rustbot rustbot added this to the 1.86.0 milestone Jan 19, 2025
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Jan 19, 2025
Rollup merge of rust-lang#135716 - Zalathar:usage-no-args, r=lqd

Don't skip argument parsing when running `rustc` with no arguments

Setting up the argument parser to parse no arguments is a tiny bit of wasted work, but avoids an otherwise-unnecessary special case, in a scenario (printing a help message and quitting) where perf at this scale really doesn't matter anyway.

In particular, this lets us avoid having to deal with multiple different APIs to determine whether the compiler is nightly or not.

---

This special-case handling for rustc with no arguments is very very old (long predating 1.0), and used to be much simpler, without any need to set up boolean values to handle various conditional cases. So I don't think it was ever explicitly decided that having this special case was worth the extra complexity; it just started out simple and accumulated complexity over time.
@Zalathar Zalathar deleted the usage-no-args branch January 19, 2025 23:46
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.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants