Change how edition based future compatibility warnings are handled #86330
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
m-ou-se
reviewed
Jun 15, 2021
6 tasks
rylev
force-pushed
the
update-fcw-handling
branch
from
4e75ec9 to
c818e47
Compare
m-ou-se
reviewed
Jun 17, 2021
m-ou-se
added
A-diagnostics
rylev
added
S-waiting-on-review
nikomatsakis
approved these changes
Jun 23, 2021
|
@bors r+ |
|
📌 Commit 44d86a9e1d7515b3858b0939a686dd4034d3ecb2 has been approved by |
bors
added
S-waiting-on-bors
rylev
force-pushed
the
update-fcw-handling
branch
from
44d86a9 to
e7adb02
Compare
|
@bors r=nikomatsakis |
|
📌 Commit e7adb02 has been approved by |
m-ou-se
added a commit
to m-ou-se/rust
that referenced
this pull request
Jun 24, 2021
…tsakis Change how edition based future compatibility warnings are handled This fixes rust-lang#85894 by updating how future compatibility lints work. This makes it more apparent that future compatibility warnings can happen for several different reasons. For now `FutureCompatibilityReasons` are limited to three reasons, but we can easily add more. This also updates the generated warning for FCW's that signal code that will error in a future edition. This makes the diagnostics between FCWs at edition boundaries more distinct from those not happening at an edition boundary. r? `@m-ou-se`
bors
added
the
S-waiting-on-author
|
☔ The latest upstream changes (presumably #86574) made this pull request unmergeable. Please resolve the merge conflicts. |
rylev
force-pushed
the
update-fcw-handling
branch
from
e7adb02 to
51f223e
Compare
|
@JohnTitor I've addressed the clippy test. This should be ready for bors again. |
|
Thanks! |
|
📌 Commit 51f223e has been approved by |
bors
added
S-waiting-on-bors
JohnTitor
added a commit
to JohnTitor/rust
that referenced
this pull request
Jun 25, 2021
…tsakis Change how edition based future compatibility warnings are handled This fixes rust-lang#85894 by updating how future compatibility lints work. This makes it more apparent that future compatibility warnings can happen for several different reasons. For now `FutureCompatibilityReasons` are limited to three reasons, but we can easily add more. This also updates the generated warning for FCW's that signal code that will error in a future edition. This makes the diagnostics between FCWs at edition boundaries more distinct from those not happening at an edition boundary. r? `@m-ou-se`
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jun 25, 2021
Rollup of 5 pull requests Successful merges: - rust-lang#86330 (Change how edition based future compatibility warnings are handled) - rust-lang#86513 (Rustdoc: Do not list impl when trait has doc(hidden)) - rust-lang#86592 (Use `#[non_exhaustive]` where appropriate) - rust-lang#86608 (chore(rustdoc): remove unused members of RenderType) - rust-lang#86624 (Update compiler-builtins) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang/cargo
that referenced
this pull request
Jun 29, 2021
Temporarily disable future_incompat tests. The `array_into_iter` lint is no longer future-breaking (via rust-lang/rust#86330), so these tests won't work anymore. This disables the tests until rust-lang/rust#86478 is merged to provide a way to start testing again.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jun 30, 2021
…omatsakis Only include lint in future_incompatible lint group if not an edition lint A follow up to rust-lang#86330 - this only includes lints annotated with `FutureIncompatibleInfo` in the `future_incompatibile` lint group if the future compatibility is not tied to an edition. We probably want to rename `FutureIncompatibleInfo` to something else since this type is now used to indicate future breakages of all kinds (even those that happen in editions). I'd prefer to do that in a separate PR though. r? `@nikomatsakis`
JohnTitor
added a commit
to JohnTitor/rust
that referenced
this pull request
Jul 15, 2021
Add -Zfuture-incompat-test to assist with testing future-incompat reports. This adds a `-Zfuture-incompat-test` cli flag to assist with testing future-incompatible reports. This flag causes all lints to be treated as a future-incompatible lint, and will emit a report for them. This is being added so that Cargo's testsuite can reliably test the reporting infrastructure. Right now, Cargo relies on using array_into_iter as a test subject. Since the breaking "future incompatible" lints are never intended to last forever, this means Cargo's testsuite would always need to keep changing to choose different lints (for example, rust-lang#86330 proposed dropping that moniker for array_into_iter). With this flag, Cargo's tests can trigger any lint and check for the report.
JohnTitor
added a commit
to JohnTitor/rust
that referenced
this pull request
Jul 15, 2021
Add -Zfuture-incompat-test to assist with testing future-incompat reports. This adds a `-Zfuture-incompat-test` cli flag to assist with testing future-incompatible reports. This flag causes all lints to be treated as a future-incompatible lint, and will emit a report for them. This is being added so that Cargo's testsuite can reliably test the reporting infrastructure. Right now, Cargo relies on using array_into_iter as a test subject. Since the breaking "future incompatible" lints are never intended to last forever, this means Cargo's testsuite would always need to keep changing to choose different lints (for example, rust-lang#86330 proposed dropping that moniker for array_into_iter). With this flag, Cargo's tests can trigger any lint and check for the report.
JohnTitor
added a commit
to JohnTitor/rust
that referenced
this pull request
Jul 15, 2021
Add -Zfuture-incompat-test to assist with testing future-incompat reports. This adds a `-Zfuture-incompat-test` cli flag to assist with testing future-incompatible reports. This flag causes all lints to be treated as a future-incompatible lint, and will emit a report for them. This is being added so that Cargo's testsuite can reliably test the reporting infrastructure. Right now, Cargo relies on using array_into_iter as a test subject. Since the breaking "future incompatible" lints are never intended to last forever, this means Cargo's testsuite would always need to keep changing to choose different lints (for example, rust-lang#86330 proposed dropping that moniker for array_into_iter). With this flag, Cargo's tests can trigger any lint and check for the report.
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.
This fixes #85894 by updating how future compatibility lints work. This makes it more apparent that future compatibility warnings can happen for several different reasons.
For now
FutureCompatibilityReasonsare limited to three reasons, but we can easily add more.This also updates the generated warning for FCW's that signal code that will error in a future edition. This makes the diagnostics between FCWs at edition boundaries more distinct from those not happening at an edition boundary.
r? @m-ou-se