nordic-dev.net/rust
nordic-dev.net/rust
2
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2024-11-23 07:14:28 +00:00
Code Issues Packages Projects Releases Wiki Activity
64af509377
rust/tests/ui/proc-macro/issue-73933-procedural-masquerade.stdout

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

22 lines
525 B
Plaintext
Raw Normal View History

Only apply `ProceduralMasquerade` hack to older versions of `rental` The latest version of `rental` (v0.5.6) contains a fix that allows it to compile without relying on the pretty-print back-compat hack. Hopefully, there are no longer any crates relying on the affected versions of the (much less popular) `procedural-masquerade` crate. This should allow us to target the pretty-print back-compat hack specifically to older versions of `rental`, and specifically mention upgrading to `rental` v0.5.6 in the lint message.
2022-02-16 19:48:39 +00:00
PRINT-DERIVE INPUT (DISPLAY): enum ProceduralMasqueradeDummyType { Input }
Extend `proc_macro_back_compat` lint to `procedural-masquerade` We now lint on *any* use of `procedural-masquerade` crate. While this crate still exists, its main reverse dependency (`cssparser`) no longer depends on it. Any crates still depending off should stop doing so, as it only exists to support very old Rust versions. If a crate actually needs to support old versions of rustc via `procedural-masquerade`, then they'll just need to accept the warning until we remove it entirely (at the same time as the back-compat hack). The latest version of `procedural-masquerade` does not work with the latest rustc, but trying to check for the version seems like more trouble than it's worth. While working on this, I realized that the `proc-macro-hack` check was never actually doing anything. The corresponding enum variant in `proc-macro-hack` is named `Value` or `Nested` - it has never been called `Input`. Due to a strange Crater issue, the Crater run that tested adding this did *not* end up testing it - some of the crates that would have failed did not actually have their tests checked, making it seem as though the `proc-macro-hack` check was working. The Crater issue is being discussed at https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/Nearly.20identical.20Crater.20runs.20processed.20a.20crate.20differently/near/230406661 Despite the `proc-macro-hack` check not actually doing anything, we haven't gotten any reports from users about their build being broken. I went ahead and removed it entirely, since it's clear that no one is being affected by the `proc-macro-hack` regression in practice.
2021-03-15 19:54:25 +00:00
PRINT-DERIVE INPUT (DEBUG): TokenStream [
Ident {
ident: "enum",
Only apply `ProceduralMasquerade` hack to older versions of `rental` The latest version of `rental` (v0.5.6) contains a fix that allows it to compile without relying on the pretty-print back-compat hack. Hopefully, there are no longer any crates relying on the affected versions of the (much less popular) `procedural-masquerade` crate. This should allow us to target the pretty-print back-compat hack specifically to older versions of `rental`, and specifically mention upgrading to `rental` v0.5.6 in the lint message.
2022-02-16 19:48:39 +00:00
span: #0 bytes(100..104),
Extend `proc_macro_back_compat` lint to `procedural-masquerade` We now lint on *any* use of `procedural-masquerade` crate. While this crate still exists, its main reverse dependency (`cssparser`) no longer depends on it. Any crates still depending off should stop doing so, as it only exists to support very old Rust versions. If a crate actually needs to support old versions of rustc via `procedural-masquerade`, then they'll just need to accept the warning until we remove it entirely (at the same time as the back-compat hack). The latest version of `procedural-masquerade` does not work with the latest rustc, but trying to check for the version seems like more trouble than it's worth. While working on this, I realized that the `proc-macro-hack` check was never actually doing anything. The corresponding enum variant in `proc-macro-hack` is named `Value` or `Nested` - it has never been called `Input`. Due to a strange Crater issue, the Crater run that tested adding this did *not* end up testing it - some of the crates that would have failed did not actually have their tests checked, making it seem as though the `proc-macro-hack` check was working. The Crater issue is being discussed at https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/Nearly.20identical.20Crater.20runs.20processed.20a.20crate.20differently/near/230406661 Despite the `proc-macro-hack` check not actually doing anything, we haven't gotten any reports from users about their build being broken. I went ahead and removed it entirely, since it's clear that no one is being affected by the `proc-macro-hack` regression in practice.
2021-03-15 19:54:25 +00:00
},
Ident {
ident: "ProceduralMasqueradeDummyType",
Only apply `ProceduralMasquerade` hack to older versions of `rental` The latest version of `rental` (v0.5.6) contains a fix that allows it to compile without relying on the pretty-print back-compat hack. Hopefully, there are no longer any crates relying on the affected versions of the (much less popular) `procedural-masquerade` crate. This should allow us to target the pretty-print back-compat hack specifically to older versions of `rental`, and specifically mention upgrading to `rental` v0.5.6 in the lint message.
2022-02-16 19:48:39 +00:00
span: #0 bytes(105..134),
Extend `proc_macro_back_compat` lint to `procedural-masquerade` We now lint on *any* use of `procedural-masquerade` crate. While this crate still exists, its main reverse dependency (`cssparser`) no longer depends on it. Any crates still depending off should stop doing so, as it only exists to support very old Rust versions. If a crate actually needs to support old versions of rustc via `procedural-masquerade`, then they'll just need to accept the warning until we remove it entirely (at the same time as the back-compat hack). The latest version of `procedural-masquerade` does not work with the latest rustc, but trying to check for the version seems like more trouble than it's worth. While working on this, I realized that the `proc-macro-hack` check was never actually doing anything. The corresponding enum variant in `proc-macro-hack` is named `Value` or `Nested` - it has never been called `Input`. Due to a strange Crater issue, the Crater run that tested adding this did *not* end up testing it - some of the crates that would have failed did not actually have their tests checked, making it seem as though the `proc-macro-hack` check was working. The Crater issue is being discussed at https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/Nearly.20identical.20Crater.20runs.20processed.20a.20crate.20differently/near/230406661 Despite the `proc-macro-hack` check not actually doing anything, we haven't gotten any reports from users about their build being broken. I went ahead and removed it entirely, since it's clear that no one is being affected by the `proc-macro-hack` regression in practice.
2021-03-15 19:54:25 +00:00
},
Group {
delimiter: Brace,
stream: TokenStream [
Ident {
ident: "Input",
Only apply `ProceduralMasquerade` hack to older versions of `rental` The latest version of `rental` (v0.5.6) contains a fix that allows it to compile without relying on the pretty-print back-compat hack. Hopefully, there are no longer any crates relying on the affected versions of the (much less popular) `procedural-masquerade` crate. This should allow us to target the pretty-print back-compat hack specifically to older versions of `rental`, and specifically mention upgrading to `rental` v0.5.6 in the lint message.
2022-02-16 19:48:39 +00:00
span: #0 bytes(141..146),
Extend `proc_macro_back_compat` lint to `procedural-masquerade` We now lint on *any* use of `procedural-masquerade` crate. While this crate still exists, its main reverse dependency (`cssparser`) no longer depends on it. Any crates still depending off should stop doing so, as it only exists to support very old Rust versions. If a crate actually needs to support old versions of rustc via `procedural-masquerade`, then they'll just need to accept the warning until we remove it entirely (at the same time as the back-compat hack). The latest version of `procedural-masquerade` does not work with the latest rustc, but trying to check for the version seems like more trouble than it's worth. While working on this, I realized that the `proc-macro-hack` check was never actually doing anything. The corresponding enum variant in `proc-macro-hack` is named `Value` or `Nested` - it has never been called `Input`. Due to a strange Crater issue, the Crater run that tested adding this did *not* end up testing it - some of the crates that would have failed did not actually have their tests checked, making it seem as though the `proc-macro-hack` check was working. The Crater issue is being discussed at https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/Nearly.20identical.20Crater.20runs.20processed.20a.20crate.20differently/near/230406661 Despite the `proc-macro-hack` check not actually doing anything, we haven't gotten any reports from users about their build being broken. I went ahead and removed it entirely, since it's clear that no one is being affected by the `proc-macro-hack` regression in practice.
2021-03-15 19:54:25 +00:00
},
],
Only apply `ProceduralMasquerade` hack to older versions of `rental` The latest version of `rental` (v0.5.6) contains a fix that allows it to compile without relying on the pretty-print back-compat hack. Hopefully, there are no longer any crates relying on the affected versions of the (much less popular) `procedural-masquerade` crate. This should allow us to target the pretty-print back-compat hack specifically to older versions of `rental`, and specifically mention upgrading to `rental` v0.5.6 in the lint message.
2022-02-16 19:48:39 +00:00
span: #0 bytes(135..148),
Extend `proc_macro_back_compat` lint to `procedural-masquerade` We now lint on *any* use of `procedural-masquerade` crate. While this crate still exists, its main reverse dependency (`cssparser`) no longer depends on it. Any crates still depending off should stop doing so, as it only exists to support very old Rust versions. If a crate actually needs to support old versions of rustc via `procedural-masquerade`, then they'll just need to accept the warning until we remove it entirely (at the same time as the back-compat hack). The latest version of `procedural-masquerade` does not work with the latest rustc, but trying to check for the version seems like more trouble than it's worth. While working on this, I realized that the `proc-macro-hack` check was never actually doing anything. The corresponding enum variant in `proc-macro-hack` is named `Value` or `Nested` - it has never been called `Input`. Due to a strange Crater issue, the Crater run that tested adding this did *not* end up testing it - some of the crates that would have failed did not actually have their tests checked, making it seem as though the `proc-macro-hack` check was working. The Crater issue is being discussed at https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/Nearly.20identical.20Crater.20runs.20processed.20a.20crate.20differently/near/230406661 Despite the `proc-macro-hack` check not actually doing anything, we haven't gotten any reports from users about their build being broken. I went ahead and removed it entirely, since it's clear that no one is being affected by the `proc-macro-hack` regression in practice.
2021-03-15 19:54:25 +00:00
},
]
Reference in New Issue Copy Permalink