Rename try! macro for 2018 compatibility

[withoutboats]

serde derive uses a custom defined try! macro internally, rather than ?. However, try is becoming a reserved word in the 2018 edition. For compatibility with 2018, it would be ideal if you renamed this macro.

[Mark-Simulacrum]

Hm, it's not clear to me that Serde should be responsible for making this change? That is, when/if Serde migrates to 2018 edition then it should but prior to that it was my understanding that edition hygiene should not require this -- am I wrong about that?

[withoutboats]

You're correct that users should not get edition related warnings from the expansion of external macros.

[Mark-Simulacrum]

I'm not quite sure what the intent of this issue is then since I can't seem to produce any warnings -- is this just a long-term cleanup?

[dtolnay]

I'm not clear then. Is this something we need to prioritize before the edition? Or is this just tracking work that needs to happen at some point before we change our own edition to 2018, which may be years later?

[withoutboats]

According to the user report on internals, the compiler might not be successfully performing edition hygiene in all cases. Obviously, this is a bug in the compiler. But this seems like a small change to serde_derive that would help mitigate edition hygiene bugs and keep them from impacting the many users of this crate.

[dtolnay]

Internals thread: Trying Rust2018, getting many warnings on `try` is a keyword

I am not able to reproduce the warnings reported there. If anyone succeeds in reproducing and can explain why this is something that a large number of users would encounter, then I can reconsider, but for now I am closing this issue. Thanks anyway! We'll take care of this when moving Serde to 2018 but don't need an issue to track this specific piece of that work.

Hopefully this helps track down the remaining places were edition hygiene is going wrong. I believe our use of try is within the space of what needs to be supported.

[alisianoi]

If anyone succeeds in reproducing and can explain why this is something that a large number of users would encounter, then I can reconsider, but for now I am closing this issue.

For me there is a warning in my emacs. My configuration (relevant part is lines 80 to 90) is inspired by a fairly common configuration for Rust development from reddit. The warning is triggered whenever I save the file, my screen gets split in two halves and the bottom half shows the exception (twice for whatever reason):

If this is theoretically just an issue of replacing ~200 occurances of try! in the codebase, I can do that. So far, I've replaced all try! occurances in two files and cargo test still works:

1. serde/src/ser/mod.rs
2. serde/src/ser/impls.rs

My Rust skills are limited, so I actually have no idea if replacing try! with ? will break things

Edit:

% cargo --version
cargo 1.45.0-nightly (cb06cb269 2020-05-08)
% rustc --version
rustc 1.45.0-nightly (a74d1862d 2020-05-14)

[dtolnay]

That looks like the emacs integration is building the code using the wrong edition. Is there a bug report about that?

[alisianoi]

At my previous comment, my rustup toolchain list looked like this:

nightly-2019-08-27-x86_64-unknown-linux-gnu
nightly-2020-02-27-x86_64-unknown-linux-gnu
nightly-2020-04-08-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu (default)

I removed every toolchain with rustup toolchain uninstall and then reinstalled nightly like so:

$ rustup toolchain install nightly
$ rustup toolchain list
nightly-x86_64-unknown-linux-gnu (default)

I also removed all of my rust-related .emacs configurations and only left the "run rustfmt when I press save" configuration and restarted my emacs:

(setq rust-format-on-save t)                                                                                                                                   

With that, the error message changed slightly but is still largely the same:

[dtolnay]

I will lock this issue for now because this isn't the place to debug that particular emacs bug.