Skip to content
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

Report usage of lib features in ast validation #127587

Merged
merged 1 commit into from
Jul 14, 2024

Conversation

compiler-errors
Copy link
Member

No idea why it was split between ast validation for lang features and a later pass for lang features.

r? @Nilstrieb

@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 Jul 10, 2024
@compiler-errors
Copy link
Member Author

compiler-errors commented Jul 10, 2024

Oh, it was added in #89012. It didn't even add a test!

I kinda don't care about that, lmao. If we want to fix this the right way we can do that somehow else. I'll reopen #88802 and leave a comment that moving the validation just for library features is likely not the right solution.

@compiler-errors
Copy link
Member Author

compiler-errors commented Jul 10, 2024

Actually, we don't halt compilation if we hit a feature-on-stable error? (At least afaict??)

So the warning that we currently issue for a library feature that is already stable is still there. I don't actually think there's any regression here at all.

Copy link
Member

@Noratrieb Noratrieb left a comment

Choose a reason for hiding this comment

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

ok, this was quite confusing, but I got it eventually.
originally, all the check for whether we're using feature on stable was in ast_passes.
then, it got split, where it's checked in ast_passes when there are lang features, and not in ast_passes when there are any no lang features.
when there are no lang features, it still did a check for libs features specifically in the later pass.
this improved a diagnostic for libs features, but made the code quite confusing (as evidenced by my confusion).
so now you basically just revert that and make it nice again, where everything is checked in ast_passes.
good!

@Noratrieb
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Jul 14, 2024

📌 Commit 153a381 has been approved by Nilstrieb

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 Jul 14, 2024
@Noratrieb
Copy link
Member

and don't forget to reopen the issue!

@compiler-errors
Copy link
Member Author

and don't forget to reopen the issue!

Wait, did you see my last comment? I don't think this regresses the issue. I will just add a test.

@bors r-

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 14, 2024
@Noratrieb
Copy link
Member

uh, right. yeah.

@compiler-errors
Copy link
Member Author

It did in fact not regress:

error[E0554]: `#![feature]` may not be used on the dev release channel
 --> /home/michael/test.rs:1:1
  |
1 | #![feature(discriminant_value)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

warning: the feature `discriminant_value` has been stable since 1.21.0 and no longer requires an attribute to enable
 --> /home/michael/test.rs:1:12
  |
1 | #![feature(discriminant_value)]
  |            ^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(stable_features)]` on by default

But also I can't add a test for it because we don't error for feature() on nightly, lol. Too lazy to add a cfg or something to test this. This is a custom build that disables feature in the compiler.

@bors r=Nilstrieb

@bors
Copy link
Contributor

bors commented Jul 14, 2024

📌 Commit 153a381 has been approved by Nilstrieb

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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 14, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 14, 2024
…iaskrgr

Rollup of 5 pull requests

Successful merges:

 - rust-lang#127273 (Fix `DebugParser`.)
 - rust-lang#127587 (Report usage of lib features in ast validation)
 - rust-lang#127592 (doc: Suggest `str::repeat` over `iter::repeat().take().collect()`)
 - rust-lang#127630 (Remove lang feature for type ascription (since it's a lib feature now))
 - rust-lang#127711 (Add regression test for a gce + effects ICE)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 5d1f9e2 into rust-lang:master Jul 14, 2024
6 checks passed
@rustbot rustbot added this to the 1.81.0 milestone Jul 14, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Jul 14, 2024
Rollup merge of rust-lang#127587 - compiler-errors:all-features-at-once, r=Nilstrieb

Report usage of lib features in ast validation

No idea why it was split between ast validation for lang features and a later pass for lang features.

r? `@Nilstrieb`
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.

4 participants