Add batch flag to remote-test-server
When using this flag, the stdout and stderr are sent in a single batch instead of being streamed. It also used `Command::output` instead of `Command::spawn`. This is useful for targets that might support std but not threading (Eg: UEFI).
Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
Don't copy symbols from dylibs with `-Zdylib-lto`
When `rustc_driver` started being built with `-Zdylib-lto -Clto=thin`, some libstd symbols were copied by the LTO process into the dylib. That causes duplicate local symbols that are not present otherwise.
Depending on the situation (lib loading order apparently), the duplicated symbols could cause issues: `rustc_driver` overrode the panic hook, but it didn't apply to rustc main's hook (the default from libstd). This is the cause of #105637, in some situations the panic hook installed by `rustc_driver` isn't executed, and only libstd's backtrace is shown (and a double panic). The query stack, as well as the various notes to open a GH about the ICE, don't appear.
It's not clear exactly what is needed to trigger the issue, but I have simulated a reproducer [here](https://github.com/lqd/issue-105637) with cargo involved, the incorrect panic hook is executed on my machine. It is hard to reproduce in a unit test: `cargo run` + `rustup` involves LD_LIBRARY_PATH, which is not the case for `compiletest`. cargo also adds unconditional flags that are then overridden in [`bootstrap` when building rustc with `rust.lto = thin`](9c07efe84f/src/bootstrap/compile.rs (L702-L714)) as done on CI).
All this to say the compilation and execution environment in `bootstrap` leading to the bug building `rustc_driver` is different from our UI tests, and I believe one of the reasons it's hard to make an exact reproducer test. Thankfully there's _still_ a difference in the behavior though: although in the unit test the correct panic hook seems to be executed compared to my repro and the current nightly, only the fix removes the double panic here.
The `7e8277aefa12f1469fb1df01418ff5846a7854a9` `try` build:
- fixes the reproducer repo linked above
- restores the ICE messages from https://github.com/rust-lang/rust/issues/105321 back to the state in its OP compared to the description in https://github.com/rust-lang/rust/issues/105637
- restores the ICE message and the query stack from https://github.com/rust-lang/rust/issues/105777 compared to nightly
While I believe this technically fixes the P-critical issue https://github.com/rust-lang/rust/issues/105637, I would not want to close it yet as we may want to backport to beta/stable (if a point release happens, it would fix the ICEs reported on 1.66.0, which is built with ThinLTO on linux). Once this PR lands, I'll also open another PR to re-enable ThinLTO on x64 darwin's dist builder.
Rustup
r? `@ghost`
I'm on the train and my internet is too bad to download the necessary toolchain, so I have to use CI to find sync fallout.
changelog: none
<!-- changelog_checked -->
fix: not suggest seek_to_start_instead_of_rewind when expr is used
changelog: [`seek_to_start_instead_of_rewind`]: No longer lints, if the return of `seek` is used.
[#10096](https://github.com/rust-lang/rust-clippy/pull/10096)
<!-- changelog_checked -->
Fixes#10065
fix logic in IncrementVisitor
There used to be a logical bug where IncrementVisitor would completely stop checking an expression/block after seeing a continue statement.
I am a little unsure of whether my fix to `IncrementVisitor` is logically sound (I hope it makes sense). Let me know what you think, and thanks in advance for the review!
fixes#10058
---
changelog: FP: [`explicit_counter_loop`]: No longer ignores counter changes after `continue` expressions
[#10094](https://github.com/rust-lang/rust-clippy/pull/10094)
<!-- changelog_checked -->
core: ensure `no_fp_fmt_parse` builds are warning-free
Rust recently introduced a new `unused_imports` warning in `no_fp_fmt_parse` builds, which was fixed in
https://github.com/rust-lang/rust/pull/105434.
To avoid accumulating more over time, let's keep the builds warning-free. This ensures projects compiling `core` with this custom config do not see the warnings in the future and that they can keep enabling `-Dwarnings`.
Similarly, https://github.com/rust-lang/rust/pull/98652 did it for `alloc`'s `no_global_oom_handling`.
Rollup of 6 pull requests
Successful merges:
- #105493 (Help rust-analyzer normalize query return types)
- #105710 (Don't bug if we're trying to cast `dyn*` to another type)
- #105711 (bail in `collect_trait_impl_trait_tys` if signatures reference errors)
- #105768 (Detect inherent associated types not having CamelCase)
- #105780 (rustdoc: Don't add "Read more" link if there is no extra content)
- #105802 (Make enum-match.rs test robust against variable name changes)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Make enum-match.rs test robust against variable name changes
https://reviews.llvm.org/D140192 caused the LLVM variable generated for enum discriminant checks to be named differently (%narrow vs %1).
This adjusts the test CHECK directives to match any name.
Rust recently introduced a new `unused_imports` warning
in `no_fp_fmt_parse` builds, which was fixed in
https://github.com/rust-lang/rust/pull/105434.
To avoid accumulating more over time, let's keep the builds
warning-free. This ensures projects compiling `core` with
this custom config do not see the warnings in the future
and that they can keep enabling `-Dwarnings`.
Similarly, https://github.com/rust-lang/rust/pull/98652 did it
for `alloc`'s `no_global_oom_handling`.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
https://reviews.llvm.org/D140192 caused the LLVM variable generated
for enum discriminant checks to be named differently (%narrow vs %1).
This adjusts the test CHECK directives to match any name.
Stabilize default_alloc_error_handler
Tracking issue: #66741
This turns `feature(default_alloc_error_handler)` on by default, which causes the compiler to automatically generate a default OOM handler which panics if `#[alloc_error_handler]` is not provided.
The FCP completed over 2 years ago but the stabilization was blocked due to an issue with unwinding. This was fixed by #88098 so stabilization can be unblocked.
Closes#66741
Implement DerefMut for PathBuf
Without this, there's no way to get a `&mut Path` from `PathBuf` without
going through `into_boxed_path`. This is relevant now that #105002 adds
`PathBuf::as_mut_os_string` and `Path::as_mut_os_str`.
There used to be a logical bug where IncrementVisitor would
completely stop checking an expression/block after seeing a continue
statement. This led to issue #10058 where a variable incremented
(or otherwise modified) after any continue statement would still be
considered incremented only once.
The solution is to continue scanning the expression after seeing a
`continue` statement, but increment self.depth so that the Visitor
thinks that the rest of the loop is within a conditional.
rustdoc: simplify CSS for codeblock tooltips
Instead of making its parts `display: none` and then changing it on hover, just make the pseudo-element itself on hover.
doc: Fix a few small issues
Hey, while reading through the (awesome) stdlib docs, I found a few minor typos.
* A few typos around generic types (`;` vs `,`)
* Use inline code formatting for code fragments
* One instance of wrong wording
Rewrite `E0158` error-code docs for clarity
Fixes#105585.
The `E0158` error-code docs are unclear. It doesn't explain all three different variants of the error and doesn't explain *why* the error occurs. This PR cleans it up a bit and brings it properly into line with [RFC1567](https://rust-lang.github.io/rfcs/1567-long-error-codes-explanation-normalization.html).
I'm a first time Rust contributor so I've probably not got it quite right. I also haven't run the whole build process because I assume that my minor docs changes shouldn't break everything.
