I have verified that the test fails if stderr begins to contain output
by making sure the test fails when I add
eprintln!("some output on stderr");
to the compiler (I added it to `fn build_session()`).
style-guide: don't flatten match arms with macro call
This pulls forward the gist of the text that was added to the style guide in https://github.com/rust-lang/style-team/pull/159 to account for needing to tweak/soften rustfmt's behavior based on the style guide prescriptions.
There were a few options I considered, noted below, and although I don't particularly love any of them, I felt this was the lesser of the evils.
r? `@joshtriplett`
Move two tests from `tests/ui/std` to `library/std/tests`
Hi, there,
This pull request comes from this issue (#99417), sorry I made some mistakes creating the pull request, it's my first one.
Less `TokenTree` cloning
`TokenTreeCursor` has this comment on it:
```
// FIXME: Many uses of this can be replaced with by-reference iterator to avoid clones.
```
This PR completes that FIXME. It doesn't have much perf effect, but at least we now know that.
r? `@petrochenkov`
Regression test `println!()` panic message on `ErrorKind::BrokenPipe`
No existing test (that I could find) failed if the `panic!()` of the `println!()` family of functions was removed, or if its message was changed:
104f4300cf/library/std/src/io/stdio.rs (L1007-L1009)
So add such a test.
This is in preparation of adding a hint about the existence of [`unix_sigpipe`](https://github.com/rust-lang/rust/issues/97889) if that is the reason for the panic.
Even if we don't end up adding a hint, this is still a sensible test to have, I think.
`@rustbot` label +A-testsuite +A-io +T-libs +O-unix
Revert "add tidy check that forbids issue ui test filenames"
This reverts commit 13e2abf6b3.
Reverting because an MCP was requested and it turned out there was a lack of a consensus on what to do in this area.
tests/ui/hello_world/main.rs: Remove FIXME (#62277)
The purpose of the test is to make sure that compiling hello world produces no compiler output. To properly test that, we need to run the entire compiler pipeline. We don't want the test to pass if codegen accidentally starts writing to stdout. So keep it as build-pass.
Part of #62277
Now `option_env_unwrap` warns even if a variable isn't set at compiletime
Fixes#10742
changelog: Fix false negative where `option_env_unwrap` wouldn't warn if the env variable isn't set at compile-time.
Build the first LLVM without LTO in try builds
Currently, we perform three LLVM builds in the Linux x64 dist builder, which is used for `try` builds:
1) "Normal" LLVM - takes ~5s to compile thanks to `sccache`, but ~8 minutes to link because of ThinLTO
2) PGO instrumented LLVM - same timings as 1)
3) PGO optimized LLVM - takes about 20 minutes to build
When I tried to disable LTO for build 1), it suddenly takes only about a minute to build, because the linking step is much faster. The first LLVM doesn't really need LTO all that much. Without it, it will be a bit slower to build `rustc` in two subsequent steps, but it seems that the ~7 minutes saved on linking it do win that back.
Btw, we can't use the host LLVM for build 1), because this LLVM then builds `rustc` in PGO instrumented mode, and we need the same compiler when later PGO optimizing `rustc`. And we want to use our in-house LLVM for that I think.
[rustdoc] If re-export is private, get the next item until a public one is found or expose the private item directly
Fixes#81141.
If we have:
```rust
use Private as Something;
pub fn foo() -> Something {}
```
Then `Something` will be replaced by `Private`.
r? `@notriddle`
Turns out opaque types can have hidden types registered during mir validation
See the newly added test's documentation for an explanation.
fixes#114121
Restore region uniquification in the new solver 🎉
All of the bugs that were "due" to uniquification have been settled via other means (e.g. bidirectional alias-relate, param-env incompleteness, etc).
Firstly, revert the functional changes in #110180. 😸
Secondly, we need to ignore regions when considering if a goal has changed (the "has_changed" boolean returned from `evaluate_goal`) -- otherwise, because we're doing region uniquification, we may perpetually consider a goal to be changed. See the UI test I committed for an explanation.
