I noticed these while reading through the build system
documentation. They're hardly worth fixing, but I'm also using this to
get my feet wet with the rustc contribution system.
A helpful primitive for moving chunks of data around inside a slice.
In particular, adding elements to the end of a Vec then moving them
somewhere else, as a way to do efficient multiple-insert. (There's
drain for efficient block-remove, but no easy way to block-insert.)
Talk with another example: <https://youtu.be/qH6sSOr-yk8?t=560>
Not being an enum improves ergonomics, especially since NonEmpty could be Empty. It can still be iterable without an extra "done" bit by making the range have !(start <= end), which is even possible without changing the Step trait.
Implements RFC 1980
Update rust-installer to normalize manifest paths
This fixes the backslash-paths found in the manifests of installers that are built on Windows. This is the most problematic part of #42121, leaving just the non-executable install.sh.
r? @alexcrichton
Improving std::env docs
Addresses #29351.
Hopefully this addresses the following points:
> - iterators should use the standard iterator boilerplate like https://doc.rust-lang.org/std/iter/struct.Map.html, this applies to all structs except for JoinPathsError
> - JoinPathsError should properly link the function it comes from and use language similar to https://doc.rust-lang.org/std/io/struct.Error.html
> - same wording issues with VarError
> - functions need to ensure linkage to things they refer to in their descriptions
> - Explain the difference between `os` and non-`os` structs and methods
expose needs_drop under mem
Note that I purposefully didn't update the intrinsic's documentation, because I think it makes sense for it be more... "honest" about its semantics.
Add an option to run rustbuild on low priority on Windows and Unix
This is a resurrection of #40776, combining their Windows setup with an additional setup on Unix to set the program group's *nice*ness to +10 (low-but-not-lowest priority, mirroring the priority in the Windows setup) when the `low_priority` option is on.
Revert "Reenable opt-level 3"
This reverts commit 30383b2384, from #41967.
We believe that this is causing the failures when compiling rustc on 64 bit (which are probably segfaults).
cc @ishitatsuyuki
Correct some stability versions
These were found by running tidy on stable versions of rust and finding
features stabilised with the wrong version numbers.
Fix: "warning: redundant linker flag specified for library `ole32`"
llvm-config seems to output this library name correctly now, removing
the need for the hack in "librustc_llvm/build.rs".
Reenable opt-level 3
This comment is quite old, let's see what would happen with current MSVC.
Since there's no AppVeyor test for PR, the best way is to try if it get through homu. I don't recommend doing this in roll-up.
debuginfo: Generate unique DW_AT_names for compilation units to work around OSX linker bug
This should fix issue #39160 and does not seem to cause any problems.
cc @tromey, @Manishearth
r? @jdm
rustdoc: Fix implementors list javascript
* Use a different loop variable, `i` was already taken. This caused
missing items in the implementors list.
* Use `.getAttribute('href')` rather than `.href` to get the relative
URL which is what it needs to actually fix the links.
More fallout from #41307.
r? @GuillaumeGomez
Give a nicer error for non-Unicode arguments to rustc and rustdoc
Previously, any non-Unicode argument would panic rustc:
```
$ rustc $'foo\x80bar'
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report:
https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
thread 'rustc' panicked at 'called `Result::unwrap()` on an `Err` value:
"foo�bar"', /checkout/src/libcore/result.rs:859 note: Run with
`RUST_BACKTRACE=1` for a backtrace.
```
Now it gives a clean error:
```
$ rustc $'foo\x80bar'
error: Argument 1 is not valid Unicode: "foo�bar"
```
Maybe fixes#15890, although we still can't *compile* arbitrary file names.
incr. comp.: Use more bits for DefPath hashes
Use 128 instead of 64 bits for DefPath hashes, like we do for everything else. Collision probability is unnecessarily high with 64 bits.
Also change the representation of `ich::Fingerprint` from `Fingerprint([u8; 16])` to `Fingerprint(u64, u64)` which is better for hashers like `FxHasher`.
