Rollup of 16 pull requests #129802
Closed
Rollup of 16 pull requests #129802
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
Updates the wrapper for 5c4lar/llvm-project@21eddfa.
The test code did have an inference failure, but that would have failed on Rust 1.79 and earlier too. Now it is rewritten to be specifically affected by 1.80's `impl FromIterator<_> for Box<str>`.
This keeps it up-to-date by moving from 0.5.6 to 0.5.7. While here I've additionally updated some other wasm-related dependencies in the workspace to keep them up-to-date and try to avoid duplicate versions as well.
Several compiler functions have `Option<!>` for their return type.
That's odd. The only valid return value is `None`, so why is this type
used?
Because it lets you write certain patterns slightly more concisely. E.g.
if you have these common patterns:
```
let Some(a) = f() else { return };
let Ok(b) = g() else { return };
```
you can shorten them to these:
```
let a = f()?;
let b = g().ok()?;
```
Huh.
An `Option` return type typically designates success/failure. How should
I interpret the type signature of a function that always returns (i.e.
doesn't panic), does useful work (modifying `&mut` arguments), and yet
only ever fails? This idiom subverts the type system for a cute
syntactic trick.
Furthermore, returning `Option<!>` from a function F makes things
syntactically more convenient within F, but makes things worse at F's
callsites. The callsites can themselves use `?` with F but should not,
because they will get an unconditional early return, which is almost
certainly not desirable. Instead the return value should be ignored.
(Note that some of callsites of `process_operand`, `process_immedate`,
`process_assign` actually do use `?`, though the early return doesn't
matter in these cases because nothing of significance comes after those
calls. Ugh.)
When I first saw this pattern I had no idea how to interpret it, and it
took me several minutes of close reading to understand everything I've
written above. I even started a Zulip thread about it to make sure I
understood it properly. "Save a few characters by introducing types so
weird that compiler devs have to discuss it on Zulip" feels like a bad
trade-off to me. This commit replaces all the `Option<!>` return values
and uses `else`/`return` (or something similar) to replace the relevant
`?` uses. The result is slightly more verbose but much easier to
understand.
…=fmease rustdoc-json: Add test for `Self` type Inspired by rust-lang#128471, the rustdoc-json suite had no tests in place for the `Self` type. This PR adds one. I've also manually checked locally that this test passes on 29e9248, confirming that adding `clean::Type::SelfTy` didn't change the JSON output. (potentially adding a self type to json (insead of (ab)using generic) is tracked in rust-lang#128522) Updates rust-lang#81359 r? `````@fmease`````
…d, r=workingjubilee allow BufReader::peek to be called on unsized types rust-lang#128405
…r=fmease Deny imports of `rustc_type_ir::inherent` outside of type ir + new trait solver We shouldn't encourage using `rustc_type_ir::inherent` outside of the new solver[^1], though this can happen by accident due to rust-analyzer, for example. See rust-lang#127537 (comment) for an example in practice. r? fmease [^1]: Unless we go the fully radical approach of always using these inherent methods everywhere in favor of inherent methods, which would be a major overhaul of the compiler, IMO. I don't really want to consider that possibility right now, tho.
…r=lcnr
Simplify some extern providers
Simplifies some extern crate providers:
1. Generalize the `ProcessQueryValue` identity impl to work on non-`Option` types.
2. Allow `ProcessQueryValue` to wrap its output in an `EarlyBinder`, to simplify `explicit_item_bounds`/`explicit_item_super_predicates`.
3. Use `{ table }` and friends more when possible.
…-dead
Remove `Option<!>` return types.
Several compiler functions have `Option<!>` for their return type. That's odd. The only valid return value is `None`, so why is this type used?
Because it lets you write certain patterns slightly more concisely. E.g. if you have these common patterns:
```
let Some(a) = f() else { return };
let Ok(b) = g() else { return };
```
you can shorten them to these:
```
let a = f()?;
let b = g().ok()?;
```
Huh.
An `Option` return type typically designates success/failure. How should I interpret the type signature of a function that always returns (i.e. doesn't panic), does useful work (modifying `&mut` arguments), and yet only ever fails? This idiom subverts the type system for a cute syntactic trick.
Furthermore, returning `Option<!>` from a function F makes things syntactically more convenient within F, but makes things worse at F's callsites. The callsites can themselves use `?` with F but should not, because they will get an unconditional early return, which is almost certainly not desirable. Instead the return value should be ignored. (Note that some of callsites of `process_operand`, `process_immedate`, `process_assign` actually do use `?`, though the early return doesn't matter in these cases because nothing of significance comes after those calls. Ugh.)
When I first saw this pattern I had no idea how to interpret it, and it took me several minutes of close reading to understand everything I've written above. I even started a Zulip thread about it to make sure I understood it properly. "Save a few characters by introducing types so weird that compiler devs have to discuss it on Zulip" feels like a bad trade-off to me. This commit replaces all the `Option<!>` return values and uses `else`/`return` (or something similar) to replace the relevant `?` uses. The result is slightly more verbose but much easier to understand.
r? ```@cjgillot```
…ngjubilee f32 docs: define 'arithmetic' operations r? `@workingjubilee` Fixes rust-lang#129699
llvm-wrapper: adapt for LLVM API changes No functional changes intended. Updates the wrapper for 5c4lar/llvm-project@21eddfa. `@rustbot` label: +llvm-main r? `@nikic`
…ler-errors Add a test for trait solver overflow in MIR inliner cycle detection This test is a combination of the reproducer posted here: rust-lang#128887 (comment) and the existing test for polymorphic recursion: https:/rust-lang/rust/blob/784d444733d65c3d305ce5edcbb41e3d0d0aee2e/tests/mir-opt/inline/polymorphic_recursion.rs r? `@compiler-errors`
Make the "detect-old-time" UI test more representative The test code did have an inference failure, but that would have failed on Rust 1.79 and earlier too. Now it is rewritten to be specifically affected by 1.80's `impl FromIterator<_> for Box<str>`.
…-ld, r=jieyouxu Update the `wasm-component-ld` binary dependency This keeps it up-to-date by moving from 0.5.6 to 0.5.7. While here I've additionally updated some other wasm-related dependencies in the workspace to keep them up-to-date and try to avoid duplicate versions as well.
…g-4, r=jieyouxu Remove `#[macro_use] extern crate tracing`, round 4 Because explicit importing of macros via use items is nicer (more standard and readable) than implicit importing via #[macro_use]. Continuing the work from rust-lang#124511, rust-lang#124914, and rust-lang#125434. After this PR no `rustc_*` crates use `#[macro_use] extern crate tracing` except for `rustc_codegen_gcc` which is a special case and I will do separately. r? `@jieyouxu`
…g-remainder, r=GuillaumeGomez Remove `#[macro_use] extern crate tracing` from rustdoc and rustfmt A follow-up to rust-lang#129767 and earlier PRs doing this for `rustc_*` crates. r? `@GuillaumeGomez`
add crashtests for several old unfixed ICEs Adds several new crashtests for some older ICEs that did not yet have any. Tests were added for rust-lang#128097, rust-lang#119095, rust-lang#117460 and rust-lang#126443.
couple more crash tests r? `@jieyouxu`
mark joboet as on vacation I'll be on vacation for about three weeks and won't have much time for reviewing. r? `@ghost`
rustbot
added
A-meta
|
@bors r+ rollup=never p=16 |
|
🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened. |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Aug 31, 2024
…kingjubilee Rollup of 16 pull requests Successful merges: - rust-lang#129123 (rustdoc-json: Add test for `Self` type) - rust-lang#129675 (allow BufReader::peek to be called on unsized types) - rust-lang#129678 (Deny imports of `rustc_type_ir::inherent` outside of type ir + new trait solver) - rust-lang#129723 (Simplify some extern providers) - rust-lang#129724 (Remove `Option<!>` return types.) - rust-lang#129725 (Stop using `ty::GenericPredicates` for non-predicates_of queries) - rust-lang#129730 (f32 docs: define 'arithmetic' operations) - rust-lang#129749 (llvm-wrapper: adapt for LLVM API changes) - rust-lang#129757 (Add a test for trait solver overflow in MIR inliner cycle detection) - rust-lang#129760 (Make the "detect-old-time" UI test more representative) - rust-lang#129762 (Update the `wasm-component-ld` binary dependency) - rust-lang#129767 (Remove `#[macro_use] extern crate tracing`, round 4) - rust-lang#129774 (Remove `#[macro_use] extern crate tracing` from rustdoc and rustfmt) - rust-lang#129780 (add crashtests for several old unfixed ICEs) - rust-lang#129782 (couple more crash tests) - rust-lang#129791 (mark joboet as on vacation) r? `@ghost` `@rustbot` modify labels: rollup
|
The job Click to see the possible cause of the failure (guessed by this bot) |
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:
Selftype #129123 (rustdoc-json: Add test forSelftype)rustc_type_ir::inherentoutside of type ir + new trait solver #129678 (Deny imports ofrustc_type_ir::inherentoutside of type ir + new trait solver)Option<!>return types. #129724 (RemoveOption<!>return types.)ty::GenericPredicatesfor non-predicates_of queries #129725 (Stop usingty::GenericPredicatesfor non-predicates_of queries)wasm-component-ldbinary dependency #129762 (Update thewasm-component-ldbinary dependency)#[macro_use] extern crate tracing, round 4 #129767 (Remove#[macro_use] extern crate tracing, round 4)#[macro_use] extern crate tracingfrom rustdoc and rustfmt #129774 (Remove#[macro_use] extern crate tracingfrom rustdoc and rustfmt)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup