`compiletest` and `remote-test-client`:
The command line for `remote-test-client` was changed slightly
to allow cross-platform compatible paths. The old way of supplying
the support libs was by joining their paths with the executable path
with `:`. This caused Windows-style paths to be split after the
directory letter. Now, the number of support libs is provided
as a parameter as well, and the support lib paths are split off
from the regular args in the client.
`remote-test-server`:
- Marked Unix-only parts as such and implemented Windows alternatives
- On Windows `LD_LIBRARY_PATH` doesn't exist. Libraries are
loaded from `PATH` though, so that's the way around it.
- Tiny cleanup: `Command::args`/`envs` instead of manually
looping over them
- The temp path for Windows has to be set via environment variable,
since there isn't a global temp directory that would work on every
machine (as a static string)
len_zero: skip ranges if feature `range_is_empty` is not enabled
If the feature is not enabled, calling `is_empty()` on a range is ambiguous. Moreover, the two possible resolutions are unstable methods, one inherent to the range and the other being part of the `ExactSizeIterator` trait.
Since `len_zero` only checks for existing `is_empty()` inherent methods, we only take into account the `range_is_empty` feature.
Related: https://github.com/rust-lang/rust/issues/48111#issuecomment-445132965
changelog: len_zero: avoid linting ranges without #![feature(range_is_empty)]
Fixes: #3807
cargo_dev: add ra-setup
It takes an absolute path to a rustc repo and adds path-dependencies
that point towards the respective rustc subcrates into the Cargo.tomls of
the clippy and clippy_lints crate.
This allows rustc-analyzer to show proper type annotations etc on rustc-internals inside the clippy repo.
Usage: cargo dev ra-setup /absolute/path/to/rust/
cc https://github.com/rust-analyzer/rust-analyzer/issues/3517
cc https://github.com/rust-lang/rust-clippy/issues/5514
changelog: none
Rustup
r? @matthiaskrgr
I finally got to doing the rustup. Sorry for taking so long, I was busy the last few days.
@ebroto FYI: I had to add b6c58f0 to make Clippy pass the rustc test suite.
changelog: none
Use `LocalDefId` instead of `NodeId` in `resolve_str_path_error`
Together with https://github.com/rust-lang/rust/pull/72777 this should remove all uses of `NodeId` in `rustdoc`.
cc #50928
r? @petrochenkov
Update the Fuchsia linker defaults
This updates the linker defaults aligning them with Clang. Specifically,
we use 4K pages on all platforms, we always use BIND_NOW, we prefer all
loadable segments be separate and page aligned, and we support RELR
relocations.
rustdoc: remove calls to `local_def_id_from_node_id`
rustdoc calls `local_def_id_from_node_id(CRATE_NODE_ID)` when it can just creates a top level `DefId` using `DefId::local(CRATE_DEF_INDEX)`.
cc #50928
r? @petrochenkov
Fix is_char_boundary documentation
Given the "start _and/or end_" wording in the original, the way I understood it was that the `str::is_char_boundary` method would also return `true` for the last byte in a UTF-8 code point sequence. (Which would have meant that for a string consisting of nothing but 1 and 2 byte UTF-8 code point sequences, it would return nothing but `true`.)
In practice the method returns `true` only for the starting byte of each sequence and the end of the string: [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=e9f5fc4d6bf2f1bf57a75f3c9a180770)
I was also somewhat tempted to remove the _The start and end of the string are considered to be boundaries_, since that's implied by the first sentence, but I decided to avoid bikeshedding over it and left it as it was since it's not wrong in relation to how the method behaves.
miri validation: clarify valid values of 'char'
The old text said "expected a valid unicode codepoint", which is not actually correct -- it has to be a scalar value (which is a code point that is not part of a surrogate pair).
rustc_lexer: Optimize shebang detection slightly
Sorry, I just couldn't resist.
It shouldn't make any difference in practice.
Also, documented a previously unnoticed case with doc comments treated as regular comments during shebang detection.
