Make source tarball generation more reproducible
This PR performs several changes to source tarball generation (`x dist rustc-src`) in order to make it more reproducible (in light of the recent "xz backdoor"...). I want to follow up on it with making a separate CI workflow for generating the tarball.
After this PR, running this locally produces identical checksums:
```bash
$ ./x dist rustc-src
$ sha256sum build/dist/rustc-1.79.0-src.tar.gz
$ ./x dist rustc-src
$ sha256sum build/dist/rustc-1.79.0-src.tar.gz
```
r? `@Mark-Simulacrum`
make some doc comments not doc tests
`./miri test --doc` will run doctests even if we have them disabled (that's a cargo quirk: https://github.com/rust-lang/cargo/issues/13668). This fixes that command to not fail.
compiletest: print reason for failing to read tests
Turns this
```
Could not read tests from /path/to/rust/tests/run-make
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Build completed unsuccessfully in 0:00:05
```
into this:
```
Could not read tests from /path/to/rust/tests/run-make: run-make tests cannot have both `Makefile` and `rmake.rs`
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Build completed unsuccessfully in 0:00:05
```
While first one is technically correct - it's not helpful at all, adding backtrace is not making it any better.
Stabilize `unchecked_{add,sub,mul}`
Tracking issue: #85122
I think we might as well just stabilize these basic three. They're the ones that have `nuw`/`nsw` flags in LLVM.
Notably, this doesn't include the potentially-more-complex or -more-situational things like `unchecked_neg` or `unchecked_shr` that are under different feature flags.
To quote Ralf https://github.com/rust-lang/rust/issues/85122#issuecomment-1681669646,
> Are there any objections to stabilizing at least `unchecked_{add,sub,mul}`? For those there shouldn't be any surprises about what their safety requirements are.
*Semantially* these are [already available on stable, even in `const`, via](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=bdb1ff889b61950897f1e9f56d0c9a36) `checked_*`+`unreachable_unchecked`. So IMHO we might as well just let people write them directly, rather than try to go through a `let Some(x) = x.checked_add(y) else { unsafe { hint::unreachable_unchecked() }};` dance.
I added additional text to each method to attempt to better describe the behaviour and encourage `wrapping_*` instead.
r? rust-lang/libs-api
Rollup of 4 pull requests
Successful merges:
- #123176 (Normalize the result of `Fields::ty_with_args`)
- #123186 (copy any file from stage0/lib to stage0-sysroot/lib)
- #123187 (Forward port 1.77.1 release notes)
- #123188 (compiler: fix few unused_peekable and needless_pass_by_ref_mut clippy lints)
r? `@ghost`
`@rustbot` modify labels: rollup
copy any file from stage0/lib to stage0-sysroot/lib
With the LLVM 18 upgrade, the name of the LLVM library has been changed to something like `libLLVM.so.18.1-rust-1.78.0-beta`, which `is_dylib` function cannot determine as it only looks whether files are ending with ".so" or not.
This change resolves this problem by no longer doing that ".so" check, as we need all files from the stage0/lib as they are all dependency of rustc anyway.
Fixes#122913
Simplify trim-paths feature by merging all debuginfo options together
This PR simplifies the trim-paths feature by merging all debuginfo options together, as described in https://github.com/rust-lang/rust/issues/111540#issuecomment-1994010274.
And also do some correctness fixes found during the review.
cc `@weihanglo`
r? `@michaelwoerister`
Match ergonomics 2024: implement mutable by-reference bindings
Implements the mutable by-reference bindings portion of match ergonomics 2024 (#123076), with the `mut ref`/`mut ref mut` syntax, under feature gate `mut_ref`.
r? `@Nadrieril`
`@rustbot` label A-patterns A-edition-2024
With the LLVM 18 upgrade, the name of the LLVM library has been changed to something like
`libLLVM.so.18.1-rust-1.78.0-beta`, which `is_dylib` function cannot determine as it only
looks whether files are ending with ".so" or not.
This change resolves this problem by no longer doing that ".so" check, as we need all files
from the stage0/lib as they are all dependency of rustc anyway.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Codegen const panic messages as function calls
This skips emitting extra arguments at every callsite (of which there
can be many). For a librustc_driver build with overflow checks enabled,
this cuts 0.7MB from the resulting shared library (see [perf]).
A sample improvement from nightly:
```
leaq str.0(%rip), %rdi
leaq .Lalloc_d6aeb8e2aa19de39a7f0e861c998af13(%rip), %rdx
movl $25, %esi
callq *_ZN4core9panicking5panic17h17cabb89c5bcc999E@GOTPCREL(%rip)
```
to this PR:
```
leaq .Lalloc_d6aeb8e2aa19de39a7f0e861c998af13(%rip), %rdi
callq *_RNvNtNtCsduqIKoij8JB_4core9panicking11panic_const23panic_const_div_by_zero@GOTPCREL(%rip)
```
[perf]: https://perf.rust-lang.org/compare.html?start=a7e4de13c1785819f4d61da41f6704ed69d5f203&end=64fbb4f0b2d621ff46d559d1e9f5ad89a8d7789b&stat=instructions:u
Errors started showing up, and I read somewhere that this might be
because of old ninja versions. This ninja version is indeed *ancient*.
```
multiple outputs aren't (yet?) supported by depslog; bring this up on the mailing list if it affects you
```
Correctly get complete intra-doc link data
Fixes https://github.com/rust-lang/rust/issues/123158.
The problem was that we didn't take into account cases where there would be content other than backticks into the intra doc link definition.
r? `@notriddle`
Use compiletest directives instead of manually checking TARGET / tools
Changes:
- Accept `ignore-wasm32-wasip1` and `needs-wasmtime` directives.
- Add support for needing `wasmtime` as a runner.
- Update wasm/compiler_builtin tests to use compiletest directives over manual checks.
Add tidy check to error on new `Makefile`s in `tests/run-make`
We would like to strongly encourage new `run-make` tests to be written in Rust and not add any new `Makefile`-based `run-make` tests.
