Rollup of 11 pull requests #139842
Closed
Rollup of 11 pull requests #139842
+1,238
−91
Conversation
This file contains 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.
Co-authored-by: Ralf Jung <[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``
…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``
rustbot
added
A-testsuite
rustbot
added
T-compiler
bors
added
S-waiting-on-bors
|
@bors r- overlaps |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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-dirfor bootstrap self-tests #139783 (Usecompiletest-ignore-dirfor bootstrap self-tests)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup