Switch rustdoc to Rust 2021

[camelid]

Closes #89074. 🎉

[rust-highfive]

rustdoc-json-types is a public (although nightly-only) API. Consider changing src/librustdoc/json/conversions.rs instead; otherwise, make sure you update format_version.

cc @CraftSpider,@aDotInTheVoid

[rust-highfive]

r? @GuillaumeGomez

(rust-highfive has picked a reviewer for you, use r? to override)

[camelid]

cc @rust-lang/rustdoc

[camelid]

My process for making this change was as follows:

1. Run RUSTFLAGS='-D rust-2021-compatibility' x build with download-rustc enabled, so it only built rustdoc.
2. Apply the sole suggestion it gave (ecc041d).
3. Change edition = "2018" to edition = "2021".
4. Run x build again. The build completed successfully.

(And now CI is running tests.)

I didn't use cargo fix --edition because I don't know if there's a way to run it in rust-lang/rust given that we use rustbuild.

[camelid]

I don't think we need to wait on the compiler being switched to Rust 2021 because editions are supposed to allow you to use crates with other editions :)

[camelid]

Looks like I'll need to update tidy 😆

[camelid]

I made the change to tidy in this PR since it's very small and is a blocker, but let me know if you'd rather that I open a separate PR for it.

[camelid]

Only remaining decision point is #89075 (comment), and then I think this should be good to merge!

[Mark-Simulacrum]

I think I would prefer to hold this (it doesn't seem that pressing) until I finish up the migration work with bootstrap. I'll likely cherry pick some of your work at least, but I want to make sure we don't mark crates with 2021 if we haven't verified them as OK with the compatibility lint.

I'd also like to follow-up with the rfc 2229 group about the insignificant dtor - #89075 (comment) - because I don't think we should be linting at all in that case. Of course, it's not necessary to block landing migrations on those fixes, but it also seems like we do not gain anything significant from pushing this forward quickly? And we'd get some additional testing if we hold off a little.

[camelid]

Sure, it's not that pressing, but I figured it'd be another way to test the edition. I'm happy to drop the change to rustdoc-themes; all of the other changes I tested with RUSTFLAGS='-D rust-2021-compatibility' before updating the edition field. But I'm also happy to wait for your bootstrap changes if you'd rather do that first.

I'd also like to follow-up with the rfc 2229 group about the insignificant dtor - #89075 (comment) - because I don't think we should be linting at all in that case.

The root variable (config) is of type LangString, which doesn't seem to implement Drop. However, one of the captured fields is a Vec, so maybe that's why it's triggering?

[camelid]

I'd also like to follow-up with the rfc 2229 group about the insignificant dtor - #89075 (comment) - because I don't think we should be linting at all in that case. Of course, it's not necessary to block landing migrations on those fixes, but it also seems like we do not gain anything significant from pushing this forward quickly? And we'd get some additional testing if we hold off a little.

This is the full error in case it's useful to the WG (in this case, I ran rustc with edition set to 2021, but the error looks the same as when I used edition = "2018"):

error: changes to closure capture in Rust 2021 will affect drop order
    --> src/librustdoc/doctest.rs:966:46
     |
966  |             testfn: test::DynTestFn(Box::new(move || {
     |                                              ^^^^^^^
...
975  |                     config.should_panic,
     |                     ------------------- in Rust 2018, this closure captures all of `config`, but in Rust 2021, it will only capture `config.should_panic`
976  |                     no_run,
977  |                     config.test_harness,
     |                     ------------------- in Rust 2018, this closure captures all of `config`, but in Rust 2021, it will only capture `config.test_harness`
...
981  |                     config.compile_fail,
     |                     ------------------- in Rust 2018, this closure captures all of `config`, but in Rust 2021, it will only capture `config.compile_fail`
982  |                     config.error_codes,
     |                     ------------------ in Rust 2018, this closure captures all of `config`, but in Rust 2021, it will only capture `config.error_codes`
...
1050 |     }
     |     -
     |     |
     |     in Rust 2018, `config` is dropped here, but in Rust 2021, only `config.should_panic` will be dropped here as part of the closure
     |     in Rust 2018, `config` is dropped here, but in Rust 2021, only `config.test_harness` will be dropped here as part of the closure
     |     in Rust 2018, `config` is dropped here, but in Rust 2021, only `config.compile_fail` will be dropped here as part of the closure
     |     in Rust 2018, `config` is dropped here, but in Rust 2021, only `config.error_codes` will be dropped here as part of the closure
     |
     = note: `-D rust-2021-incompatible-closure-captures` implied by `-D rust-2021-compatibility`
     = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/disjoint-capture-in-closures.html>
help: add a dummy let to cause `config` to be fully captured
     |
966  ~             testfn: test::DynTestFn(Box::new(move || {
967  +                 let _ = &config;
     |

[Mark-Simulacrum]

I've filed #89080 to track the specific case we're seeing here.

Sure, it's not that pressing, but I figured it'd be another way to test the edition

For sure! I expect we'll get this merged by the end of the week at the latest, so I don't think it loses us much - I think migrating the crates deps first will also help us test more than the leaves first approach, fwiw. (Since we get far more testing of leaves in e.g. crater runs, but partial migrations of dependencies are less visible).

[camelid]

Sounds good! :)

[Mark-Simulacrum]

OK, I talked to @arora-aman and it looks like we never finalized the insignificant destructor work by actually applying the attributes to std -- a PR doing that should be forthcoming shortly.

I think it probably makes sense to not try to one off migrate individual crates in the tree -- it'll generate more PRs and ultimately feels like it'll be more hassle than just rolling everything into one PR (which migrates everything except the library/ crates, as there's currently a bug with the panic macro edition handling -- we can't migrate libcore at least yet).

I've posted #89103 to replace this PR -- that rolls in an update to 2021 across almost all in-tree crates.

[bors]

☔ The latest upstream changes (presumably #89103) made this pull request unmergeable. Please resolve the merge conflicts.

[camelid]

Closing now that #89103 has been merged.