Playground links from code blocks in books need to obey edition2018 flag #58491
Comments
Centril
added
C-bug
|
This is probably due to compiling the test with Rust 2015; it works on Rust 2018. cc @scottmcm |
|
It definitely works in 2018: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=e2ca081a42124a7615dd542c3cc36324 See also the run-pass test for it: https://github.com/rust-lang/rust/blob/master/src/test/run-pass/try-block.rs It was originally marked ignore because of needing 2018 (https://github.com/rust-lang/rust/blob/master/src/test/run-pass/try-block.rs), but was changed to run in 2018 when #54350 made that possible. So I don't think there's a bug here. |
|
@scottmcm The bug is in the unstable book linking the user towards a 2015 playground instead of a 2018 one. |
scottmcm
added
T-rustdoc
scottmcm
changed the title
|
@Centril Ok, renamed the issue and changed the flags. This isn't a testsuite problem, then. |
|
@scottmcm good call :) cc @steveklabnik |
|
Related: rust-lang/mdBook#812 |
Add a note about 2018e if someone uses `try {` in 2015e
Inspired by rust-lang#58491, where a `try_blocks` example was accidentally run in 2015, which of course produces a bunch of errors.
What's the philosophy about gating for this? The keyword is stably a keyword in 2018, so I haven't gated it for now but am not mentioning what the keyword _does_. Let me know if I should do differently.
|
I need to use 2018 features in an MD book I'm creating. It looks like this is a fresh issue, so I assume nobody has had a chance to deal with it yet. In the meantime, is there any work-around I can use? I took a naive shot at changing a local copy of mdBook. In src/theme/book.js, I changed the url that (I think) runs the code to
That didn't seem to help any. Any other suggestions? |
Add a note about 2018e if someone uses `try {` in 2015e
Inspired by rust-lang#58491, where a `try_blocks` example was accidentally run in 2015, which of course produces a bunch of errors.
What's the philosophy about gating for this? The keyword is stably a keyword in 2018, so I haven't gated it for now but am not mentioning what the keyword _does_. Let me know if I should do differently.
Add a note about 2018e if someone uses `try {` in 2015e
Inspired by rust-lang#58491, where a `try_blocks` example was accidentally run in 2015, which of course produces a bunch of errors.
What's the philosophy about gating for this? The keyword is stably a keyword in 2018, so I haven't gated it for now but am not mentioning what the keyword _does_. Let me know if I should do differently.
Add a note about 2018e if someone uses `try {` in 2015e
Inspired by rust-lang#58491, where a `try_blocks` example was accidentally run in 2015, which of course produces a bunch of errors.
What's the philosophy about gating for this? The keyword is stably a keyword in 2018, so I haven't gated it for now but am not mentioning what the keyword _does_. Let me know if I should do differently.
Resolves rust-lang#53672
Add a note about 2018e if someone uses `try {` in 2015e
Inspired by rust-lang#58491, where a `try_blocks` example was accidentally run in 2015, which of course produces a bunch of errors.
What's the philosophy about gating for this? The keyword is stably a keyword in 2018, so I haven't gated it for now but am not mentioning what the keyword _does_. Let me know if I should do differently.
Resolves rust-lang#53672
|
This is fixed in beta (1.37) via rust-lang/mdBook#946. |
EDIT: The error here is actually from clicking the playground link, not that there's a problem with the code, or how the book's testpass is running. Original description follows.
It seems that
#![feature(try_blocks)]is not worked now.link: https://doc.rust-lang.org/unstable-book/language-features/try-blocks.html
The text was updated successfully, but these errors were encountered: