-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Rollup of 12 pull requests #139837
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Rollup of 12 pull requests #139837
+1,496
−93
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Use `const_eval_select!()` macro to enable contract checking only at runtime. The existing contract logic relies on closures, which are not supported in constant functions. This commit also removes one level of indirection for ensures clauses, however, it currently has a spurious warning message when the bottom of the function is unreachable.
Invert the order that we pass the arguments to the `contract_check_ensures` function to avoid the warning when the tail of the function is unreachable. Note that the call itself is also unreachable, but we have already handled that case by ignoring unreachable call for contract calls.
`#[target_feature]` attributes refer to a target-specific list of features. Enabling certain features can imply enabling other features. Certain features are always enabled on certain targets, since they are required by the target's ABI. Features can also be enabled indirectly based on other compiler flags. Feature information is ultimately known to `rustc`. Rather than force external tools to track it -- which may be wildly impractical due to `-C target-cpu` -- have `rustdoc` output `rustc`'s feature data.
Co-authored-by: Ralf Jung <[email protected]>
Co-authored-by: Predrag Gruevski <[email protected]>
so the merging step doesn't fail for `opt-dist local` on Windows
According to the docs in `Command::output`: > By default, stdout and stderr are captured (and used to provide the resulting output). Stdin is not inherited from the parent and any attempt by the child process to read from the stdin stream will result in the stream immediately closing. This was being violated by UEFI which was inheriting stdin by default. While the docs don't explicitly state that the default should be NULL, the behaviour seems like reading from NULL. UEFI however, has a bit of a problem. The `EFI_SIMPLE_TEXT_INPUT_PROTOCOL` only provides support for reading 1 key press. This means that you either get an error, or it is assumed that the keypress was read successfully. So there is no way to have a successful read of length 0. Currently, I am returning UNSUPPORTED error when trying to read from NULL stdin. On linux however, you will get a read of length 0 for Null stdin. One possible way to get around this is to translate one of the UEFI errors to a read 0 (Maybe unsupported?). It is also possible to have a non-standard error code, but well, not sure if we go that route. Alternatively, if meaning of Stdio::Null is platform dependent, it should be fine to keep the current behaviour of returning an error. Signed-off-by: Ayush Singh <[email protected]>
Allows implementing Stdio::Null for Command in a deterministic manner. Signed-off-by: Ayush Singh <[email protected]>
Stdio::MakePipe is not supported. For Stdio::Null, return UNSUPPORTED. This is treated as read(0). Additionally, have infinte loop on the notify function to prevent wait_for_key from returning. Signed-off-by: Ayush Singh <[email protected]>
Avoid cloning in `Cloned<I>` or copying in `Copied<I>` when elements are only needed by reference or not at all. There is already some precedent for this, given that `__iterator_get_unchecked` is implemented, which can skip elements. The reduced clones are technically observable by a user impl of `Clone`.
Ubuntu 25.04 has `llvm-20` packages that we can start testing with. The `Dockerfile` is otherwise the same as the `llvm-18`/`19` runners.
approved in ACP rust-lang/libs-team#554
…ct, r=compiler-errors,oli-obk,RalfJung Enable contracts for const functions Use `const_eval_select!()` macro to enable contract checking only at runtime. The existing contract logic relies on closures, which are not supported in constant functions. This commit also removes one level of indirection for ensures clauses since we no longer build a closure around the ensures predicate. Resolves rust-lang#136925 **Call-out:** This is still a draft PR since CI is broken due to a new warning message for unreachable code when the bottom of the function is indeed unreachable. It's not clear to me why the warning wasn't triggered before. r? `@compiler-errors`
ci: add runners for vanilla LLVM 20 Ubuntu 25.04 has `llvm-20` packages that we can start testing with. The `Dockerfile` is otherwise the same as the `llvm-18`/`19` runners. try-job: x86_64-gnu-llvm-20-1 try-job: x86_64-gnu-llvm-20-2 try-job: x86_64-gnu-llvm-20-3
…=BoxyUwU Allow const patterns of matches to contain pattern types Trying to pattern match on a type containing a pattern type will currently fail with an ICE ```rust error: internal compiler error: compiler/rustc_mir_build/src/builder/matches/test.rs:459:18: invalid type for non-scalar compare: (u32) is 1.. --> src/main.rs:22:5 | 22 | TWO => {} | ^^^ ``` because the compiler tries to generate a MIR `BinOp(Eq)` operation on a pattern type, which is not supported. While we could support that, there are side effects of allowing this (none that would compile, but the compiler would simultaneously think it could `==` pattern types and that it could not because `PartialEq` is not implemented. So instead I change the logic for pattern matching to transmute pattern types to their base type before comparing. r? `@BoxyUwU` cc rust-lang#123646 `@scottmcm` `@joshtriplett`
…ature_information, r=aDotInTheVoid rustdoc-json: Output target feature information `#[target_feature]` attributes refer to a target-specific list of features. Enabling certain features can imply enabling other features. Certain features are always enabled on certain targets, since they are required by the target's ABI. Features can also be enabled indirectly based on other compiler flags. Feature information is ultimately known to `rustc`. Rather than force external tools to track it – which may be wildly impractical due to `-C target-cpu` – have `rustdoc` output `rustc`'s feature data. This change is motivated by obi1kenobi/cargo-semver-checks#1246, which intends to detect semver hazards caused by `#[target_feature]`.
…oboet std: sys: process: uefi: Use NULL stdin by default According to the docs in `Command::output`: > By default, stdout and stderr are captured (and used to provide the resulting output). Stdin is not inherited from the parent and any attempt by the child process to read from the stdin stream will result in the stream immediately closing. This was being violated by UEFI which was inheriting stdin by default. While the docs don't explicitly state that the default should be NULL, the behaviour seems like reading from NULL. UEFI however, has a bit of a problem. The `EFI_SIMPLE_TEXT_INPUT_PROTOCOL` only provides support for reading 1 key press. This means that you either get an error, or it is assumed that the keypress was read successfully. So there is no way to have a successful read of length 0. Currently, I am returning UNSUPPORTED error when trying to read from NULL stdin. On linux however, you will get a read of length 0 for Null stdin. One possible way to get around this is to translate one of the UEFI errors to a read 0 (Maybe unsupported?). It is also possible to have a non-standard error code, but well, not sure if we go that route. Alternatively, if meaning of Stdio::Null is platform dependent, it should be fine to keep the current behaviour of returning an error. cc `@nicholasbishop` `@dvdhrm`
…=tgross35 std: add Output::exit_ok approved in ACP rust-lang/libs-team#554 Tracking issue: rust-lang#84908
…, r=joboet Avoid unused clones in `Cloned<I>` and `Copied<I>` Avoid cloning in `Cloned<I>` or copying in `Copied<I>` when elements are only needed by reference or not at all. There is already some precedent for this, given that `__iterator_get_unchecked` is implemented, which can skip elements. The reduced clones are technically observable by a user impl of `Clone`. r? libs-api
opt-dist: use executable-extension for host llvm-profdata because it's used for target llvm-profdata too r? Kobzol
…lcnr Add test for issue 34834 closes: rust-lang#34834 This PR adds a UI test for a case where a trait with an associated type using a higher-ranked trait bound (HRTB) failed to compile in Rust 1.55.0 but succeeded starting from 1.56.0. ```rust pub trait Provides<'a> { type Item; } pub trait Selector: for<'a> Provides<'a> { type Namespace: PartialEq + for<'a> PartialEq<<Self as Provides<'a>>::Item>; fn get_namespace(&self) -> <Self as Provides>::Item; } pub struct MySelector; impl<'a> Provides<'a> for MySelector { type Item = &'a str; } impl Selector for MySelector { type Namespace = String; fn get_namespace(&self) -> &str { unimplemented!() } } fn main() {} ``` * ❌ [compile fail (rustc: 1.55.0)](https://godbolt.org/z/T1jY1Ebo6) * ⭕ [compile pass (rustc: 1.56.0)](https://godbolt.org/z/e4jo11Ma7)
Use `compiletest-ignore-dir` for bootstrap self-tests Follow-up to rust-lang#139705 and rust-lang#139740. I did another survey pass over `//@ ignore-test` under `tests/`, and this is the only 2 non-tests that should use `compiletest-ignore-dir`. r? ``@Zalathar`` (or compiler/bootstrap)
…=compiler-errors do not unnecessarily leak auto traits in item bounds fixes rust-lang/trait-system-refactor-initiative#158 Not a fix for rust-lang/trait-system-refactor-initiative#173 as you may have realized/tried yourself, cc rust-lang#139788. However, fixing this feels desirable regardless and I don't see any reason not to. r? `@compiler-errors`
…=compiler-errors drop global where-bounds before merging candidates fixes rust-lang/trait-system-refactor-initiative#172 r? `@compiler-errors`
@bors r+ rollup=never p=5 |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 15, 2025
Rollup of 12 pull requests Successful merges: - rust-lang#138374 (Enable contracts for const functions) - rust-lang#138380 (ci: add runners for vanilla LLVM 20) - rust-lang#138393 (Allow const patterns of matches to contain pattern types) - rust-lang#139393 (rustdoc-json: Output target feature information) - rust-lang#139517 (std: sys: process: uefi: Use NULL stdin by default) - rust-lang#139554 (std: add Output::exit_ok) - rust-lang#139745 (Avoid unused clones in `Cloned<I>` and `Copied<I>`) - rust-lang#139757 (opt-dist: use executable-extension for host llvm-profdata) - rust-lang#139778 (Add test for issue 34834) - rust-lang#139783 (Use `compiletest-ignore-dir` for bootstrap self-tests) - rust-lang#139789 (do not unnecessarily leak auto traits in item bounds) - rust-lang#139791 (drop global where-bounds before merging candidates) r? `@ghost` `@rustbot` modify labels: rollup
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-compiletest
Area: The compiletest test runner
A-rustdoc-json
Area: Rustdoc JSON backend
A-testsuite
Area: The testsuite used to check the correctness of rustc
rollup
A PR which is a rollup
S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-infra
Relevant to the infrastructure team, which will review and decide on the PR/issue.
T-libs
Relevant to the library team, which will review and decide on the PR/issue.
T-rustdoc
Relevant to the rustdoc team, which will review and decide on the PR/issue.
WG-trait-system-refactor
The Rustc Trait System Refactor Initiative (-Znext-solver)
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
Cloned<I>
andCopied<I>
#139745 (Avoid unused clones inCloned<I>
andCopied<I>
)compiletest-ignore-dir
for bootstrap self-tests #139783 (Usecompiletest-ignore-dir
for bootstrap self-tests)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup