Rustup #4044
Merged
Rustup #4044
Conversation
This file contains 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
Drop debug info instead of panicking if we exceed LLVM's capability to represent it Recapping a bit of history here: In #128861 I made debug info correctly represent parameters to inline functions by removing a fake lexical block that had been inserted to suppress LLVM assertions and by deduplicating those parameters. LLVM, however, expects to see a single parameter _with distinct locations_, particularly distinct inlinedAt values on the DILocations. This generally worked because no matter how deep the chain of inlines it takes two different call sites in the original function to result in the same function being present multiple times, and a function call requires a non-zero number of characters, but macros threw a wrench in that in #131944. At the time I thought the issue there was limited to proc-macros, where an arbitrary amount of code can be generated at a single point in the source text. In #132613 I added discriminators to DILocations that would otherwise be the same to repair #131944[^1]. This works, but LLVM's capacity for discriminators is not infinite (LLVM actually only allocates 12 bits for this internally). At the time I thought it would be very rare for anyone to hit the limit, but #132900 proved me wrong. In the relatively-minimized test case it also became clear to me that the issue affects regular macros too, because the call to the inlined function will (without collapse_debuginfo on the macro) be attributed to the (repeated, if the macro is used more than once) textual callsite in the macro definition. This PR fixes the panic by dropping debug info when we exceed LLVM's maximum discriminator value. There's also a preceding commit for a related but distinct issue: macros that use collapse_debuginfo should in fact have their inlinedAts collapsed to the macro callsite and thus not need discriminators at all (and not panic/warn accordingly when the discriminator limit is exhausted). Fixes #132900 r? `@jieyouxu` [^1]: Editor's note: `fix` is a magic keyword in PR description that apparently will close the linked issue (it's closed already in this case, but still).
continue `ParamEnv` to `TypingEnv` transition cc #132279 r? `@compiler-errors`
Use attributes for `dangling_pointers_from_temporaries` lint Checking for dangling pointers by function name isn't ideal, and leaves out certain pointer-returning methods that don't follow the `as_ptr` naming convention. Using an attribute for this lint cleans things up and allows more thorough coverage of other methods, such as `UnsafeCell::get()`.
lints_that_dont_need_to_run: never skip future-compat-reported lints Follow-up to rust-lang/rust#125116: future-compat lints show up with `--json=future-incompat` even if they are otherwise allowed in the crate. So let's ensure we do not skip those as part of the `lints_that_dont_need_to_run` logic. I could not find a current future compat lint that is emitted by a lint pass, so there's no clear way to add a test for this. Cc `@blyxyas` `@cjgillot`
CI: use free runner in dist-aarch64-msvc try-job: dist-aarch64-msvc
Make rustc --explain compatible with BusyBox less busybox less does not support the -r flag and less(1) says: USE OF THE -r OPTION IS NOT RECOMMENDED.
Implement `~const Fn` trait goal in the new solver Split out from rust-lang/rust#132329 since this should be easier to review on its own. r? lcnr
Rollup of 5 pull requests Successful merges: - #132732 (Use attributes for `dangling_pointers_from_temporaries` lint) - #133108 (lints_that_dont_need_to_run: never skip future-compat-reported lints) - #133190 (CI: use free runner in dist-aarch64-msvc) - #133196 (Make rustc --explain compatible with BusyBox less) - #133216 (Implement `~const Fn` trait goal in the new solver) r? `@ghost` `@rustbot` modify labels: rollup
Update cargo 5 commits in 69e595908e2c420e7f0d1be34e6c5b984c8cfb84..66221abdeca2002d318fde6efff516aab091df0e 2024-11-16 01:26:11 +0000 to 2024-11-19 21:30:02 +0000 - Docs for optional registry JSON fields (rust-lang/cargo#14839) - Allow registries to omit empty/default fields in JSON (rust-lang/cargo#14838) - docs(unstable): Link to -Zwarnings issue, tracking issue (rust-lang/cargo#14836) - fix(): error context for git_fetch refspec not found (rust-lang/cargo#14806) - you we distinction (rust-lang/cargo#14829)
interpret: make typing_env field private This was made public in rust-lang/rust#133212 but IMO it should remain private. (Specifically, this prevents it from being mutated.) r? `@lcnr`
Rollup of 3 pull requests Successful merges: - #131904 (Stabilize const_pin_2) - #133239 (Fix LLVM target triple for `x86_64-win7-windows-msvc`) - #133241 (interpret: make typing_env field private) r? `@ghost` `@rustbot` modify labels: rollup
…komatsakis Reduce false positives of tail-expr-drop-order from consumed values (attempt rust-lang#2) r? `@nikomatsakis` Tracked by #123739. Related to #129864 but not replacing, yet. Related to #130836. This is an implementation of the approach suggested in the [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/temporary.20drop.20order.20changes). A new MIR statement `BackwardsIncompatibleDrop` is added to the MIR syntax. The lint now works by inspecting possibly live move paths before at the `BackwardsIncompatibleDrop` location and the actual drop under the current edition, which should be one before Edition 2024 in practice.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in 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.
No description provided.