Fixes footnote handling in rustdoc
Fixes#100638.
You can now declare footnotes like this:
```rust
//! Reference to footnotes A[^1], B[^2] and C[^3].
//!
//! [^1]: Footnote A.
//! [^2]: Footnote B.
//! [^3]: Footnote C.
```
r? `@notriddle`
Move UI issue tests to subdirectories
I've moved issue tests numbered 1920, 3668, 5997, 23302, 32122, 40510, 57741, 71676, and 76077 to relevant better-named subdirectories (tracking issue #73494). The issues were chosen by having the highest number of files per issue.
I adjusted the `ISSUES_ENTRY_LIMIT` because `tidy` was shouting at me.
raw pointer metadata API: data address -> data pointer
A pointer consists of [more than just an address](https://github.com/rust-lang/rfcs/pull/3559), so let's not equate "pointer" and "address" in these docs.
Add instructions of how to use pre-vendored 'rustc-src'
This PR closes#110163.
I had to move the URL to the left, making it not aligned as it is three lines above, but the tidy check would yell at me otherwise. If that's not acceptable, I'd love some suggestions on how to make it better.
One question: in the original issue (https://github.com/rust-lang/rust/issues/110163#issuecomment-1502647562), it was suggested to mention how to download specific commit tarballs; however, it was said it's not documented anywhere, so I did not include that yet. If there is a want to have that, I'd gladly amend the commit.
Make the coroutine def id of an async closure the child of the closure def id
Adjust def collection to make the (inner) coroutine returned by an async closure be a def id child of the (outer) closure. This makes it easy to map from coroutine -> closure by using `tcx.parent`, since currently it's not trivial to do this.
rustdoc: Prevent JS injection from localStorage
It turns out that you can execute arbitrary JavaScript on the rustdocs settings page. Here's how:
1. Open `settings.html` on a rustdocs site.
2. Set "preferred light theme" to "dark" to initialize the corresponding localStorage value.
3. Plant a payload by executing this in your browser's dev console: ``Object.keys(localStorage).forEach(key=>localStorage.setItem(key,`javascript:alert()//*/javascript:javascript:"/*'/*\`/*--></noscript></title></textarea></style></template></noembed></script><html " onmouseover=/*<svg/*/onload=alert()onload=alert()//><svg onload=alert()><svg onload=alert()>*/</style><script>alert()</script><style>`));``
4. Refresh the page -- you should see an alert.
This could be particularly dangerous if rustdocs are deployed on a domain hosting some other application. Malicious code could circumvent `same-origin` policies and do mischievous things with user data.
This change ensures that only defined themes can actually be selected (arbitrary strings from localStorage will not be written to the document), and for good measure sanitizes the theme name.
Because it's almost always static.
This makes `impl IntoDiagnosticArg for DiagnosticArgValue` trivial,
which is nice.
There are a few diagnostics constructed in
`compiler/rustc_mir_build/src/check_unsafety.rs` and
`compiler/rustc_mir_transform/src/errors.rs` that now need symbols
converted to `String` with `to_string` instead of `&str` with `as_str`,
but that' no big deal, and worth it for the simplifications elsewhere.
only assemble alias bound candidates for rigid aliases
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/77
This also causes `<Wrapper<?0> as Trait>::Unwrap: Trait` to always be ambig, as we now normalize the self type before checking whether it is an inference variable.
I cannot think of an approach to the underlying issues here which does not require the "may-define means must-define" restriction for opaque types. Going to go ahead with this and added this restriction to the tracking issue for the new solver to make sure we don't stabilize it without getting types + lang signoff here.
r? `@compiler-errors`
Handle out of memory errors in io:Read::read_to_end()
#116570 got stuck due to a [procedural confusion](https://github.com/rust-lang/rust/pull/116570#issuecomment-1768271068). Retrying so that it can get FCP with the proper team now. cc `@joshtriplett` `@BurntSushi`
----
I'd like to propose handling of out-of-memory errors in the default implementation of `io::Read::read_to_end()` and `fs::read()`. These methods create/grow a `Vec` with a size that is external to the program, and could be arbitrarily large.
Due to being I/O methods, they can already fail in a variety of ways, in theory even including `ENOMEM` from the OS too, so another failure case should not surprise anyone.
While this may not help much Linux with overcommit, it's useful for other platforms like WASM. [Internals thread](https://internals.rust-lang.org/t/io-read-read-to-end-should-handle-oom/19662).
I've added documentation that makes it explicit that the OOM handling is a nice-to-have, and not a guarantee of the trait.
I haven't changed the implementation of `impl Read for &[u8]` and `VecDeque` out of caution, because in these cases users could assume `read` can't fail.
This code uses `try_reserve()` + `extend_from_slice()` which is optimized since #117503.
Issue tests numbered 1920, 3668, 5997, 23302, 32122, 40510, 57741, 71676, and 76077 were moved to relevant better-named subdirectories. ISSUES_ENTRY_LIMIT was adjusted to match new number of files and FIXME note was expanded.
Avoid ICE in trait without `dyn` lint
Do not attempt to provide an accurate suggestion for `impl Trait` in bare trait types when linting. Instead, only do the object safety check when an E0782 is already going to be emitted in the 2021 edition.
Fix#120241.
The test was using an internal feature which doesn't really matter, but
more importantly, we're now fatally exiting after the duplicate lang
item, so this tests nothing.
Do not attempt to provide an accurate suggestion for `impl Trait`
in bare trait types when linting. Instead, only do the object
safety check when an E0782 is already going to be emitted in the
2021 edition.
Fix#120241.
