Skip to content
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

Rollup of 7 pull requests #135789

Merged
merged 182 commits into from
Jan 20, 2025
Merged

Rollup of 7 pull requests #135789

merged 182 commits into from
Jan 20, 2025

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

Giga-Bowser and others added 30 commits January 6, 2025 15:30
…`Into<ast::Expr>`

This will help with specializing the various `make::expr_*` functions later
`expr_unit` is just a shortcut for a common expression, so it belongs in `make::ext`
`make::match_arm` should take a single `ast::Pat`, and callers can handle creating an `ast::OrPat` if need be. It should also take a proper `ast::MatchGuard`, instead of making one itself.
We should immediately mark them as finished, on the first entry.

The funny (or sad) part was that this bug was pre-existing, but previously to rust-lang#18327, it was causing us to generate bindings non-stop, 65535 of them, until we get to the hardcoded repetition limit, and then throw it all away. And it was so Blazingly Fast that nobody noticed.

With rust-lang#18327 however, this is still what happens, except that now instead of *merging* the fragments into the result, we write them on-demand. Meaning that when we hit the limit, we've already written all previous entries. This is a minor change, I thought for myself when I was writing this, and it's actually for the better, so who cares. Minor change? Not so fast. This caused us to emit 65535 repetitions, all of which the MBE infra needs to handle when calling other macros with the expansion, and convert to rowan tree etc., which resulted a *massive* hang.

The test (and also `analysis-stats`) used to crash with stack overflow on this macro, because we were dropping some crazily deep rowan tree. Now they work properly. Because I am lazy, and also because I could not find the exact conditions that causes a macro match but with a missing binding, I just copied all macros from tracing. Easy.
fix: Fix a bug with missing binding in MBE
internal: Migrate `if let` replacement assists to `SyntaxEditor`
fix: Fix `env`/`option_env` macro check disregarding macro_rules definitions
Also changes `make::expr_empty_block()` to return `ast::BlockExpr` instead of `ast::Expr`
It should be left biased, not right biased, because when e.g. the use has typed `h` then requested completion, the `h` is what we want to find, not the next token (which might indeed be inside a macro call).

I'm not sure why I wrote `right_biased()` to begin with (I remember I had a reason and not just "both should work"), I might've copied the code in `expand_and_analyze()` (which is wrong, because there it lookups on the speculative file, where right biased will always find the correct token and left biased not).

This is still not perfect, because there might not be an identifier already typed then we might still end up in a macro call, but this is the best we can do.
More correctly, *also* per-token. Because as it turns out, while the top-level edition affects parsing (I think), the per-token edition affects escaping of identifiers/keywords.
vayunbiyani and others added 13 commits January 20, 2025 09:15
Reexport likely/unlikely in std::hint

Since `likely`/`unlikely` should be working now, we could reexport them in `std::hint`. I'm not sure if this is already approved or if it requires approval

Tracking issue: rust-lang#26179
…printing, r=lqd

Respect --sysroot for rustc -vV and -Cpasses=list

This is necessary when the specified codegen backend is in a custom sysroot.

Fixes rust-lang#135165
…lfJung

Partial progress on rust-lang#132735: Replace extern "rust-intrinsic" with #[rustc_intrinsic] across the codebase

Part of rust-lang#132735: Replace `extern "rust-intrinsic"` with `#[rustc_intrinsic]` macro

- Updated all instances of `extern "rust-intrinsic"` to use the `#[rustc_intrinsic]` macro.
- Skipped `.md` files and test files to avoid unnecessary changes.
…manieu

Recognise new IPv6 documentation range from IETF RFC 9637

This PR adds the `3fff::/20` range defined by [IETF RFC 9637](https://datatracker.ietf.org/doc/rfc9637/) to those ranges which `Ipv6Addr::is_documentation` recognises as a documentation IP.

See also: https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
Unstable tracking issue: rust-lang#27709
…uting, r=Kobzol

Update contributing docs for submodule/subtree changes

Noticed in rust-lang#135337 (comment).

r? ``@Kobzol`` (or anyone really)
Subtree update of `rust-analyzer`

r? ``@ghost``
…bjorn3

Subtree sync for rustc_codegen_cranelift

Nothing too exciting this time, but this includes a fix for a linker hang on Windows: rust-lang/rustc_codegen_cranelift#1554

r? ``@ghost``

``@rustbot`` label +A-codegen +A-cranelift +T-compiler
@rustbot rustbot added A-meta Area: Issues & PRs about the rust-lang/rust repository itself S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler 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. rollup A PR which is a rollup labels Jan 20, 2025
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Jan 20, 2025

📌 Commit 67b609a has been approved by matthiaskrgr

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 20, 2025
@bors
Copy link
Contributor

bors commented Jan 20, 2025

⌛ Testing commit 67b609a with merge f3d1d47fd84dfcf7f513be1dbad356e74c8f3b2b...

@bors
Copy link
Contributor

bors commented Jan 20, 2025

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing f3d1d47 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jan 20, 2025
@bors bors merged commit f3d1d47 into rust-lang:master Jan 20, 2025
7 checks passed
@rustbot rustbot added this to the 1.86.0 milestone Jan 20, 2025
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#133695 Reexport likely/unlikely in std::hint b58c439f4b60706e02c183f783499b8875ad41d4 (link)
#135330 Respect --sysroot for rustc -vV and -Cpasses=list f7c8a68503e07a2c038349ec5fe43e7a25850254 (link)
#135333 Partial progress on #132735: Replace extern "rust-intrinsic… dde7f13e674f81e0ebbae2b50dc6b015ec19b659 (link)
#135741 Recognise new IPv6 documentation range from IETF RFC 9637 ceb061b79e5dbcd342d53e72aa6f354f43971b0e (link)
#135770 Update contributing docs for submodule/subtree changes 42740dc0a8f236f710a2a41caa62691a6c860fc8 (link)
#135775 Subtree update of rust-analyzer bf2fb10fa19e14fcb3aedd80a7b41bffcaab0eae (link)
#135776 Subtree sync for rustc_codegen_cranelift f37f48f150508517ffa1584763f65292eb83d73b (link)

previous master: 9f4d9dc102

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (f3d1d47): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

  • If the regression was expected or you think it can be justified,
    please write a comment with sufficient written justification, and add
    @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
  • If you think that you know of a way to resolve the regression, try to create
    a new PR with a fix for the regression.
  • If you do not understand the regression or you think that it is just noise,
    you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
    were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
0.1% [0.1%, 0.1%] 2
Improvements ✅
(primary)
-1.1% [-1.1%, -1.1%] 2
Improvements ✅
(secondary)
-0.5% [-0.6%, -0.5%] 2
All ❌✅ (primary) -1.1% [-1.1%, -1.1%] 2

Max RSS (memory usage)

Results (secondary -2.4%)

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.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.4% [-2.4%, -2.4%] 1
All ❌✅ (primary) - - 0

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 765.975s -> 764.999s (-0.13%)
Artifact size: 326.02 MiB -> 326.01 MiB (-0.00%)

@rustbot rustbot added the perf-regression Performance regression. label Jan 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-meta Area: Issues & PRs about the rust-lang/rust repository itself merged-by-bors This PR was explicitly merged by bors. perf-regression Performance regression. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.