Guard does not build anymore on 1.70

[xmo-odoo]

Heya, I don't know if you maintain this much anymore, but it fails to build on 1.70: Rust removed support for box_syntax (rust-lang/rust#108471).

guard only uses it in a single test gated behind cfg(nightly) so it should not be an issue, but it is:

❯ git clone https://github.com/durka/guard/
[...]
❯ cd guard
❯ cargo b
   Compiling guard v0.5.1 (~/guard)
error: `box_syntax` has been removed
   --> src/lib.rs:426:20
    |
426 |         let foo = (box 42, [1, 2, 3]);
    |                    ^^^^^^
    |
help: use `Box::new()` instead
    |
426 |         let foo = (Box::new(42), [1, 2, 3]);
    |                    ~~~~~~~~~~~~

error: `box_syntax` has been removed
   --> src/lib.rs:430:29
    |
430 |         let mut foo = Some((box 42, [1, 2, 3]));
    |                             ^^^^^^
    |
help: use `Box::new()` instead
    |
430 |         let mut foo = Some((Box::new(42), [1, 2, 3]));
    |                             ~~~~~~~~~~~~

error: `box_syntax` has been removed
   --> src/lib.rs:446:20
    |
446 |         let foo = (box 42, [1, 2, 3]);
    |                    ^^^^^^
    |
help: use `Box::new()` instead
    |
446 |         let foo = (Box::new(42), [1, 2, 3]);
    |                    ~~~~~~~~~~~~

error: `box_syntax` has been removed
   --> src/lib.rs:451:20
    |
451 |         let foo = (box 42, [1, 2, 3]);
    |                    ^^^^^^
    |
help: use `Box::new()` instead
    |
451 |         let foo = (Box::new(42), [1, 2, 3]);
    |                    ~~~~~~~~~~~~

error: could not compile `guard` (lib) due to 4 previous errors

[durka]

Thanks for the report. This crate isn't needed anymore since the feature is in rust, but it's good to keep it building. I've removed box_syntax and published v0.5.2.

[xmo-odoo]

Thanks for the report. This crate isn't needed anymore since the feature is in rust, but it's good to keep it building. I've removed box_syntax and published v0.5.2.

Thank you for the work.

I think the crate is still useful to remain compatible with older versions of Rust. 1.65 is only a hair more than 6 months old, so e.g. debian bookworm ships with 1.63. Also because frankly it works just fine and it's not really worth updating. I've just done that in a custom codebase, and while rust-analyzer can inline macros they have to be inlined one by one and the formatting is completely borked, and rust-analyzer is not currently able to format let-else statements. In hindsight I should have just search and replaced the guard!( an removed the trailing parens, but I found out RA couldn't do it afterwards.

I assume the breakage despite use being behind both cfg and #[test] is because it's a syntactic component so rustc still needs to parse it in order to process the rest of the file? Do you think I should report this to rustc?

[durka]

Do you think I should report this to rustc?

I'm unsure about this. You could argue that it's a stable regression since the code compiled before. But on 1.69, you get a clear warning even with the feature gate: https://rust.godbolt.org/z/6d916faE1 So I'm not sure how else they could really be expected to phase it out.

[xmo-odoo]

I'm unsure about this. You could argue that it's a stable regression since the code compiled before. But on 1.69, you get a clear warning even with the feature gate: rust.godbolt.org/z/6d916faE1 So I'm not sure how else they could really be expected to phase it out.

While that's technically true, the warning is only visible when compiling the problematic package directly, it does not show up when the warning is triggered by a dependency (which would explain why I never noticed I guess).

And the biggest issue to me is that why somewhat understandable here it breaks compilation even when gated out by two different cfgs which is quite annoying.

[durka]

Well, we could report it, the worst that happens is it's closed as a misunderstanding!

…

On Tue, Jun 6, 2023 at 1:56 AM xmo-odoo ***@***.***> wrote: I'm unsure about this. You could argue that it's a stable regression since the code compiled before. But on 1.69, you get a clear warning even with the feature gate: rust.godbolt.org/z/6d916faE1 So I'm not sure how else they could really be expected to phase it out. While that's technically true, the warning is only visible when compiling the problematic package directly, it does not show up when the warning is triggered by a dependency (which would explain why I never noticed I guess). And the biggest issue to me is that why somewhat understandable here it breaks compilation even when gated out by two different cfgs which is quite annoying. — Reply to this email directly, view it on GitHub <#10 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAALPH2Y5DHAOMMBQWNZJWDXJ3BAZANCNFSM6AAAAAAYX5ENKA> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>