Add missing #[inline] on AsFd impl for sys::unix::fs::File
This operation should be extremely cheap, at most the `mov` of the underlying file descriptor, but due to this missing `#[inline]` it is currently a function call.
Print GHA log groups to stdout instead of stderr
In all other places (e.g. `bootstrap.py`, `opt-dist`), we use stdout instead of stderr. I think that using stderr might be causing some discrepancies in the log, where sometimes the contents of a group "leak" outside the group. Let's see what happens if we use stdout instead. It's possible that it will be worse, since we print most stuff to stderr (?).
r? `@ghost`
update jemalloc-sys to most recent release
I wouldn't expect this to show perf improvements: IIUC this release should only contain a bugfix.
cc `@nnethercote`
r? `@ghost`
Correct misleading std::fmt::Binary example (#116165)
Nothing too crazy...
- Add two to the width specifier (so all 32 bits are correctly displayed)
- Pad out the compared string so the assert passes
- Add `// Note` comment highlighting the need for the extra width when using the `#` flag.
The exact contents (and placement?) of the note are, of course, highly bikesheddable.
bootstrap: copy self-contained linking components to `stage0-sysroot`
I hit this issue while trying to bootstrap using a rustc where `rust-lld` is used by default: this was the cause of the failure to profile rustc-perf's bootstrap benchmark in https://github.com/rust-lang/rust/pull/113382.
`stage0-sysroot` currently only has libs and self-contained objects, not the other self-contained linking components yet. Most notably, it does not contain the linker and wrappers that we build, and that rustup distributes.
If you try to bootstrap using the bootstrap compiler's `rust-lld`, it will fail to link std at stage0 because `rust-lld` and the `gcc-ld` wrappers, will not be found in `stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/bin`.
This PR copies the `bin` directory next to the `lib` directory when `rust.lld` is enabled in the config (though maybe it could be done unconditionally, the fact that we need it to link does not necessarily mean that we'd want to build and provide it at stage1).
cc `@Kobzol` who also encountered this issue while using lld during bootstrap.
bootstrap major change detection implementation
The use of `changelog-seen` and `bootstrap/CHANGELOG.md` has not been functional in any way for many years. We often do major/breaking changes but never update the changelog file or the `changelog-seen`. This is an alternative method for tracking major or breaking changes and informing developers when such changes occur.
Example output when bootstrap detects a major change:
Add track_caller attribute to Result::unwrap_or_else
Fixes issue where panics in unwrap_or_else callbacks marked with the `track_caller` attribute appear as errors in core.
Stdio support for UEFI
- Uses Simple Text Output Protocol and Simple Text Input Protocol
- Reading is done one character at a time
- Writing is done with max 4096 characters
# Quirks
## Output Newline
- UEFI uses CRLF for newline. So when running the application in UEFI shell (qemu VGA), the output of `println` looks weird.
- However, since the UEFI shell supports piping output, I am unsure if doing any output post-processing is a good idea. UEFI shell `cat` command seems to work fine with just LF.
## Input Newline
- `Stdin.read_line()` method is broken in UEFI shell. Pressing enter seems to be read as CR, which means LF is never encountered.
- Works fine with input redirection from file.
CC `@dvdhrm`
Cleanup number handling in match exhaustiveness
Doing a little bit of cleanup; handling number constants was somewhat messy. In particular, this:
- evals float consts once instead of repetitively
- reduces `Constructor` from 88 bytes to 56 (`mir::Const` is big!)
The `fast_try_eval_bits` function was mostly constructed from inlining existing code but I don't fully understand it; I don't follow how consts work and are evaluated very well.
coverage: Regression test for functions with unreachable bodies
This is a regression test for the coverage issue that was addressed temporarily by #116166, and is tracked by #116171.
---
If we instrument a function for coverage, but all of its counter-increment statements are removed by MIR optimizations, LLVM will think it isn't instrumented and it will disappear from coverage maps and coverage reports.
Most MIR opts won't cause this because they tend not to remove statements from bb0, but `UnreachablePropagation` can do so if it sees that bb0 ends with `TerminatorKind::Unreachable`.
Currently we have worked around this by turning off `UnreachablePropagation` when coverage instrumentation is enabled, which is why this test is able to pass.
---
`@rustbot` label +A-code-coverage
