Document direct implementations on type aliases.
This improves #32077, but is not a complete fix.
For a type alias `type NewType = AliasedType`, it will include any `impl NewType` and `impl
Trait for NewType` blocks in the documentation for `NewType`.
A complete fix would include the implementations from the aliased type in the type alias' documentation, so that users have a complete picture of methods that are available on the alias. However, to do this properly would require a fix for #14072, as the alias may affect the type parameters of the type alias, making the documentation difficult to understand. (That is, for `type Result = std::result::Result<(), ()>` we would ideally show documentation for `impl Result<(), ()>`, rather than generic documentation for `impl<T, E> Result<T, E>`).
I think this improvement is worthwhile, as it exposes implementations which are not currently documented by rustdoc. The documentation for the implementations on the aliased type are still accessible by clicking through to the docs for that type. (Although perhaps it's now less obvious to the user that they should click-through to get there).
This improves #32077, but is not a complete fix. For a type alias `type
NewType = AliasedType`, it will include any `impl NewType` and `impl
Trait for NewType` blocks in the documentation for `NewType`.
A complete fix would include the implementations from the aliased type
in the type alias' documentation, so that users have a complete
picture of methods that are available on the alias. However, to do this
properly would require a fix for #14072, as the alias may affect the
type parameters of the type alias, making the documentation difficult to
understand. (That is, for `type Result = std::result::Result<(), ()>` we
would ideally show documentation for `impl Result<(), ()>`, rather than
generic documentation for `impl<T, E> Result<T, E>`).
I think this improvement is worthwhile, as it exposes implementations
which are not currently documented by rustdoc. The documentation for the
implementations on the aliased type are still accessible by clicking
through to the docs for that type. (Although perhaps it's now less
obvious to the user that they should click-through to get there).
bootstrap: improve 'build --help' by explaining what exactly the last example does
I recently found myself confused about what exactly gets built how often when I run which command; I think this would have helped me.
One thing I did not touch, but I feel could also be improved, is the wording just above: "For a quick build with a usable compile, you can pass". I am not a native speaker, but this sounds odd to me. Do you mean "For a quick build of a usable compiler" (but then it should say where the usable compiler is produced)? Or do you mean "For a quick build testing if the compiler is usable"? I can reword this, but I'd like to make sure I understand the intent of the message.
What about
```
For a quick build of a usable compiler, you can pass:
./x.py build --stage 1 src/libtest
This will first build everything once (like --stage 0 without further
arguments would), and then use the compiler built in stage 0 to build
src/libtest and its dependencies.
Once this is done, build/$ARCH/stage1 contains a usable compiler.
```
However, I am not sure this is actually true. In particular, why even bother building the libstd in stage 1? AFAIK that ends up in `build/*/stage1-std`, not in `build/*/stage1` (which is filled from `build/*/stage0-*`).
std: Avoid panics in rust_eh_personality
This commit removes a few calls to panic and/or assert in `rust_eh_personality`.
This function definitely can't itself panic (that'd probably segfault or do
something else weird) and I was also noticing that a `pub extern fn foo() {}`
cdylib was abnormally large. Turns out all that size was the panicking machinery
brought in by the personality function!
The change here is to return a `Result` internally so we can bubble up the fatal
error, eventually translating to the appropriate error code for the libunwind
ABI.
This commit removes a few calls to panic and/or assert in `rust_eh_personality`.
This function definitely can't itself panic (that'd probably segfault or do
something else weird) and I was also noticing that a `pub extern fn foo() {}`
cdylib was abnormally large. Turns out all that size was the panicking machinery
brought in by the personality function!
The change here is to return a `Result` internally so we can bubble up the fatal
error, eventually translating to the appropriate error code for the libunwind
ABI.
Change `llvm.neon.*` to `llvm.arm.neon.*` in the mapping for platform intrinsics
This avoids linker errors when using platform intrinsics on 32-bit ARM with
NEON.
Fixesrust-lang-nursery/simd#10.
I don't have an explanation why the old code might have worked when the `simd` crate was written, since the new LLVM intrinsic naming seems to have existed as early as 2012. Maybe LLVM accepted two naming schemes for a few years and dropped the `llvm.neon.*` version recently? I don't know.
Also, I don't know how to write a unit test for this.
Better closure error message
Use tracked data introduced in #42196 to provide a better closure
error message by showing why a closure implements `FnOnce`.
```
error[E0525]: expected a closure that implements the `Fn` trait, but
this closure only implements `FnOnce`
--> $DIR/issue_26046.rs:4:19
|
4 | let closure = move || {
| ___________________^
5 | | vec
6 | | };
| |_____^
|
note: closure is `FnOnce` because it moves the variable `vec` out of
its environment
--> $DIR/issue_26046.rs:5:9
|
5 | vec
| ^^^
error: aborting due to previous error(s)
```
Fixes#26046
r? @nikomatsakis
cc @doomrobo
Fix setting PATH during linkage on windows-gnu
This makes the behavior almost exactly the same as before the VS2017 patch, except that on MSVC builds the host bin path is no longer added to PATH. I am not sure that's actually necessary on any platform.
r? @alexcrichton
Fixes https://github.com/rust-lang/rust/issues/42422
Changing error message from `contains interior mutability` to `may contain interior mutability`
Fixes#40313 . I have changed the message from `contains interior mutability` to `may contain interior mutability` for the following example
```
use std::cell::Cell;
use std::panic::catch_unwind;
fn main() {
let mut x = Cell::new(22);
catch_unwind(|| { x.set(23); });
}
```
which has been added as a ui test.
Also, the message [here](https://github.com/gaurikholkar/rust/blob/master/src/librustc_mir/transform/qualify_consts.rs#L666) and it's respective `compile-fail` test have been modified.
cc @nikomatsakis @Mark-Simulacrum @eddyb
The Rustdoc book
A work-in-progress start for docs for rustdoc.
This doesn't actually generate the docs yet; I wanted to open this PR to get feedback on this approach, the chapters headings themselves, and to see if anyone wanted to help fill in the ones that aren't done yet.
Start of #42322.
/cc @rust-lang/dev-tools @rust-lang/docs
rustc: T: 'empty always holds for all types.
Fixes#42467 by special-casing `ReEmpty` to always hold, even for parameters.
The reason this is the case is that `ReEmpty` is the result of inferring a region variable with no constraints attached to it, so there is no lifetime a type would contain which would be strictly shorter.
r? @nikomatsakis
rustc_typeck: do not overlap a borrow of TypeckTables with method lookup.
If trait selection is reached, it could potentially request a closure signature, which will have to borrow the `TypeckTables` of the current function, and so those tables *should not* be mutably borrowed.
Fixes#42463.
r? @nikomatsakis
Pursuant to issue #25663, this commit adds the max and min functions to the Ord trait, enabling items that implement Ord to use UFCS (ex. 1.max(2)) instead of the longer std::cmp::max(1,2) format.
