Rollup of 15 pull requests #129809
Merged
Rollup of 15 pull requests #129809
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
This shouldn't affect projects indirectly depending on wasm-bindgen because cargo passes `--cap-lints=allow` when building dependencies.
It should be 0.3.74~ish. This should help with backtraces on Android, QNX NTO 7.0, and Windows.
Previously `libname.a` naming was supported as a fallback when producing rlibs, but not when producing executables or dynamic libraries
This commit fixes an assert in the WASI-specific implementation of thread sleep to ensure that sleeping for a very large period of time blocks instead of panicking. This can come up when testing programs that sleep "forever", for example.
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.
…-patterns, r=nnethercote Don't make statement nonterminals match pattern nonterminals Right now, the heuristic we use to check if a token may begin a pattern nonterminal falls back to `may_be_ident`: https://github.com/rust-lang/rust/blob/ef71f1047e04438181d7cb925a833e2ada6ab390/compiler/rustc_parse/src/parser/nonterminal.rs#L21-L37 This has the unfortunate side effect that a `stmt` nonterminal eagerly matches against a `pat` nonterminal, leading to a parse error: ```rust macro_rules! m { ($pat:pat) => {}; ($stmt:stmt) => {}; } macro_rules! m2 { ($stmt:stmt) => { m! { $stmt } }; } m2! { let x = 1 } ``` This PR fixes it by more accurately reflecting the set of nonterminals that may begin a pattern nonterminal. As a side-effect, I modified `Token::can_begin_pattern` to work correctly and used that in `Parser::nonterminal_may_begin_with`.
…z,notriddle Separate core search logic with search ui Currenty, the `search.js` mixed with UI/DOM manipulation codes and search logic codes, I propose to extract the search logic to a class for following benefits: - Clean code. Separation of DOM manipulation and search logic can lead better code maintainability and easy code testings. - Easy share the search logic for third party to utilize the search function, such as [Rust Search Extension](https://rust.extension.sh), https://query.rs. This PR added a new class called `DocSearch`, which mainly expose following methods: ```js class DocSearch { // Dependency inject searchIndex, rootPath and searchState constructor(rawSearchIndex, rootPath, searchState) { // build search index... } static parseQuery(userQuery) { } async execQuery(parsedQuery, filterCrates, currentCrate) { } } ```
…=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````````
linker: Synchronize native library search in rustc and linker Also search for static libraries with alternative naming (`libname.a`) on MSVC when producing executables or dynamic libraries, and not just rlibs. This unblocks rust-lang#123436. try-job: x86_64-msvc
Don't use `TyKind` in a lint Allows us to remove an inherent method from `TyKind` from the type ir crate.
…fcw-to-deny, r=daxpedda,alexcrichton Deny `wasm_c_abi` lint to nudge the last 25% This shouldn't affect projects indirectly depending on wasm-bindgen because cargo passes `--cap-lints=allow` when building dependencies. The motivation is that the ecosystem has mostly taken up the versions of wasm-bindgen that are compatible in general, but ~25% or so of recent downloads remain on lower versions. However, this change might still be unnecessarily disruptive. I mostly propose it as a discussion point.
…, r=tgross35 Re-enable android tests/benches in alloc/core This is basically a revert of rust-lang#73729. These tests better work on android now; it's been 4 years and we don't use dlmalloc on that target anymore. And I've validated that they should pass now with a try-build :)
…b22, r=workingjubilee Bump backtrace to 0.3.74~ish Commit: rust-lang/backtrace-rs@230570f This should help with backtraces on Android, QNX NTO 7.0, and Windows. It addresses a case of backtrace incurring undefined behavior on Android.
…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``````
rustbot
added
T-libs
|
@bors r+ rollup=never p=15 |
bors
added
S-waiting-on-bors
|
there we go |
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: fa72f0763d In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Aug 31, 2024
This was referenced Aug 31, 2024
|
Finished benchmarking commit (9649706): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)Results (primary 0.1%, secondary -0.1%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (primary -0.4%, secondary -0.2%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResults (primary 0.3%, secondary 0.0%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 789.792s -> 788.814s (-0.12%) |
|
The @rustbot label: +perf-regression-triaged |
rustbot
added
the
perf-regression-triaged
# for free
to join this conversation on GitHub.
Already have an account?
# 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)TyKindin a lint #129527 (Don't useTyKindin a lint)wasm_c_abilint to nudge the last 25% #129534 (Denywasm_c_abilint to nudge the last 25%)Option<!>return types. #129724 (RemoveOption<!>return types.)ty::GenericPredicatesfor non-predicates_of queries #129725 (Stop usingty::GenericPredicatesfor non-predicates_of queries)./x.py test compiler#129731 (Allow running./x.py test compiler)Duration::MAX#129754 (wasi: Fix sleeping forDuration::MAX)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup