Move to intra-doc links for /library/core/src/any.rs
Helps with #75080.
@rustbot modify labels: T-doc, A-intra-doc-links, T-rustdoc
Known issues:
* Links from `core` to `std` (#74481):
* `[Box]: ../../std/boxed/struct.Box.html`
Move CloudABI to tier 3.
The CloudABI target hasn't had much work done on it in a while, and it doesn't appear to be in active use. It has a fairly substantial amount of code, particularly in the [sys module](5addb135ed/library/std/src/sys/cloudabi) that requires actively supporting. I contacted @EdSchouten who indicated that many of the CloudABI concepts are now in WASI, and that they are OK with the target being moved to tier 3.
Rollup of 10 pull requests
Successful merges:
- #74204 (Don't visit foreign function bodies when lowering ast to hir)
- #74314 (rustc_typeck: construct {Closure,Generator}Substs more directly.)
- #74346 (Use LocalDefId instead of HirId for reachable_set elements.)
- #74399 (Move DelaySpanBugEmitted to ty::context)
- #75177 (Add regression test for issue-66768)
- #75223 (Add #[track_caller] to `Session::delay_span_bug`)
- #75423 (Move to intra-doc links for /library/core/src/hint.rs)
- #75485 (pin docs: add some forward references)
- #75569 (Bump minor version of emsdk to 1.38.47)
- #75596 (Switch to intra-doc links in /sys/windows/ext/{ffi,fs,process}.rs)
Failed merges:
r? @ghost
Bump minor version of emsdk to 1.38.47
Release Notes:
```
v1.38.47: 10/02/2019
--------------------
- Add support for FETCH API in WASM backend. This doesn't support FETCH in the
main thread (`USE_FETCH_WORKER=0` is enforced). #9490
- Redefine errno values to be consistent with wasi. This will let us avoid
needing to convert the values back and forth as we use more wasi APIs.
This is an ABI change, which should not be noticeable from user code
unless you use errno defines (like EAGAIN) *and* keep around binaries
compiled with an older version that you link against. In that case, you
should rebuild them. See #9545.
- Removed build option `-s ONLY_MY_CODE` as we now have much better solutions
for that, like building to a wasm object file or using `STANDALONE_WASM`
etc. (see
https://github.com/emscripten-core/emscripten/wiki/WebAssembly-Standalone).
- Emscripten now supports the config file (.emscripten) being placed in the
emscripten directory rather that the current user's home directory.
See #9543
```
Motivated by changes to errno values which are currently out of sync with those
in libc crate which uses wasi values already. Helps with #72808 and #75532.
pin docs: add some forward references
@nagisa had some questions about pinning that were answered in the docs, which they did not realize because that discussion is below the examples. I still think it makes sense to introduce the examples before that discussion, since it give the discussion something concrete to refer to, but this PR adds some forward references so people don't think the examples conclude the docs.
@nagisa do you think this would have helped?
Use LocalDefId instead of HirId for reachable_set elements.
The only `HirId`s being tracked there that don't have matching `DefId`s are local variables, and that's an accident from #44316 (where I preserved the old behavior, even if nothing relied on reachability tracking local variables).
rustc_typeck: construct {Closure,Generator}Substs more directly.
We've previously not had a way to create `{Closure,Generator}Substs` other than instantiating all generics as inference variables and unifying the inference types (extracted using the regular `{Closure,Generator}Substs` accessors), with the actual types.
With this PR, those hacks, and assumptions about the order of closure/generator-specific components, are replaced with a simple API where the base `Substs` are combined with the additional information into a `{Closure,Generator}Substs`.
This might also be faster than relying inference, although probably not by much.
r? @nikomatsakis cc #53488 @blitzerr
Don't visit foreign function bodies when lowering ast to hir
Previously the existence of bodies inside a foreign function block would
cause a panic in the hir `NodeCollector` during its collection of crate
bodies to compute a crate hash:
e59b08e62e/src/librustc_middle/hir/map/collector.rs (L154-L158)
The collector walks the hir tree and creates a map of hir nodes, then
attaching bodies in the crate to their owner in the map. For a code like
```rust
extern "C" {
fn f() {
fn g() {}
}
}
```
The crate bodies include the body of the function `g`. But foreign
functions cannot have bodies, and while the parser AST permits a foreign
function to have a body, the hir doesn't. This means that the body of
`f` is not present in the hir, and so neither is `g`. So when the
`NodeCollector` finishes the walking the hir, it has no record of `g`,
cannot find an owner for the body of `g` it sees in the crate bodies,
and blows up.
Why do the crate bodies include the body of `g`? The AST walker has a
need a for walking function bodies, and FFIs share the same AST node as
functions in other contexts.
There are at least two options to fix this:
- Don't unwrap the map entry for an hir node in the `NodeCollector`
- Modifier the ast->hir lowering visitor to ignore foreign function
blocks
I don't think the first is preferrable, since we want to know when we
can't find a body for an hir node that we thought had one (dropping this
information may lead to an invalid hash). So this commit implements the
second option.
Closes#74120
Add `TyCtxtAt::{ty_error, ty_error_with_message}`
~~Only e2d957d was added, the rest comes from #70551.~~
I was unsure where to put the implementation for those methods, please tell me if there is a better place for it.
Closes#72619, ~~blocked on #70551~~.
r? @eddyb cc @mark-i-m, maybe this should be part of #70551? If so feel free to cherry-pick or ask me to file a PR against your fork.
Add option to use the new symbol mangling in rustc/std
I don't know if this causes problems in some cases -- maybe it should be on by default for at least rustc. I've never encountered problems with it other than tools not supporting it, though.
cc @nnethercote
r? @eddyb
Move to intra doc links in std::net
Helps with #75080.
@rustbot modify labels: T-doc, A-intra-doc-links, T-rustdoc
The links for `true` and `false` had to stay else `rustdoc` complained, it is intended ?
Doc: String isn't a collection
On forums one user was confused by this text, interpreting it as saying that `String` is a `Vec<char>` literally, rather than figuratively for the purpose of collect. I've reworded that paragraph.
Switch to intra-doc links in `core::option`
Part of #75080.
I didn't change some of the links since they link into `std` and you can't link from `core` to `std` (#74481).
Also, at least one other link can't be switched to an intra-doc link because it's not supported yet (#74489).
Release Notes:
```
v1.38.47: 10/02/2019
--------------------
- Add support for FETCH API in WASM backend. This doesn't support FETCH in the
main thread (`USE_FETCH_WORKER=0` is enforced). #9490
- Redefine errno values to be consistent with wasi. This will let us avoid
needing to convert the values back and forth as we use more wasi APIs.
This is an ABI change, which should not be noticeable from user code
unless you use errno defines (like EAGAIN) *and* keep around binaries
compiled with an older version that you link against. In that case, you
should rebuild them. See #9545.
- Removed build option `-s ONLY_MY_CODE` as we now have much better solutions
for that, like building to a wasm object file or using `STANDALONE_WASM`
etc. (see
https://github.com/emscripten-core/emscripten/wiki/WebAssembly-Standalone).
- Emscripten now supports the config file (.emscripten) being placed in the
emscripten directory rather that the current user's home directory.
See #9543
```
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
