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 8 pull requests #135788

Closed
wants to merge 186 commits into from
Closed

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.
jieyouxu and others added 15 commits January 20, 2025 21:53
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.
…crum

bump compiler and tools to windows 0.59, bootstrap to 0.57

This bumps compiler and tools to windows 0.59 (temporary dupes version, as `sysinfo` still depend on <= 0.57).
Bootstrap bumps only to 0.57 (the same sysinfo dep).

This additionally resolves my comment rust-lang#130874 (comment)

Will work on it in follow up pr: There still some sus imports for `rustc_driver.dll` like ws2_32 or RoOriginateErrorW, but i will look at them later.
…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-compiletest Area: The compiletest test runner A-meta Area: Issues & PRs about the rust-lang/rust repository itself A-testsuite Area: The testsuite used to check the correctness of rustc A-tidy Area: The tidy tool S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) 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=6

@bors
Copy link
Contributor

bors commented Jan 20, 2025

📌 Commit 7dedd8d 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
@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain)

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
Labels
A-compiletest Area: The compiletest test runner A-meta Area: Issues & PRs about the rust-lang/rust repository itself A-testsuite Area: The testsuite used to check the correctness of rustc A-tidy Area: The tidy tool 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-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) 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.