This commit switches the `--enable-extended` option on the arm-related
dist builders to `--enable-full-tools`. This alias in `config.py`
corresponds to enabling a few more options:
* `rust.lld = true` - this is the main purpose of this PR, to enable LLD
on ARM-related platforms. This means it will effectively unlock
compilation of wasm programs from an arm host.
* `rust.llvm-tools = true` - it turns out that this option is largely
ignored in rustbuild today. This is only read in one location to set
some flags for the `llvm-tools` package, but the `llvm-tools` package
is already produced on all of these builders. It's predicted that this
will have no effect on build times.
* `rust.codegen-backends = ['llvm']` - historically this also enabled
the emscripten backend, but that has long since been removed.
This brings the ARM dist builders in line with the x86_64 dist builders
using this flag. The hope is that the extra time spent on CI building
LLD will acceptable because it's cached by `sccache`, LLD is a
relatively small C++ project, and the dist builders are all clocking
well under 3 hours (the slowest of all builders) around 2 hours.
There's likely some possible cleanup that can happen with these
configure options since it doesn't look like they've aged too too well,
but I'm hopeful that possible refactorings, if necessary, could be
deferred to future PRs.
Fix doc links
This fixes a few doc links which were causing `cargo doc` to fail when using `--document-private-items --document-hidden-items` on libstd. Most of the fixes are just escaping '[' and ']' characters in doc comments, and one change actually fixes a doc link.
Only use read_unaligned in transmute_copy if necessary
I've noticed that this causes LLVM to generate poor code on targets that don't support unaligned memory accesses.
Check code blocks tags
Fixes#71347.
Explanations here: I realized recently that it was a common issue to confuse/misspell tags on code blocks. This is actually quite a big issue since it generally ends up in a code blocks being ignored since it's not being considered as a rust one. With this new warning, users will at least be notified about it.
PS: some improvements can be done on the error rendering but considering how big the PR already is, I think it's better to do it afterwards.
r? @ollie27
cc @rust-lang/rustdoc
Don't fuse Chain in its second iterator
Only the "first" iterator is actually set `None` when exhausted,
depending on whether you iterate forward or backward. This restores
behavior similar to the former `ChainState`, where it would transition
from `Both` to `Front`/`Back` and only continue from that side.
However, if you mix directions, then this may still set both sides to
`None`, totally fusing the iterator.
Fixes#71375
r? @scottmcm
Confusing suggestion on incorrect closing `}`
Compiler returns
```
error: unexpected closing delimiter: `}`
--> main.rs:20:1
|
9 | ErrorHandled::Reported => {}
| -- this block is empty, you might have not meant to close it temp
...
20 | }
| ^ unexpected closing delimiter
error: aborting due to previous error
```
This was needed by an early version of dataflow-based const
qualification where `QualifCursor` needed to return a full `BitSet` with
the current state.
Improve E0308 error message wording again
Hello again,
I recently did this PR: #70242
I felt the error message could be further improved, so I made [a post on the Rust community forum](https://users.rust-lang.org/t/looking-for-feedback-on-an-improved-error-message-for-e0308/40004) to ask for feedback.
(Also, there were some comments on my original PR that I took into consideration as well.)
This PR is my attempt to take all the feedback into account and propose a better and simplified error message that should still be accurate. Its main benefit is having simpler grammar, and hopefully being easier to read and understand.
Thanks to everyone who commented and gave feedback, and thank you for taking a look at this PR.
