-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Rollup of 7 pull requests #135789
Conversation
…`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
minor: Fix `test-fixture` autopublishing
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.
…acy extern "rust-intrinsic" blocks
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
@bors r+ rollup=never p=5 |
⌛ Testing commit 67b609a with merge f3d1d47fd84dfcf7f513be1dbad356e74c8f3b2b... |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 9f4d9dc102 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (f3d1d47): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countThis 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.
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.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 765.975s -> 764.999s (-0.13%) |
Successful merges:
extern "rust-intrinsic"
blocks #132735: Replace extern "rust-intrinsic" with #[rustc_intrinsic] across the codebase)rust-analyzer
#135775 (Subtree update ofrust-analyzer
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup