rustdoc: add flag to control the html_root_url of dependencies
The `--extern-html-root-url` flag in this PR allows one to override links to crates whose docs are not already available locally in the doc bundle. Docs.rs currently uses a version of this to make sure links to other crates go into that crate's docs.rs page. See the included test for intended use, but the idea is as follows:
Calling rustdoc with `--extern-html-root-url crate=https://some-url.com` will cause rustdoc to override links that point to that crate to instead be replaced with a link rooted at `https://some-url.com/`. (e.g. for docs.rs this would be `https://docs.rs/crate/0.1.0` or the like.) Cheekily, rustup could use these options to redirect links to std/core/etc to instead point to locally-downloaded docs, if it so desired.
Fixes https://github.com/rust-lang/rust/issues/19603
Fix promotion stability hole in old borrowck
r? @nikomatsakis
I screwed up the promotion stability checks. Big time. They were basically nonexistant. We had tests for it. I also screwed up said tests. This is in stable already :(
Basically stability checks of promotion only worked if you tried to use a const fn defined in the same crate.
cc @eddyb
Rollup of 20 pull requests
Successful merges:
- #51760 (Add another PartialEq example)
- #53113 (Add example for Cow)
- #53129 (remove `let x = baz` which was obscuring the real error)
- #53389 (document effect of join on memory ordering)
- #53472 (Use FxHash{Map,Set} instead of the default Hash{Map,Set} everywhere in rustc.)
- #53476 (Add partialeq implementation for TryFromIntError type)
- #53513 (Force-inline `shallow_resolve` at its hottest call site.)
- #53655 (set applicability)
- #53702 (Fix stabilisation version for macro_vis_matcher.)
- #53727 (Do not suggest dereferencing in macro)
- #53732 (save-analysis: Differentiate foreign functions and statics.)
- #53740 (add llvm-readobj to llvm-tools-preview)
- #53743 (fix a typo: taget_env -> target_env)
- #53747 (Rustdoc fixes)
- #53753 (expand keep-stage --help text)
- #53756 (Fix typo in comment)
- #53768 (move file-extension based .gitignore down to src/)
- #53785 (Fix a comment in src/libcore/slice/mod.rs)
- #53786 (Replace usages of 'bad_style' with 'nonstandard_style'.)
- #53806 (Fix UI issues on Implementations on Foreign types)
Failed merges:
r? @ghost
Miri refactor: Final round
Tying up some loose ends that I noticed in the previous PRs -- and finally getting argument passing into a shape where @eddyb says it is "okay", which is a big improvement over the previous verdict that I cannot quote in public. ;)
Also move a bunch of useful helpers to construct `Scalar` from miri to here.
Cc @eddyb
r? @oli-obk
rustbuild: Distribute libLLVM.so with rustc
A recent change (#53245) started to build LLVM with ThinLTO enabled and to
ensure that compile times are kept down it builds LLVM dynamically by default to
ensure that all the various LLVM tools aren't redoing all that optimization
work. This means, however, that all LLVM tools depend on LLVM's dynamic library
by default.
While the LLVM tools and LLDB components were updated to include the shared
library we accidentally forgot about LLD, included with the main rustc
component. LLD also links dynamically to LLVM and ships a non-working binary
right now because of this!
This commit updates our distribution to ship the LLVM dynamic library with the
compiler libraries. While not technically needed for rustc itself to operate
(right now) it may be needed for LLD, and otherwise it serves as a good basis
for the other LLVM tools components to work with as well.
This should...
Closes#53813
move file-extension based .gitignore down to src/
Currently, it for example ignores `*.rlib` files in the repository root -- which I think is wrong; I sometimes get these files when I call rustc directly and I do want them cleaned up, not ignored. No such files are created during the normal build process.
fix a typo: taget_env -> target_env
This typo was introduced in https://github.com/rust-lang/rust/pull/47334. A couple tests bitrotted as a result, so we fix those too, and move them to a more sensible place.
Is there some lint we could turn on that would've caught this? It's a drag that cfg typos can silently pass through the compiler.
add llvm-readobj to llvm-tools-preview
Similar to readelf but supports more object formats (it seems). Particularly useful to inspect in detail sections (e.g. their flags) and symbols (e.g. their types).
r? @alexcrichton
cc @dvc94ch
Use FxHash{Map,Set} instead of the default Hash{Map,Set} everywhere in rustc.
Most of the compiler uses the `Fx` hasher but some places ended up with the default one.
Fix manifests for broken tools: take 2
This is a follow up of #53715, to avoid stripping unavailable components from the extensions list. This time I also figured out how to test the changes, so the produced manifest is correct.
Along with the fix I added a README with instructions on how to test the tool, and a new `BUILD_MANIFEST_DISABLE_SIGNING` env var to avoid dealing with gpg while testing the tool. I chose an env var instead of a flag because it's more difficult to have it slip in by accident on CI, and there is also another protection that panics if that env var is set on CI, just to be sure we don't release unsigned artifacts.
r? @alexcrichton
cc https://github.com/rust-lang-nursery/rustup.rs/issues/1486
A recent change (#53245) started to build LLVM with ThinLTO enabled and to
ensure that compile times are kept down it builds LLVM dynamically by default to
ensure that all the various LLVM tools aren't redoing all that optimization
work. This means, however, that all LLVM tools depend on LLVM's dynamic library
by default.
While the LLVM tools and LLDB components were updated to include the shared
library we accidentally forgot about LLD, included with the main rustc
component. LLD also links dynamically to LLVM and ships a non-working binary
right now because of this!
This commit updates our distribution to ship the LLVM dynamic library with the
compiler libraries. While not technically needed for rustc itself to operate
(right now) it may be needed for LLD, and otherwise it serves as a good basis
for the other LLVM tools components to work with as well.
This should...
Closes#53813
