Change `SIGPIPE` ui from `#[unix_sigpipe = "..."]` to `-Zon-broken-pipe=...`
In the stabilization [attempt](https://github.com/rust-lang/rust/pull/120832) of `#[unix_sigpipe = "sig_dfl"]`, a concern was [raised ](https://github.com/rust-lang/rust/pull/120832#issuecomment-2007394609) related to using a language attribute for the feature: Long term, we want `fn lang_start()` to be definable by any crate, not just libstd. Having a special language attribute in that case becomes awkward.
So as a first step towards the next stabilization attempt, this PR changes the `#[unix_sigpipe = "..."]` attribute to a compiler flag `-Zon-broken-pipe=...` to remove that concern, since now the language is not "contaminated" by this feature.
Another point was [also raised](https://github.com/rust-lang/rust/pull/120832#issuecomment-1987023484), namely that the ui should not leak **how** it does things, but rather what the **end effect** is. The new flag uses the proposed naming. This is of course something that can be iterated on further before stabilization.
Tracking issue: https://github.com/rust-lang/rust/issues/97889
Some hir cleanups
It seemed odd to not put `AnonConst` in the arena, compared with the other types that we did put into an arena. This way we can also give it a `Span` without growing a lot of other HIR data structures because of the extra field.
r? compiler
Allow fmt to run on rmake.rs test files
As discussed with `@jieyouxu,` `rmake.rs` from the `run-make` testsuite would benefit from being formatted as well.
Only thing needed to be done for it to work: allow support for `!` in our `rustfmt.toml` file parsing.
r? `@onur-ozkan`
Add support for inputing via stdin with run-make-support
This PR adds the facility to set a input bytes that will be passed via the standard input.
This is useful for testing `rustc -` (and soon `rustdoc -`).
In #124611 took the approach of having a dedicated `run` method but it is not very convenient to use and would necessitate many functions, one for success, one for fail, ...
Instead this PR takes a different approach and allows setting the input bytes as if it were a parameter and when calling the (now custom) `output` function, we write the input bytes into stdin. I think this gives us maximum flexibility in the implementation and a simple interface for users.
To test this new logic I ported `tests/run-make/stdin-non-utf8/` to an `rmake.rs` one.
r? `@jieyouxu`
handle the targets that are missing in stage0
During sanity checks, we search for target names to determine if they exist in the compiler's built-in target list (`rustc --print target-list`). While a target name may be present in the stage2 compiler, it might not yet be included in stage0. This PR handles that difference.
Follow-up of https://github.com/rust-lang/rust/pull/123546
In the stabilization attempt of `#[unix_sigpipe = "sig_dfl"]`, a concern
was raised related to using a language attribute for the feature: Long
term, we want `fn lang_start()` to be definable by any crate, not just
libstd. Having a special language attribute in that case becomes
awkward.
So as a first step towards towards the next stabilization attempt, this
PR changes the `#[unix_sigpipe = "..."]` attribute to a compiler flag
`-Zon-broken-pipe=...` to remove that concern, since now the language
is not "contaminated" by this feature.
Another point was also raised, namely that the ui should not leak
**how** it does things, but rather what the **end effect** is. The new
flag uses the proposed naming. This is of course something that can be
iterated on further before stabilization.
Use `tcx.types.unit` instead of `Ty::new_unit(tcx)`
I don't think there is any need for the function, given that we can just access the `.types`, similarly to all other primitives?
Arm bare-metal target doc changes
Updates the Arm bare-metal target docs:
* Detailed pages for all the Cortex-M targets, including details about setting target-cpu and target-features to suit specific Arm models
* More detail about the difference between `eabi` and `eabihf`
* Marks the Embedded Devices Working Group Cortex-M Team as the maintainer of the Cortex-M targets
rustc: document the jobserver
Explicitly document that the jobserver may be used by `rustc`, as well as recommend the `+` indicator for integration of `rustc` into GNU Make.
In particular, show the warning to increase the chances that this document is found when searching for solutions online.
In addition, add a note about the issue with GNU Make 4.3 since it is important that users realize they should do this even if they do not expect parallelism from `rustc`.
Finally, show how to workaround the issue of `$(shell ...)` calls in recursive Make (which e.g. was needed for the Linux kernel).
The GNU Make 4.4 case under `--jobserver-style=pipe` is not added since it got fixed after Rust 1.76.0 already (i.e. `rustc` will not warn if it finds the negative file descriptors).
From: https://github.com/rust-lang/rust/issues/120515
Cc: `@petrochenkov` `@belovdv` `@weihanglo` `@bjorn3`
---
v2: To be able to use tab characters for the Make examples, add `<!-- ignore-tidy-{check} -->` support to `tidy`.
v3: Added "Integration with build systems" section to hold the GNU Make one. Added "by clearing the `MAKEFLAGS` variable". Added "aforementioned" so that it is clear we are talking about the warning above.
v4: Added CMake subsection. Added a note that `rustc` may be affected by other flags, e.g. `CARGO_MAKEFLAGS`.
v5: Added that `rustc` will choose the number of jobs if a jobserver is not passed.
Update cargo
15 commits in b60a1555155111e962018007a6d0ef85207db463..6087566b3fa73bfda29702632493e938b12d19e5
2024-04-26 16:37:29 +0000 to 2024-04-30 20:45:20 +0000
- fix(cargo-fix): dont fix into standard library (rust-lang/cargo#13792)
- refactor: Move diagnostic printing to Shell (rust-lang/cargo#13813)
- Populate git information when building Cargo from Rust's source tarball (rust-lang/cargo#13832)
- docs: fix several typos found by `typos-cli` (rust-lang/cargo#13831)
- fix(alias): Aliases without subcommands should not panic (rust-lang/cargo#13819)
- fix(toml): Improve granularity of traces (rust-lang/cargo#13830)
- fix(toml): Warn, rather than fail publish, if a target is excluded (rust-lang/cargo#13713)
- test(cargo-lints): Add a test to ensure cap-lints works (rust-lang/cargo#13829)
- fix(toml)!: Remove support for inheriting badges (rust-lang/cargo#13788)
- chore(ci): Don't check `cargo` against beta channel (rust-lang/cargo#13827)
- Fix target entry in .gitignore (rust-lang/cargo#13817)
- Bump to 0.81.0; update changelog (rust-lang/cargo#13823)
- Add failing test: artifact_dep_target_specified (rust-lang/cargo#13816)
- fix(cargo-lints): Don't always inherit workspace lints (rust-lang/cargo#13812)
- Update SleepTraker returns_in_order unit test (rust-lang/cargo#13811)
r? ghost
Use `target_vendor = "apple"` instead of `target_os = "..."`
Use `target_vendor = "apple"` instead of `all(target_os = "macos", target_os = "ios", target_os = "tvos", target_os = "watchos", target_os = "visionos")`.
The apple targets are quite close to being identical, with iOS, tvOS, watchOS and visionOS being even closer, so using `target_vendor` when possible makes it clearer when something is actually OS-specific, or just Apple-specific.
Note that `target_vendor` will [be deprecated in the future](https://github.com/rust-lang/rust/issues/100343), but not before an alternative (like `target_family = "apple"`) is available.
While doing this, I found various inconsistencies and small mistakes in the standard library, see the commits for details. Will follow-up with an extra PR for a similar issue that need a bit more discussion. EDIT: https://github.com/rust-lang/rust/pull/124494
Since you've talked about using `target_vendor = "apple"` in the past:
r? workingjubilee
CC `@simlay,` `@thomcc`
`@rustbot` label O-macos O-ios O-tvos O-watchos O-visionos
Add `normalize()` in run-make `Diff` type
I need it to do the same as:
```
//@ normalize-stdout-test "finished in \d+\.\d+s" -> "finished in $$TIME"
```
in doctests.
I need it in particular for the https://github.com/rust-lang/rust/pull/123974 PR (which contains this commit until this PR current PR is merged).
cc `@Urgau`
r? `@jieyouxu`
Write `git-commit-{sha,info}` for Cargo in source tarballs
Right now Cargo doesn't populate the commit hash or date in its version output when it's built from the plain source tarball. That's because we don't include the git information for it, and Cargo's build script doesn't pick it up.
This PR *partially* solves the problem by storing the git information for Cargo in `src/tools/cargo` in the plain source tarball. We store separate information because even when built in CI Cargo uses its own git information rather than Rust's.
This PR will also require a change in the Cargo repository to consume this information (https://github.com/rust-lang/cargo/pull/13832), but it doesn't have to be blocked on the Cargo PR being merged.
Port repr128-dwarf run-make test to rmake
This PR ports the repr128-dwarf run-make test to rmake, using the `gimli` crate instead of the `llvm-dwarfdump` command.
Note that this PR changes `rmake.rs` files to be compiled with the 2021 edition (previously no edition was passed to `rustc`, meaning they were compiled with the 2015 edition). This means that `panic!("{variable}")` will now work as expected in `rmake.rs` files (there's already a usage in the [wasm-symbols-not-exported test](aca749eefc/tests/run-make/wasm-symbols-not-exported/rmake.rs (L34)) that this will fix).
Tracking issue: #121876
Yes it looks weird, but this is how Arm write it now.
I left ARM64 alone, because it's a Microsoft/Apple term but not an Arm term (they have Armv8-A and Armv9-A architectures, which say that A64 instructions are executed when in the Aarch64 state), and I don't want to get into that, especially for a Tier 1 target.
Explicitly document that the jobserver may be used by `rustc` and show
the warning to increase the chances that this document is found when
searching for solutions online.
In particular, add a section about the interaction with build systems,
which is intended to contain recommendations on how to integrate `rustc`
with different built systems.
For GNU Make, recommend using the `+` indicator. In addition, add a
note about the issue with GNU Make 4.3 since it is important that users
realize they should do this even if they do not expect parallelism from
`rustc`. Finally, show how to workaround the issue of `$(shell ...)`
calls in recursive Make (which e.g. was needed for the Linux kernel).
The GNU Make 4.4 case under `--jobserver-style=pipe` is not added since
it got fixed after Rust 1.76.0 already (i.e. `rustc` will not warn if
it finds the negative file descriptors).
For CMake, recommend using `JOB_SERVER_AWARE` and show a workaround using
`$(MAKE)` for earlier versions (when using the Makefile generator).
From: https://github.com/rust-lang/rust/issues/120515
Cc: @petrochenkov @belovdv @weihanglo @bjorn3
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Rollup of 4 pull requests
Successful merges:
- #124519 (adapt a codegen test for llvm 19)
- #124524 (Add StaticForeignItem and use it on ForeignItemKind)
- #124540 (Give proof tree visitors the ability to instantiate nested goals directly)
- #124543 (codegen tests: Tolerate `range()` qualifications in enum tests)
r? `@ghost`
`@rustbot` modify labels: rollup
Add StaticForeignItem and use it on ForeignItemKind
This is in preparation for unsafe extern blocks that adds a safe variant for functions inside extern blocks.
r? `@oli-obk`
cc `@compiler-errors`
coverage: Replace boolean options with a `CoverageLevel` enum
After #123409, and some discussion at https://github.com/rust-lang/rust/issues/79649#issuecomment-2042093553 and #124120, it became clear to me that we should have a unified concept of “coverage level”, instead of having several separate boolean flags that aren't actually independent.
This PR therefore introduces a `CoverageLevel` enum, to replace the existing boolean flags for `branch` and `mcdc`.
The `no-branch` value (for `-Zcoverage-options`) has been renamed to `block`, instructing the compiler to only instrument for block coverage, with no branch coverage or MD/DC instrumentation.
`@rustbot` label +A-code-coverage
cc `@ZhuUx` `@Lambdaris` `@RenjiSann`
Remove direct dependencies on lazy_static, once_cell and byteorder
The relevant functionality of all three crates is now available and stable in the standard library, i.e. `std::sync::OnceLock` and `{integer}::to_le_bytes`. I think waiting for `LazyLock` (#109736) would give marginally more concise code, but not by much.
