| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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
|
|
|
|
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.
|
|
Rollup of 4 pull requests
Successful merges:
- #130895 (make type-check-4 asm tests about non-const expressions)
- #131057 (Reject leading unsafe in `cfg!(...)` and `--check-cfg`)
- #131060 (Drop conditionally applied cargo `-Zon-broken-pipe=kill` flags to fix stage 1 cargo rebuilds)
- #131061 (replace manual verbose checks with `Config::is_verbose`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
replace manual verbose checks with `Config::is_verbose`
self-explanatory
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
These conditionally applied flags trigger rebuilds because they can
invalidate previous cargo build cache.
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
r=Mark-Simulacrum
check if it's rust-lang/rust CI job in `llvm::is_ci_llvm_modified`
Changes `llvm::is_ci_llvm_modified` to only work on rust-lang/rust managed CI.
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
simplify LLVM submodule handling
Fixes #130906.
|
|
Bump `cc` to 1.1.22, which includes a caching fix. Also run `cargo
update` which does a minor increment on a few dependencies.
|
|
delete sub build directory "debug" to not delete the change-id file
Fixes #130449
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Add the library workspace to the suggested rust-analyzer config
|
|
Previously if you pass compiler stage 1 to `tool::Cargo`, it will build
stage2 rustc and give you back a cargo built with stage2 rustc, which is
not what we want.
This commit adds a hack that chops off a stage from the compiler passed
to `tool::Cargo`, meaning that we will get a cargo built with stage 1
compiler, avoiding unnecessary and incorrect build of stage2 rustc and
the cargo built by that.
|
|
And stop passing `BOOTSTRAP_CARGO` as an env var, instead the provided
cargo should go through `--cargo-path.`
|
|
remove workaround for make prepare and use dry-run build instead
Removes an annoying hard-coded logic.
try-job: x86_64-msvc
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
bootstrap: Set the dylib path when building books with rustdoc
The library path is needed when the toolchain has been configured with
`[rust] rpath = false`. Otherwise, building the reference book will get
an error when it tries to run rustdoc, like:
rustdoc: error while loading shared libraries: librustc_driver-2ec457c3b8826b72.so
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
move enzyme flags from general cargo to rustc-specific cargo
Resolves #130637.
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
A couple tests were using `BOOTSTRAP_CARGO` with `-Zbuild-std`, but that
stage0 cargo might not always be in sync with in-tree changes. In
particular, those tests started failing on the beta branch because the
older cargo couldn't find the library `Cargo.lock`, and then couldn't
build the latest version of `compiler_builtins` that had nightly changes.
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
change `download-ci-llvm` default from `if-unchanged` to `true`
Since https://github.com/rust-lang/rust/pull/129473 and https://github.com/rust-lang/rust/pull/130202, using `download-ci-llvm=true` is now the better default and it also fixes #130515.
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Bump cc dependency
* The [issue](https://github.com/rust-lang/rust/issues/130231) was fixed in the [PR](https://github.com/rust-lang/cc-rs/pull/1207)
* The build artifacts of arm64e-apple-darwin can be found [here](https://github.com/arttet/rust-compiler-builder/actions/runs/10902308425)
|
|
The library path is needed when the toolchain has been configured with
`[rust] rpath = false`. Otherwise, building the reference book will get
an error when it tries to run rustdoc, like:
rustdoc: error while loading shared libraries: librustc_driver-2ec457c3b8826b72.so
|
|
|
|
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Register tool docs for `src/tools/build_helper`
Fixes #130355.
|
|
simplify `Build::update_existing_submodule`
`Build::update_existing_submodule` is already doing the same thing..
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
