Update to edition 2018

[pickfire]

Update mdbook to 0.3.5

Command:
sed -i '/extern crate/ {N;s/\n$//}' src/**.md; sed -i 's/extern crate error_chain;/use error_chain::error_chain;/; s/extern crate lazy_static;/use lazy_static::lazy_static;/; s/extern crate bitflags;/use bitflags::bitflags;/; s/extern crate serde_json;/ use serde_json::json;/; s/extern crate serde_derive;/use serde::{Serialize, Deserialize};/; /macro_use/d; /extern crate/ d; s/```rust/```rust,edition2018/; s/bail!/error_chain::&/; s/\(debug\|info\|warn\|error\)!/log::&/;' src/**.md

Fixes #530
Fixes #569

[pickfire]

@AndyGauge Interested to review?

[AndyGauge]

Yeah, I was reading it and I'm impressed. One thing I'm concerned about is if there are any extern crate definitions that the text doesn't include a reference. One thing nice about having those extern crate statements is it makes it easy to set up the recipe's Cargo.toml. I'll build it locally and peruse.

[AndyGauge]

duh, there's crate badges right above the recipes. That should be instructive enough. I've peeked at it and from 30000 ft it looks good.

[pickfire]

@AndyGauge I think the notable changes are index.hbs, the google analytics were removed I guess. Not sure if we need it? For me, I cannot see it, not really transparent so I guess it won't be useful for anyone except those that have access. I wonder why those data are not open sourced?

[pickfire]

@AndyGauge What should I do next for this?

[AndyGauge]

I'm going to try and get it compiled and uploaded to review it in book format next.

[AndyGauge]

OK, I've published it here http://www.yetanother.site/rust-cookbook/ and am reviewing

[AndyGauge]

OK, so I'm now seeing new errors... it looks like error-chain does not like its result type being ignored.

error[E0107]: wrong number of type arguments: expected 2, found 1
--> /tmp/rust-skeptic.HOf7zmrK9Y0r/test.rs:12:14
|
12 | fn main() -> Result<()> {
| ^^^^^^^^^^ expected 2 type arguments
error: aborting due to 2 previous errors
For more information about this error, try rustc --explain E0107.
test about_sect_a_note_about_error_handling_line_150 ... FAILED
error: cannot find macro error_chain_processing in this scope
--> /tmp/rust-skeptic.qfSON6UfVh6g/test.rs:6:1
|
6 | / error_chain! {
7 | | foreign_links {
8 | | Utf8(std::str::Utf8Error);
9 | | AddrParse(std::net::AddrParseError);
10 | | }
11 | | }
| |_^

[AndyGauge]

Result is a type that is defined from the error-chain! macro, I'm not sure yet why this is happening. When I tested creating a new program from http://www.yetanother.site/rust-cookbook/compression/tar.html#decompress-a-tarball-while-removing-a-prefix-from-the-paths it compiled without errors.

[AndyGauge]

In order to make Travis useful, I had to fix #569 to figure out what errors are caused by this change.

[AndyGauge]

OK, here's the problem. error-chain never was updated for Rust 2018 🤕 . Now I can do that, but it looks like here rust-lang/rust#57013 the way to fix error-chain for now is to use all of the internal macros.

use error_chain::{error_chain, error_chain_processing, impl_error_chain_kind, impl_error_chain_processed, impl_extract_backtrace, ChainedError};

[pickfire]

Is this fix supposed to be in the 2018 edition branch? saw the comment too late.

By the way, is error_chain still valid for 2018 edition? Isn't something like anyhow suits better now?

[AndyGauge]

It is really hard to come up with consensus on error handling. I'm biased, because I maintain error-chain (picked up both projects after Brian left Mozilla). I think I would use thiserror in my own library at this point though. Feel free to address error-handling in #502 or #370
The primary reason we don't switch crates is there is no ecosystem stability right now. The cookbook is all about curated, stable libraries that the library team originally approved. Adding crates to the list should be a hard thing. In fact if you want to showcase anyhow as a recipe I'd probably approve it, and throw a thiserror in there too, but for blanket switching all recipes I think that would give me an aneurysm.

[pickfire]

@AndyGauge What should I do for this pull request?

[AndyGauge]

We've discovered a major pain point using error-chain with 2018. Either we need to use the internal macros, fix error-chain, or change the error handling library. I believe I wrote those in order of complexity.

I doubt I will be working on this error-chain change immediately, but I think that would be a good solution. If you would rather rewrite the error handling story of the cookbook let me know if you have that capacity.

[AndyGauge]

Interestingly I discovered that error-chain 0.12 included the 2018 fix. cargo downloads both error-chain 0.11 and 0.12, and incorrectly was using the 0.11 version.

I feel like this is a skeptic problem.

I just recompiled this branch with rustc 1.45-nightly and had every single test fail.

[AndyGauge]

OK, let's party like its 2018!

[pickfire]

I doubt I will be working on this error-chain change immediately, but I think that would be a good solution. If you would rather rewrite the error handling story of the cookbook let me know if you have that capacity.

Yes, I could rewrite the rust error handling story to use anyhow or thiserror.

Also, I would like change the global data story to use once_cell.

But I may not have time recently but should have some time to work this out in few weeks.

[AndyGauge]

Turns out error chain was updated and the problem was with the dependency graph. At this time we shouldnt rewrite the error handling. Thanks!

…

On Sun, May 31, 2020, 6:26 PM Ivan Tham ***@***.***> wrote: I doubt I will be working on this error-chain change immediately, but I think that would be a good solution. If you would rather rewrite the error handling story of the cookbook let me know if you have that capacity. Yes, I could rewrite the rust error handling story to use anyhow or thiserror. Also, I would like change the global data story to use once_cell. But I may not have time recently but should have some time to work this out in few weeks. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#565 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABRZBXXCHJJNUCSL5ENULS3RUL7VZANCNFSM4J43T6RA> .

[pickfire]

How about lazy_static? once_cell looks like a better alternative without using macro. https://docs.rs/once_cell/1.4.0/once_cell/#faq

[AndyGauge]

Funny story. @matklad was helping me with a pre-rfc when once_cell was born. https://internals.rust-lang.org/t/pre-rfc-lazy-static-move-to-std/7993/36 <https://internals.rust-lang.org/t/pre-rfc-lazy-static-move-to-std/7993/36> I’m fine with a recipe on it. How about highlighting the regex use case? I know @burtsushi describes that as a big part of using either of these, and creating a regex is a good introductory problem. Like https://docs.rs/once_cell/1.4.0/once_cell/#building-block <https://docs.rs/once_cell/1.4.0/once_cell/#building-block> without creating a macro? Andrew

…

On May 31, 2020, at 8:23 PM, Ivan Tham ***@***.***> wrote: How about lazy_static? once_cell looks like a better alternative without using macro. https://docs.rs/once_cell/1.4.0/once_cell/#faq <https://docs.rs/once_cell/1.4.0/once_cell/#faq> — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#565 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABRZBXTPZJUYGA4XNFN5P2TRUMNMBANCNFSM4J43T6RA>.

[pickfire]

I’m fine with a recipe on it. How about highlighting the regex use case? I know @burtsushi describes that as a big part of using either of these, and creating a regex is a good introductory problem. Like https://docs.rs/once_cell/1.4.0/once_cell/#building-block https://docs.rs/once_cell/1.4.0/once_cell/#building-block without creating a macro?

https://docs.rs/once_cell/1.4.0/once_cell/#building-block is creating a macro itself and regex already uses lazy_static, we would have to replace it with once_cell and can also explain the benefits of using once_cell such that one could do lazy initialization without macro.