Rollup of 10 pull requests #129805
Closed
Rollup of 10 pull requests #129805
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
Inspired by discussion on rust-lang#129486 this is intended to at least document the current state of the world in a more public location than throughout a series of issues.
Updates the wrapper for 5c4lar/llvm-project@21eddfa.
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``````
…-on-wasm32-u-u, r=workingjubilee Document the broken C ABI of `wasm32-unknown-unknown` Inspired by discussion on rust-lang#129486 this is intended to at least document the current state of the world in a more public location than throughout a series of issues.
…d, r=workingjubilee allow BufReader::peek to be called on unsized types rust-lang#128405
…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```` …mease Stop using `ty::GenericPredicates` for non-predicates_of queries `GenericPredicates` is a struct of several parts: A list of of an item's own predicates, and a parent def id (and some effects related stuff, but ignore that since it's kinda irrelevant). When instantiating these generic predicates, it calls `predicates_of` on the parent and instantiates its predicates, and appends the item's own instantiated predicates too: https://github.com/rust-lang/rust/blob/acb4e8b6251f1d8da36f08e7a70fa23fc581839e/compiler/rustc_middle/src/ty/generics.rs#L407-L413 Notice how this should result in a recursive set of calls to `predicates_of`... However, `GenericPredicates` is *also* misused by a bunch of *other* queries as a convenient way of passing around a list of predicates. For these queries, we don't ever set the parent def id of the `GenericPredicates`, but if we did, then this would be very easy to mistakenly call `predicates_of` instead of some other intended parent query. Given that footgun, and the fact that we don't ever even *use* the parent def id in the `GenericPredicates` returned from queries like `explicit_super_predicates_of`, It really has no benefit over just returning `&'tcx [(Clause<'tcx>, Span)]`. This PR additionally opts to wrap the results of `EarlyBinder`, as we've tended to use that in the return type of these kinds of queries to properly convey that the user has params to deal with, and it also gives a convenient way of iterating over a slice of things after instantiating.
…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``
…-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.
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 
Member Author
| @bors r+ rollup=never p=10 |
Collaborator
bors added S-waiting-on-bors 
Member
| partially merged already in #129809 |
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
12 participants
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)wasm32-unknown-unknown#129630 (Document the broken C ABI ofwasm32-unknown-unknown)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)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup