Rollup of 7 pull requests
Successful merges:
- #133358 (Don't type error if we fail to coerce `Pin<T>` because it doesnt contain a ref)
- #133422 (Fix clobber_abi in RV32E and RV64E inline assembly)
- #133452 (Support predicate registers (clobber-only) in Hexagon inline assembly)
- #133463 (Fix handling of x18 in AArch64 inline assembly on ohos/trusty or with -Zfixed-x18)
- #133487 (fix confusing diagnostic for reserved `##`)
- #133557 (Small doc fixes in `rustc_codegen_ssa`)
- #133560 (Trim extra space in 'repeated `mut`' diagnostic)
r? `@ghost`
`@rustbot` modify labels: rollup
Use edition of `macro_rules` when compiling the macro
This changes the edition assigned to a macro_rules macro when it is compiled to use the edition of where the macro came from instead of the local crate's edition.
This fixes a problem when a macro_rules macro is created by a proc-macro. Previously that macro would be tagged with the local edition, which would cause problems with using the correct edition behavior inside the macro. For example, the check for unsafe attributes would cause errors in 2024 when using proc-macros from older editions.
This is partially related to https://github.com/rust-lang/rust/issues/132906. Unfortunately this is only a half fix for that issue. It fixes the error that happens in 2024, but does not fix the lint firing in 2021. I'm still trying to think of some way to fix that, but I'm running low on ideas.
Reduce integer `Display` implementation size
I was thinking about #128204 and how we could reduce the size of the code and just realized that we didn't need the `_fmt` method to be implemented on signed integers, which in turns allow to simplify greatly the macro call.
r? `@workingjubilee`
rustc: Fail fast when compiling a source file larger than 4 GiB
Currently if you try to compile a file that is larger than 4 GiB, `rustc` will first read the whole into memory before failing.
If we can read the metadata of the file, we can fail before reading the file.
Add `AsyncFn*` to the prelude in all editions
The general vibe is that we will most likely stabilize the `feature(async_closure)` *without* the `async Fn()` trait bound modifier.
Without `async Fn()` bound syntax, this necessitates users to spell the bound like `AsyncFn()`. Since `core::ops::AsyncFn` is not in the prelude, users will need to import these any time they actually want to use the trait. This seems annoying, so let's add these traits to the prelude unstably.
We're trying to work on the general vision of `async` trait bound modifier in general in: https://github.com/rust-lang/rfcs/pull/3710, however that RFC still needs more time for consensus to converge, and we've decided that the value that users get from calling the bound `async Fn()` is *not really* worth blocking landing async closures in general.
btree: don't leak value if destructor of key panics
This PR fixes a regression from https://github.com/rust-lang/rust/pull/84904.
The `BTreeMap` already attempts to handle panicking destructors of the key-value pairs by continuing to execute the remaining destructors after one destructor panicked. However, after #84904 the destructor of a value in a key-value pair gets skipped if the destructor of the key panics, only continuing with the next key-value pair. This PR reverts to the behavior before #84904 to also drop the corresponding value if the destructor of a key panics.
This avoids potential memory leaks and can fix the soundness of programs that rely on the destructors being executed (even though this should not be relied upon, because the std collections currently do not guarantee that the remaining elements are dropped after a panic in a destructor).
cc `@Amanieu` because you had opinions on panicking destructors
Stabilize `Ipv6Addr::is_unique_local` and `Ipv6Addr::is_unicast_link_local`
Make `Ipv6Addr::is_unique_local` and `Ipv6Addr::is_unicast_link_local` stable (+const).
Newly stable API:
```rust
impl Ipv6Addr {
// Newly stable under `ipv6_is_unique_local`
const fn is_unique_local(&self) -> bool;
// Newly stable under `ipv6_is_unique_local`
const fn is_unicast_link_local(&self) -> bool;
}
```
These stabilise a subset of the following tracking issue:
- #27709
I have looked and could not find any issues with `is_unique_local` and `is_unicast_link_local`. There is a well received comment calling for stabilisation of the latter function.
Both functions are well defined and consistent with implementations in other languages:
- [Go](https://cs.opensource.google/go/go/+/refs/tags/go1.23.0:src/net/netip/netip.go;l=518)
- [Python](e9d1bf353c/Lib/ipaddress.py (L2319-L2321))
- [Ruby (unique local)](https://ruby-doc.org/stdlib-2.5.1/libdoc/ipaddr/rdoc/IPAddr.html#private-3F-source)
- [Ruby (unicast link local)](https://ruby-doc.org/stdlib-2.5.1/libdoc/ipaddr/rdoc/IPAddr.html#link_local-3F-source)
cc implementor `@little-dude`
(I can't find the original PR for `is_unqiue_local`)
r? libs-api
`@rustbot` label +T-libs-api +needs-fcp
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)
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).
Default-enable `llvm_tools_enabled` when no `config.toml` is present
Fixes#133195. cc `@wesleywiser` could you double check if with this patch and no `config.toml` that you can run `./x test tests/ui --stage 1`?
`llvm-objcopy` is usually required by cg_ssa on macOS to workaround bad `strip`s.
cc `@bjorn3` I hope this doesn't break cg_clif...
r? bootstrap
Add `visit` methods to ast nodes that already have `walk`s on ast visitors
Some `walk` functions are called directly, because there were no correspondent visit functions.
related to #128974 & #127615
r? `@petrochenkov`
