| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
ignore `ci_rustc_if_unchanged_logic` test
Temporary hotfix for unblocking CI.
r? ghost
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Prevent building cargo from invalidating build cache of other tools due to conditionally applied `-Zon-broken-pipe=kill` via tracked `RUSTFLAGS`
This PR fixes #130980 where building cargo invalidated the tool build caches of other tools (such as rustdoc) because `-Zon-broken-pipe=kill` was conditionally passed via `RUSTFLAGS` for other tools *except* for cargo. The differing `RUSTFLAGS` triggered tool build cache invalidation as `RUSTFLAGS` is a tracked env var -- any changes in `RUSTFLAGS` requires a rebuild.
`-Zon-broken-pipe=kill` is load-bearing for rustc and rustdoc to not ICE on broken pipes due to usages of raw std `println!` that panics without the flag being set, which manifests in ICEs.
I can't say I like the changes here, but it is what it is...
See detailed discussions and history of `-Zon-broken-pipe=kill` usage in https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Internal.20lint.20for.20raw.20.60print!.60.20and.20.60println!.60.3F/near/474593815.
## Approach
This PR fixes the tool build cache invalidation by informing the `rustc` binary shim when to apply `-Zon-broken-pipe=kill` (i.e. when the rustc binary shim is not used to build cargo). This information is not communicated by `RUSTFLAGS`, which is an env var tracked by cargo, and instead uses an untracked env var `UNTRACKED_BROKEN_PIPE_FLAG` so we won't trigger tool build cache invalidation. We preserve bootstrap's behavior of not setting that flag for cargo by conditionally omitting setting `UNTRACKED_BROKEN_PIPE_FLAG` when building cargo.
Notably, the `-Zon-broken-pipe=kill` instance in https://github.com/rust-lang/rust/blob/1e5719bdc40bb553089ce83525f07dfe0b2e71e9/src/bootstrap/src/core/build_steps/compile.rs#L1058 is not modified because that is used to build rustc only and not cargo itself.
Thanks to `@cuviper` for the idea!
## Testing
### Integration testing
This PR introduces a run-make test for rustc and rustdoc that checks that when they do not ICE/panic when they encounter a broken pipe of the stdout stream.
I checked this test will catch the broken pipe ICE regression for rustc on Linux (at least) by commenting out https://github.com/rust-lang/rust/blob/1e5719bdc40bb553089ce83525f07dfe0b2e71e9/src/bootstrap/src/core/build_steps/compile.rs#L1058, and the test failed because rustc ICE'd.
### Manual testing
I have manually tried:
1. `./x clean && `./x test build --stage 1` -> `rustc +stage1 --print=sysroot | false`: no ICE.
2. `./x clean` -> `./x test run-make` twice: no stage 1 cargo rebuilds.
3. `./x clean` -> `./x build rustdoc` -> `rustdoc +stage1 --version | false`: no panics.
4. `./x test src/tools/cargo`: tests pass, notably `build::close_output` and `cargo_command::closed_output_ok` do not fail which would fail if cargo was built with `-Zon-broken-pipe=kill`.
## Related discussions
Thanks to everyone who helped!
- https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Applying.20.60-Zon-broken-pipe.3Dkill.60.20flags.20in.20bootstrap.3F
- https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/Modifying.20run-make.20tests.20unnecessarily.20rebuild.20stage.201.20.2E.2E.2E
- https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Internal.20lint.20for.20raw.20.60print!.60.20and.20.60println!.60.3F
Fixes https://github.com/rust-lang/rust/issues/130980
Closes https://github.com/rust-lang/rust/issues/131059
---
try-job: aarch64-apple
try-job: x86_64-msvc
try-job: x86_64-mingw
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
- Don't touch rustc's `-Zon-broken-pipe=kill` env var in `compile.rs`.
- Use an untracked env var to pass `-Zon-broken-pipe=kill` for tools but
skip cargo still, because cargo wants `-Zon-broken-pipe=kill` unset.
|
|
Remove valgrind test suite and support from compiletest, bootstrap and opt-dist
The `run-pass-valgrind` test suite is not exercised in CI, and as far as I'm aware nobody runs it (asked in https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Are.20the.20valgrind.20tests.20even.20used.20by.20anyone.3F). What's remaining of valgrind support in compiletest isn't even properly hooked up with bootstrap.
The existing valgrind logic in compiletest is also straight up questionable, i.e.
https://github.com/rust-lang/rust/blob/1b3b8e7b0265162853c650ead09905bc3cdaeae9/src/tools/compiletest/src/runtest/valgrind.rs#L7-L12
It just runs valgrind tests as `rpass` if no valgrind path is provided to compiletest from bootstrap -- but bootstrap doesn't even pass a valgrind path to compiletest in the first place, so this always ran as `rpass` tests. So what is this even testing?
So if it's not testing anything, let's delete it.
Closes #44816 by deleting the test suite :3
<img src="https://github.com/user-attachments/assets/99525bf7-e85b-40ba-9281-e4e1e275c4e8" width=300 />
|
|
Couple of changes to make it easier to compile rustc for wasm
This is a subset of the patches I have on my rust fork to compile rustc for wasm32-wasip1.
|
|
onur-ozkan:llvm-bitcode-linker-multiple-candidates, r=Kobzol
skip in-tree compiler build for llvm-bitcode-linker if ci-rustc is on
Similar to https://github.com/rust-lang/rust/issues/108767, resolves the `multiple candidates` problem for ci-rustc.
See https://github.com/rust-lang/rust/pull/122709#issuecomment-2355436227 for more context.
Blocker for #122709.
|
|
|
|
r=albertlarsan68"
This reverts commit 776187d2c9a42dc07452ae36a8b765d66bd8e2ca, reversing
changes made to 7d015575ada1de8a4627fcdea416194a57a175c2.
|
|
lolbinarycat:bootstrap-warn-old-upstream-worktree, r=albertlarsan68"
This reverts commit 507c05bead4026ed8841512095b4218119eb479f, reversing
changes made to 0609062a91c8f445c3e9a0de57e402f9b1b8b0a7.
|
|
Rollup of 5 pull requests
Successful merges:
- #129392 (Do not consider match/let/ref of place that evaluates to `!` to diverge, disallow coercions from them too)
- #131279 (update "build/host" symlink comment)
- #131312 (On function and method calls in patterns, link to the book)
- #131315 (bootstrap: add `std_features` config)
- #131316 (Fix typo in primitive_docs.rs)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=onur-ozkan
bootstrap: add `std_features` config
Adding support for a std-features config under the rust section in config.toml during bootstrap. This allows rustc devs to build with specific feature flags for local development.
|
|
update "build/host" symlink comment
It's needed and can't be removed, so make it clear where it's needed.
|
|
bootstrap: Consolidate editor setup into ./x setup editor & add support for vim, emacs & helix
Add support for automatically setting up the recommended
LSP config for Vim (coc-nvim), Emacs (eglot) and Helix.
Additionally, refactor setup.rs to make it easier to add support
for more editors in the future.
As suggested,
r? `@jieyouxu`
|
|
bootstrap: add std_features to config.example
fix: use BTreeSet for std-features; add unit tests
* fix formatting of string in front of std_features
* rename `std_features` to `std-features` in config.toml
fix: remove space before std-features in config.toml
fix: remove explicit .into_iter conversion
bootstrap: add details for rust.std-features in config.example.toml
Co-authored-by: Onur Özkan <onurozkan.dev@outlook.com>
fix: remove `Option<T>` from `rust_std_features`
fix: move default rust_std_features to config
fix: make std_features CI rustc incompatible
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Initial support for riscv32{e|em|emc}_unknown_none_elf
We have a research prototype of an RV32EMC target and have been successfully running the e, em, emc programs on it. I'm hoping upstreaming this configuration would make the target maintenance slightly easier.
Configuration is based on the respective {i, im, imc} variants. As defined in RISC-V Unprivileged Spec. 20191213, the only change in RVE wrt. RVI is to reduce the number of integer registers to 16 (x0-x15), which also implies
- 2 callee saved registers instead of 12
- 32-bit / 4-byte stack alignment instead of 128 bits / 16 bytes
My initial presumption is that this will not impact how the target is defined for the compiler but only becomes relevant at the runtime level. I am willing to investigate, though.
EDIT: LLVM is now told about the presumed 32-bit stack alignment.
`@Disasm` `@romancardenas`
|
|
Do not copy libstd dynamic library to sysroot
Since https://github.com/rust-lang/rust/pull/122362, rustc links statically to libstd.[so|dll]. Which means that the libstd.[so|dll] file no longer has to be in the rustc sysroot. However, we are currently still shipping this file, in every new release of Rust, for no reason, it's just wasted bytes.
This PR removes the dynamic library file from the built sysroot.
However, it is not yet performed on Windows, because stage0 incremental tests start failing there (see description of the issue [here](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Failing.20incr.20tests.20on.20Windows.20when.20std.2Edll.20is.20missing/near/474507064)).
This is an extended version of https://github.com/rust-lang/rust/pull/128986.
CC `@Zoxc`
|
|
Add rv32e-targets to 'stage0 missing targets'. This prevents the error
"no such target exists in the target list".
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
|
|
Consolidate LSP setup for different editors into one `./x setup editor`.
|
|
|
|
Update helper docs display disable option
Updated helper docs via configure.py to make it clearer that users can control options with enable and disable
Fixing issue #129146
|
|
Revert #131060 "Drop conditionally applied cargo `-Zon-broken-pipe=kill` flags"
In [#131059] we found out that `-Zon-broken-pipe=kill` is actually **load-bearing**[^1] for
(at least) `rustc` and `rustdoc` to have the kill-process-on-broken-pipe behavior, e.g. `rustc
--print=sysroot | false` will ICE and `rustdoc --print=sysroot | false` will panic on a broken pipe.
This PR reverts 5a7058c5a542ec42d1fa9b524f7b4f7d6845d1e9 (reverts PR #131060) in favor of a future
fix to *unconditionally* apply `-Zon-broken-pipe=kill` to tool builds and also not drop the
`-Zon-broken-pipe=kill` flag for rustc binary builds.
I could not figure out how to write a regression test for the `rustc --print=sysroot | false`
behavior on Unix, so this is a plain revert for now.
This revert will unfortunately reintroduce #130980 until we fix it again with the different approach.
See more details at <https://github.com/rust-lang/rust/issues/131059#issuecomment-2385822033> and in the timeline below.
### Timeline of kill-process-on-broken-pipe behavior changes
See [`unix_sigpipe` tracking issue #97889][#97889] for more context around unix sigpipe handling.
- From the very beginning since 2014, Rust binaries by default use `sig_ign`. This meant that if
output pipe is broken yet the program tries to use `println!` and such, there will be a broken
pipe panic from std. This lead to ICEs from e.g. `rustc --help | false` [#34376].
- [#49606] mitigated [#34376] by adding an explicit signal handler to `rustc_driver` register a
sigpipe handler with `SIG_DFL` which will cause the binary using `rustc_driver` to terminate if
`rustc_driver::set_sigpipe_handler()` is called. `rustc`'s main binary wrapper uses
`rustc_driver::set_sigpipe_handler()`, and so does `rustdoc`.
- A more universal way to set sigpipe behavior for Unix was introduced as part of [#97889], i.e. `#
[unix_sigpipe = "sig_dfl"]` attribute.
- [#102587] migrated `rustc` to use `#[unix_sigpipe = "sig_dfl"]` instead of
`rustc_driver::set_sigpipe_handler`.
- [#103495] migrated `rustdoc` to use `#[unix_sigpipe = "sig_dfl"]` instead of
`rustc_driver::set_sigpipe_handler`. `rustc_driver::set_sigpipe_handler` was removed.
- Following concerns about sigpipe setting UI in [#97889], the UI for specifying sigpipe behavior
was changed in [#124480] from `#[unix_sigpipe = "sig_dfl"]` attribute to the commmand line flag
`-Zon-broken-pipe=kill`.
- In the same PR, `#[unix_sigpipe = "sig_dfl"]` were removed from `rustc` and `rustdoc` main
binary crate entry points in favor of the command line flag. Kill-process-on-broken-pipe
behavior was preserved by adding `-Zon-broken-pipe=kill` for `rustdoc` tool build step and
`rustc` during compile steps.
- [#126934] added `-Zon-broken-pipe=kill` for tool builds *except* for cargo to help with some miri
tests because at the time the PR was written, this would lead to a couple of cargo test failures.
Conditionally setting `RUSTFLAGS` can lead to tool build invalidation, e.g. building `cargo`
without `-Zon-broken-pipe=kill` but `clippy` with the flag can lead to invalidation of the tool
build cache. This is not a problem at the time, because nothing (not even miri) tests built stage
1 cargo (all used initial cargo).
- In [#130634] we found out that `run-make` tests like `compiler-builtins` needed stage 1 cargo, not
just beta bootstrap cargo, because there can be changes that are present in stage 1 cargo but
absent in beta cargo, which was blocking a beta backport.
- [#130642] and later [#130739] now build stage 1 cargo. And as previously mentioned, since
`-Zon-broken-pipe=kill` was specifically *not* set for cargo, this caused tool build cache
invalidation meaning rebuilds of stage 1 even if nothing in source was changed due to differing
`RUSTFLAGS` since `run-make` also builds `rustdoc` and such [#130980].
[#34376]: https://github.com/rust-lang/rust/issues/34376
[#49606]: https://github.com/rust-lang/rust/pull/49606
[#97889]: https://github.com/rust-lang/rust/issues/97889
[#102587]: https://github.com/rust-lang/rust/pull/102587
[#103495]: https://github.com/rust-lang/rust/pull/103495
[#124480]: https://github.com/rust-lang/rust/pull/124480
[#130634]: https://github.com/rust-lang/rust/issues/130634
[#130642]: https://github.com/rust-lang/rust/pull/130642
[#130739]: https://github.com/rust-lang/rust/pull/130739
[#130980]: https://github.com/rust-lang/rust/issues/130980
[#131059]: https://github.com/rust-lang/rust/issues/131059
[^1]: https://github.com/rust-lang/rust/issues/131059#issuecomment-2385822033
r? ``@onur-ozkan`` (or bootstrap)
|
|
Updated helper docs via configure.py to make it clearer that users can control options with enable and disable
|
|
This reverts commit 5a7058c5a542ec42d1fa9b524f7b4f7d6845d1e9.
In [#131059] we found out that `-Zon-broken-pipe=kill` is actually
**load-bearing** [1] for (at least) `rustc` and `rustdoc` to have the
kill-process-on-broken-pipe behavior, e.g. `rustc --print=sysroot |
false` will ICE and `rustdoc --print=sysroot | false` will panic on a
broken pipe.
[#131059]: https://github.com/rust-lang/rust/issues/131059
[1]: https://github.com/rust-lang/rust/issues/131059#issuecomment-2385822033
|
|
|
|
|
|
Add support for automatically setting up the recommended
LSP config for Emacs.
Additionally, refactor setup.rs to make it easier to add support
for more editors in the future.
|
|
|
|
Hook up std::net to wasi-libc on wasm32-wasip2 target
One of the improvements of the `wasm32-wasip2` target over `wasm32-wasip1` is better support for networking. Right now, p2 is just re-using the `std::net` implementation from p1. This PR adds a new net module for p2 that makes use of net from `sys_common` and calls wasi-libc functions directly.
There are currently a few limitations:
- Duplicating a socket is not supported by WASIp2 (directly returns an error)
- Peeking is not yet implemented in wasi-libc (we could let wasi-libc handle this, but I opted to directly return an error instead)
- Vectored reads/writes are not supported by WASIp2 (the necessary functions are available in wasi-libc, but they call WASIp1 functions which do not support sockets, so I opted to directly return an error instead)
- Getting/setting `TCP_NODELAY` is faked in wasi-libc (uses the fake implementation instead of returning an error)
- Getting/setting `SO_LINGER` is not supported by WASIp2 (directly returns an error)
- Setting `SO_REUSEADDR` is faked in wasi-libc (since this is done from `sys_common`, the fake implementation is used instead of returning an error)
- Getting/setting `IPV6_V6ONLY` is not supported by WASIp2 and will always be set for IPv6 sockets (since this is done from `sys_common`, wasi-libc will return an error)
- UDP broadcast/multicast is not supported by WASIp2 (since this is configured from `sys_common`, wasi-libc will return appropriate errors)
- The `MSG_NOSIGNAL` send flag is a no-op because there are no signals in WASIp2 (since explicitly setting this flag would require a change to `sys_common` and the result would be exactly the same, I opted to not set it)
Do those decisions make sense?
While working on this PR, I noticed that there is a `std::os::wasi::net::TcpListenerExt` trait that adds a `sock_accept()` method to `std::net::TcpListener`. Now that WASIp2 supports standard accept, would it make sense to remove this?
cc `@alexcrichton`
|
|
Rollup of 5 pull requests
Successful merges:
- #131023 (Copy correct path to clipboard for modules/keywords/primitives)
- #131035 (Preserve brackets around if-lets and skip while-lets)
- #131038 (Fix `adt_const_params` leaking `{type error}` in error msg)
- #131053 (Improve `--print=check-cfg` documentation)
- #131056 (enable compiler fingerprint logs in verbose mode)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
enable compiler fingerprint logs in verbose mode
This provides very useful logs especially when debugging build cache-related stuff.
|
|
Bump `cc` and run `cargo update` for bootstrap
Bump `cc` to 1.1.22, which includes a caching fix. Also run `cargo update` which does a minor increment on a few dependencies.
|
|
Fixes #96506
|
|
|
