Add rustc-docs as a component
Previously it was listed as a package but wasn't available in the component
lists in rustup, so wasn't actually installable.
rustc-docs is also only present for x86_64-unknown-linux-gnu. Eventually it'll
also be shipped for aarch64-gnu with current CI configuration, but that builder
isn't quite up and running yet.
We probably want to ship compiler docs for other platforms as well, though, but
this commit doesn't enable that quite yet. A future PR may do so by adding
--enable-compiler-docs to the relevant builders (but it would also need to
decide the set of builders which we'd ship on).
r? @matthiaskrgr
Add sanitizer support on FreeBSD
Restarting #47337. Everything is better now, no more weird llvm problems, well not everything:
Unfortunately, the sanitizers don't have proper support for versioned symbols (https://github.com/google/sanitizers/issues/628), so `libc`'s usage of `stat@FBSD_1.0` and so on explodes, e.g. in calling `std::fs::metadata`.
Building std (now easy thanks to cargo `-Zbuild-std`) and libc with `freebsd12/13` config via the `LIBC_CI=1` env variable is a good workaround…
```
LIBC_CI=1 RUSTFLAGS="-Z sanitizer=address" cargo +san-test -Zbuild-std run --target x86_64-unknown-freebsd --verbose
```
…*except* std won't build because there's no `st_lspare` in the ino64 version of the struct, so an std patch is required:
```diff
--- i/src/libstd/os/freebsd/fs.rs
+++ w/src/libstd/os/freebsd/fs.rs
@@ -66,8 +66,6 @@ pub trait MetadataExt {
fn st_flags(&self) -> u32;
#[stable(feature = "metadata_ext2", since = "1.8.0")]
fn st_gen(&self) -> u32;
- #[stable(feature = "metadata_ext2", since = "1.8.0")]
- fn st_lspare(&self) -> u32;
}
#[stable(feature = "metadata_ext", since = "1.1.0")]
@@ -136,7 +134,4 @@ impl MetadataExt for Metadata {
fn st_flags(&self) -> u32 {
self.as_inner().as_inner().st_flags as u32
}
- fn st_lspare(&self) -> u32 {
- self.as_inner().as_inner().st_lspare as u32
- }
}
```
I guess std could like.. detect that `libc` isn't built for the old ABI, and replace the implementation of `st_lspare` with a panic?
Previously it was listed as a package but wasn't available in the component
lists in rustup, so wasn't actually installable.
rustc-docs is also only present for x86_64-unknown-linux-gnu. Eventually it'll
also be shipped for aarch64-gnu with current CI configuration, but that builder
isn't quite up and running yet.
We probably want to ship compiler docs for other platforms as well, though, but
this commit doesn't enable that quite yet. A future PR may do so by adding
--enable-compiler-docs to the relevant builders (but it would also need to
decide the set of builders which we'd ship on).
merge `as_local_hir_id` with `local_def_id_to_hir_id`
`as_local_hir_id` was defined as just calling `local_def_id_to_hir_id` and I think that having two different ways to call the same method is somewhat confusing.
Don't really care about which of these 2 methods we want to keep.
Does this require an MCP, considering that these methods are fairly frequently used?
Move platform support to the rustc book.
This moves the [Platform Support](https://forge.rust-lang.org/release/platform-support.html) page from the forge to the rustc book. There are several reasons for doing this:
* The forge is not really oriented towards end-users (it mostly contains infrastructure, governance and policy, internal team pages, etc.). This platform support page is useful to user to know which targets are supported.
* This page can now be updated in-sync with any PRs that add or remove a target, or change its status.
* This is now automatically checked on CI to verify the list does not get out of sync. Currently it only checks the presence/absence of an entry, but more sophisticated checks could be added in the future.
I'm not 100% certain this is the best location, but I think it fits. I'd like to see the rustc guide continue to grow, including things like linking information and more platform-specific details.
Update cargo
7 commits in 1653f354644834073d6d2541e27fae94588e685e..ab32ee88dade1b50c77347599e82ca2de3fb8a51
2020-08-04 23:14:37 +0000 to 2020-08-10 17:44:43 +0000
- Build manpage archive deterministically (rust-lang/cargo#8600)
- doc: Qualify GNU licenses in example license field (rust-lang/cargo#8604)
- Fix jobserver_exists test on single-cpu systems (rust-lang/cargo#8598)
- Fix small typo in reference/profiles.md (rust-lang/cargo#8605)
- Default cargo publish to the alt registry if it's the only allowed one (rust-lang/cargo#8571)
- cargo install with specific yanked version gives confusing "not found" error (rust-lang/cargo#8565)
- Fix typo (rust-lang/cargo#8589)
Rollup of 9 pull requests
Successful merges:
- #74521 (older toolchains not valid anymore)
- #74960 (Fix regionck failure when converting Index to IndexMut)
- #75234 (Update asm! documentation in unstable book)
- #75368 (Move to doc links inside the prelude)
- #75371 (Move to doc links inside std/time.rs)
- #75394 (Add a function to `TyCtxt` for computing an `Allocation` for a `static` item's initializer)
- #75395 (Switch to intra-doc links in library/std/src/os/*/fs.rs)
- #75422 (Accept more safety comments)
- #75424 (fix wrong word in documentation)
Failed merges:
r? @ghost
Accept more safety comments
This accepts more `// SAFETY:` comments from `tidy`.
This is done after the current behaviour of requiring text one the same line (because spaces are stripped so the last space never pass if there is no text on the same line) bit me once more in #75066
This could potentially accept empty `// SAFETY:` comments but `tidy` is an internal tool used only here so my reasoning is reviews will catch those.
Miri: Renamed "undef" to "uninit"
Renamed remaining references to "undef" to "uninit" when referring to Miri.
Impacted directories are:
- `src/librustc_codegen_llvm/consts.rs`
- `src/librustc_middle/mir/interpret/`
- `src/librustc_middle/ty/print/pretty.rs`
- `src/librustc_mir/`
- `src/tools/clippy/clippy_lints/src/consts.rs`
Upon building Miri based on the new changes it was verified that no changes needed to be made with the Miri project.
Related issue #71193
Renamed remaining references to "undef" to "uninit" when referring to Miri.
Impacted directories are:
- src/librustc_codegen_llvm/consts.rs
- src/librustc_middle/mir/interpret/
- src/librustc_middle/ty/print/pretty.rs
- src/librustc_mir/
- src/tools/clippy/clippy_lints/src/consts.rs
Upon building Miri based on the new changes it was verified that no changes needed to be made with the Miri project.
Related issue #71193
By moving `{known,used}_attrs` from `SessionGlobals` to `Session`. This
means they are accessed via the `Session`, rather than via TLS. A few
`Attr` methods and `librustc_ast` functions are now methods of
`Session`.
All of this required passing a `Session` to lots of functions that didn't
already have one. Some of these functions also had arguments removed, because
those arguments could be accessed directly via the `Session` argument.
`contains_feature_attr()` was dead, and is removed.
Some functions were moved from `librustc_ast` elsewhere because they now need
to access `Session`, which isn't available in that crate.
- `entry_point_type()` --> `librustc_builtin_macros`
- `global_allocator_spans()` --> `librustc_metadata`
- `is_proc_macro_attr()` --> `Session`
Check whether locals are too large instead of whether accesses into them are too large
Essentially this stops const prop from attempting to optimize
```rust
let mut x = [0_u8; 5000];
x[42] = 3;
```
I don't expect this to be a perf improvement without #73656 (which is also where the lack of this PR will be a perf regression).
r? @wesleywiser
rustc_ast: Stop using "string typing" for doc comment tokens
Explicitly store their kind and style retrieved during lexing in the `token::DocComment`.
Also don't "beautify" doc comments before converting them to `#[doc]` attributes when passing them to macros (both declarative and procedural).
The trimming of empty lines, lines containing only `*`s, etc is purely a rustdoc's job as a part of its presentation of doc strings to users, rustc must not do this and must pass tokens as precisely as possible internally.
