-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Partially revert the early feature-gatings added in #65742. #66004
Conversation
This reverts commit 15a6c09.
This reverts commit e4ed886.
This reverts commit 137ded8.
This reverts commit 1935ba6.
This reverts commit 665a876.
This reverts commit 2aff6b3.
This reverts commit 1f470ce.
This reverts commit 49cbfa1.
This reverts commit 04c661b.
This reverts commit c17a1fd.
This reverts commit 2d182b8.
(rust_highfive has picked a reviewer for you, use r? to override) |
@eddyb I think #65742 did the right thing, but if any specific gate causes regressions/issues in practice we can revert it or turn into a |
We wanted to revert so that at least this hits nightly early in the cycle rather than in the last week for additional testing and also wanted some discussion around the general design (in particular, I feel like this is too strict -- I would like to see some exploration of allowing cfg's on stable syntax that may contain unstable syntax). We also felt that the existing crater run was likely not hitting all the cases, specifically, since it was a nightly-enabled crater run, that meant that crates may have been detecting as such and turning features on (which would've masked errors that the PR introduced otherwise). I've been put on the hook for helping out with that crater run, and was planning on trying to do so this weekend. |
Understood. |
📌 Commit 27e01a1 has been approved by |
@bors p=100 |
Partially revert the early feature-gatings added in #65742. The intent here is to address #65860 ASAP (in time for beta, ideally), while leaving as much of #65742 around as possible, to make it easier to re-enable later. Therefore, I've only kept the parts of the revert that re-add the old (i.e. non-early) feature-gating checks that were removed in #65742, and the test reverts. I've disabled the new early feature-gating checks from #65742 entirely for now, but it would be easy to put them behind a `-Z` flag, or turn them into warnings, which would allow us to keep tests for both the early and late versions of the checks - assuming that's desirable. cc @nikomatsakis @Mark-Simulacrum @Centril
☀️ Test successful - checks-azure |
…-loc, r=compiler-errors Lint against misplaced where-clauses on associated types in traits Extends the scope of the lint `deprecated_where_clause_location` (rust-lang#89122) from associated types in impls to associated types in any location (impl or trait). This is only relevant for `#![feature(associated_type_defaults)]`. Previously we didn't warn on the following code for example: ```rs #![feature(associated_type_defaults)] trait Trait { type Assoc where u32: Copy = (); } ``` Personally I would've preferred to emit a *hard* error here instead of a lint warning since the feature is unstable but unfortunately we are constrained by back compat as associated type defaults won't necessarily trigger the feature-gate error if they are inside of a macro call (since they use a post-expansion feature-gate due to historical reasons, see also rust-lang#66004). I've renamed and moved related preexisting tests: 1. They test AST validation passes not the parser & thus shouldn't live in `parser/` (historical reasons?). 2. One test file was named after type aliases even though it tests assoc tys. `@rustbot` label A-lint
The intent here is to address #65860 ASAP (in time for beta, ideally), while leaving as much of #65742 around as possible, to make it easier to re-enable later.
Therefore, I've only kept the parts of the revert that re-add the old (i.e. non-early) feature-gating checks that were removed in #65742, and the test reverts.
I've disabled the new early feature-gating checks from #65742 entirely for now, but it would be easy to put them behind a
-Z
flag, or turn them into warnings, which would allow us to keep tests for both the early and late versions of the checks - assuming that's desirable.cc @nikomatsakis @Mark-Simulacrum @Centril