Prototype: Add unstable `-Z reference-niches` option
MCP: rust-lang/compiler-team#641
Relevant RFC: rust-lang/rfcs#3204
This prototype adds a new `-Z reference-niches` option, controlling the range of valid bit-patterns for reference types (`&T` and `&mut T`), thereby enabling new enum niching opportunities. Like `-Z randomize-layout`, this setting is crate-local; as such, references to built-in types (primitives, tuples, ...) are not affected.
The possible settings are (here, `MAX` denotes the all-1 bit-pattern):
| `-Z reference-niches=` | Valid range |
|:---:|:---:|
| `null` (the default) | `1..=MAX` |
| `size` | `1..=(MAX- size)` |
| `align` | `align..=MAX.align_down_to(align)` |
| `size,align` | `align..=(MAX-size).align_down_to(align)` |
------
This is very WIP, and I'm not sure the approach I've taken here is the best one, but stage 1 tests pass locally; I believe this is in a good enough state to unleash this upon unsuspecting 3rd-party code, and see what breaks.
Support `--print KIND=PATH` command line syntax
As is already done for `--emit KIND=PATH` and `-L KIND=PATH`.
In the discussion of #110785, it was pointed out that `--print KIND=PATH` is nicer than trying to apply the single global `-o` path to `--print`'s output, because in general there can be multiple print requests within a single rustc invocation, and anyway `-o` would already be used for a different meaning in the case of `link-args` and `native-static-libs`.
I am interested in using `--print cfg=PATH` in Buck2. Currently Buck2 works around the lack of support for `--print KIND=PATH` by [indirecting through a Python wrapper script](d43cf3a51a/prelude/rust/tools/get_rustc_cfg.py) to redirect rustc's stdout into the location dictated by the build system.
From skimming Cargo's usages of `--print`, it definitely seems like it would benefit from `--print KIND=PATH` too. Currently it is working around the lack of this by inserting `--crate-name=___ --print=crate-name` so that it can look for a line containing `___` as a delimiter between the 2 other `--print` informations it actually cares about. This is commented as a "HACK" and "abuse". 31eda6f7c3/src/cargo/core/compiler/build_context/target_info.rs (L242) (FYI `@weihanglo` as you dealt with this recently in https://github.com/rust-lang/cargo/pull/11633.)
Mentioning reviewers active in #110785: `@fee1-dead` `@jyn514` `@bjorn3`
The style guide inconsistently used language like "there should be a
space" or "it should be on its own line", or "may be written on a single
line", for things that are required components of the default Rust
style. "should" and especially "may" come across as optional. While the
style guide overall now has a statement at the top that the default
style itself is a *recommendation*, the *definition* of the default
style should not be ambiguous about what's part of the default style.
Rewrite language in the style guide to only use "should" and "may" and
similar for truly optional components of the style (e.g. things a tool
cannot or should not enforce in its default configuration).
In their place, either use "must", or rewrite in imperative style ("put
a space", "start it on the same line"). The latter also substantially
reduces the use of passive voice.
This is a purely editorial change, and does not affect the semantic
definition of the Rust style.
The style guide requires a trailing comma on where clause components,
but then gives an example that doesn't include one. Add the missing
trailing comma.
Remove outdated Firefox-specific CSS for search's crate selector appearance
Remove adjustments that used to be necessary for search's crate selector appearance (padding) to look identical on Firefox. New versions of Firefox appear to have changed behavior to agree with Chrome.
As briefly discussed in https://github.com/rust-lang/rust/pull/98855#issuecomment-1624098112
r? ``@GuillaumeGomez``
new solver: don't consider blanket impls multiple times
only consider candidates which rely on the self type in `assemble_candidates_after_normalizing_self_ty`.
r? ``@compiler-errors``
rustdoc: fix position of `default` in method rendering
With the following code:
```rs
#![feature(specialization)]
pub trait A {
unsafe fn a();
}
impl A for () {
default unsafe fn a() {}
}
```
rustdoc would render the `impl` of `a` as
```rs
unsafe default fn a()
```
which is inconsistent with the actual position of `default`.
This PR fixes this issue.
Add tests for `--document-hidden-items` option
Since `--document-hidden-items` was greatly fixed/improved in https://github.com/rust-lang/rust/pull/113574, thought it might be worth adding some more tests for it to prevent new regressions.
As for the first commit, it allows to go from:
```
Traceback (most recent call last):
File "/home/imperio/rust/rust/src/etc/htmldocck.py", line 706, in <module>
check(sys.argv[1], get_commands(rust_test_path))
File "/home/imperio/rust/rust/src/etc/htmldocck.py", line 689, in check
for c in commands:
File "/home/imperio/rust/rust/src/etc/htmldocck.py", line 274, in get_commands
args = shlex.split(args)
File "/usr/lib/python3.10/shlex.py", line 315, in split
return list(lex)
File "/usr/lib/python3.10/shlex.py", line 300, in __next__
token = self.get_token()
File "/usr/lib/python3.10/shlex.py", line 109, in get_token
raw = self.read_token()
File "/usr/lib/python3.10/shlex.py", line 191, in read_token
raise ValueError("No closing quotation")
ValueError: No closing quotation
```
to:
```
Traceback (most recent call last):
File "/home/imperio/rust/rust/src/etc/htmldocck.py", line 708, in <module>
check(sys.argv[1], get_commands(rust_test_path))
File "/home/imperio/rust/rust/src/etc/htmldocck.py", line 691, in check
for c in commands:
File "/home/imperio/rust/rust/src/etc/htmldocck.py", line 278, in get_commands
raise Exception("line {}: {}".format(lineno + 1, exc)) from None
Exception: line 57: No closing quotation
```
Having the line where the error occurred is quite useful.
r? `@notriddle`
Fix rpath for libdir is specified
## What does this PR try to resolve?
When building the Rust toolchain with `--libdir=lib64`, the executable tools such as `rustc` cannot find shared libraries.
```bash
./configure --prefix=/ --libdir=lib64
DESTDIR=/tmp/rust ./x.py install
```
```
$ /tmp/rust/bin/rustc
rustc: error while loading shared libraries: librustc_driver-13f1fd1bc7f7000d.so: cannot open shared object file: No such file or directory
```
This issue is caused by the link args `-Wl,rpath` being different from `--libdir`.
```
$ readelf -d /tmp/rust/bin/rustc | grep RUNPATH
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib]
```
## How to resolve?
When setting the rpath, get it from sysroot libdir relative path.
After this patch:
```
$ readelf -d /tmp/rust/bin/rustc | grep RUNPATH
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib64]
```
On nightly, dump ICE backtraces to disk
Implement rust-lang/compiler-team#578.
When an ICE is encountered on nightly releases, the new rustc panic handler will also write the contents of the backtrace to disk. If any `delay_span_bug`s are encountered, their backtrace is also added to the file. The platform and rustc version will also be collected.
<img width="1032" alt="Screenshot 2023-03-03 at 2 13 25 PM" src="https://user-images.githubusercontent.com/1606434/222842420-8e039740-4042-4563-b31d-599677171acf.png">
The current behavior will *always* write to disk on nightly builds, regardless of whether the backtrace is printed to the terminal, unless the environment variable `RUSTC_ICE_DISK_DUMP` is set to `0`. This is a compromise and can be changed.
Fix invalid display of inlined re-export when both local and foreign items are inlined
Fixes#105735.
The bug is actually quite interesting: at the `clean` pass, local inlined items have their `use` item removed, however foreign items don't have their `use` item removed because it's in the `clean` pass that we handle them. So when a `use` inlines both a local and a foreign item, it will work as expected for the foreign one, but not for the local as its `use` should not be around anymore.
To prevent this, I created a new `inlined_foreigns` field into the `Module` struct to allow to remove the `use` item early on for foreign items as well. Then we iterate it in the `clean` pass directly.
r? ``@notriddle``
Implement rust-lang/compiler-team#578.
When an ICE is encountered on nightly releases, the new rustc panic
handler will also write the contents of the backtrace to disk. If any
`delay_span_bug`s are encountered, their backtrace is also added to the
file. The platform and rustc version will also be collected.
add mips64r6 and mips32r6 as target_arch values
This PR introduces `"mips32r6"` and `"mips64r6"` as valid `target_arch` values, and would be the arch value used by Tier-3 targets `mipsisa32r6-unknown-linux-gnu`, `mipsisa32r6el-unknown-linux-gnu`, `mipsisa64r6-unknown-linux-gnuabi64` and `mipsisa64r6el-unknown-linux-gnuabi64`.
This PR was inspired by `rustix` attempting to link traditional mips64el objects with mips64r6el objects when building for mips64r6, even though `rustix` recently removed outline assembly support. This is because currently this target's `target_arch` is `"mips64"` and rustix has its respective assembly implementation as well as a pre-compiled little-endian static library prepared for mips64el, a tier-2 target with the same `target_arch`. After some [discussions on zulip](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Add.20New.20Values.20To.20MIPS_ALLOWED_FEATURES.20compiler-team.23595), I decided to treat mips64r6 as an independent architecture from Rust's POV, since these two architectures are incompatible anyway.
This PR is now waiting for `libc` to release a new version with [support](https://github.com/rust-lang/libc/pull/3268) for these `target_arch` values. It is not expected to introduce changes to any other target, especially Tier-1 and Tier-2 targets.
This PR has its corresponding [MCP](https://github.com/rust-lang/compiler-team/issues/632) approved.
Fix compiletest windows path finding with spaces
With `(?x)` enabled spaces are ignored unless you escape them, so the space wasn't being added to the character class
I don't think this makes any difference to the current test suite, but it could save someone a headache in the future
Rename `arg_iter` to `iter_instantiated`
`arg_iter` doesn't make sense, and doesn't really indicate what it's doing (returning an iterator that ~~substitutes~~ instantiates its elements).
`iter_instantiated_copied` is kinda awkward but i don't really wanna bikeshed it.
r? `@oli-obk`
