Rollup of 8 pull requests
Successful merges:
- #132474 (Add more mailmap entries)
- #133486 (borrowck diagnostics: make `add_move_error_suggestions` use the HIR rather than `SourceMap`)
- #134861 (Add GUI test for item info elements color)
- #134968 (Print how to rebless Python formatting in tidy)
- #134971 (chore: fix typos)
- #134972 (add .mailmap entry for myself)
- #134974 (Revert #119515 single line where clause style guide)
- #134975 (Revert style guide rhs break)
r? `@ghost`
`@rustbot` modify labels: rollup
Revert #119515 single line where clause style guide
This did not get implemented for the style edition in 2024, so this PR removes it from the documentation.
See tracking issue https://github.com/rust-lang/rust/issues/132381.
This can be added back in the next edition if it gets implemented. I'm a little unclear on what the style team intends for how future changes are documented. For example, the current style-guide documented behavior that rustfmt does not support. I'm not sure who the audience for this document is, or how this is intended to stay in sync with rustfmt. For example, if I read this and assume this is how it is supposed to work, and then rustfmt breaks that, it seems like that is confusing. Similarly, if I'm staying on an older edition, this documentation would be incorrect for my crate.
Perhaps changes like this could be "teed-up" in a PR, but not merged until the edition is stabilized (similar to how the reference works)? And include notes for parts that are edition-specific (so if I am using an older edition, I can see that something is different). In general, I'm a little confused on how this is intended to work.
Reverts:
- https://github.com/rust-lang/rust/pull/119515
add .mailmap entry for myself
Seeing #132474 in the bors queue I decided to check myself and noticed I was listed four times.
This fixed that by cannonicalizing all entries to use my username and the github no-reply email address, rather than some combination of name or username and different email addresses.
borrowck diagnostics: make `add_move_error_suggestions` use the HIR rather than `SourceMap`
This PR aims to fix#132806 by rewriting `add_move_error_suggestions`[^1]. Previously, it manually scanned the source text to find a leading `&`, which isn't always going to produce a correct result (see: that issue). Admittedly, the HIR visitor in this PR introduces a lot of boilerplate, but hopefully the logic at its core isn't too complicated (I go over it in the comments). I also tried a simpler version that didn't use a HIR visitor and suggested adding `ref` always, but the `&ref x` suggestions really didn't look good. As a bonus for the added complexity though, it's now able to produce nice `&`-removing suggestions in more cases.
I tried to do this such that it avoids edition-dependent checks and its suggestions can be applied together with those from the match ergonomics 2024 migration lint. I haven't added tests for that since the details of match ergonomics 2024 are still being sorted out, but I can try if desired once that's finalized.
[^1]: In brief, it fires on patterns where users try to bind by-value in such a way that moves out of a reference to a non-Copy type (including slice references with non-copy elements). The suggestions are to change the binding's mode to be by-reference, either by removing[^2] an enclosing `&`/`&mut` or adding `ref` to the binding.
[^2]: Incidentally, I find the terminology of "consider removing the borrow" a bit confusing for a suggestion to remove a `&` pattern in order to make bindings borrow rather than move. I'm not sure what a good, concise way to explain that would be though, and that should go in a separate PR anyway.
Add more mailmap entries
If you have been pinged: I'm adding a mailmap entry for you to keep thanks.rust-lang.org working properly.
**I have picked the canonical address mostly arbitrarily. If you want a different one as the canonical address, please tell me here**.
<details>
<summary>more details on the change</summary>
builds on top of #132471, this containing the less obvious changes that add new canonical email addresses instead of just adding new current ones.
The people updated in this commit have contributed under different email
addresses than the ones they have used in rust-lang/team.
https://github.com/rust-lang/thanks/pull/53 will use team data for thanks reviewers, which requires this to be in
sync.
Therefore, I have updated many of the people that I've noticed being
duplicated after the change.
</details>
I'm adding a novel entry for you: ``@apiraino`` ``@KodrAus`` ``@cramertj`` ``@sunfishcode`` ``@Eh2406`` ``@skade`` ``@huonw`` ``@jsha`` ``@shepmaster`` ``@workingjubilee`` ``@rbtcollins`` ``@nrc`` ``@fitzgen`` ``@sophiajt`` ``@tmiasko`` ``@notriddle`` ``@TimNN`` ``@WaffleLapkin``
Tidy up bigint multiplication methods
This tidies up the library version of the bigint multiplication methods after the addition of the intrinsics in #133663. It follows [this summary](https://github.com/rust-lang/rust/issues/85532#issuecomment-2403442775) of what's desired for these methods.
Note that, if `2H = N`, then `uH::MAX * uH::MAX + uH::MAX + uH::MAX` is `uN::MAX`, and that we can effectively add two "carry" values without overflowing.
For ease of terminology, the "low-order" or "least significant" or "wrapping" half of multiplication will be called the low part, and the "high-order" or "most significant" or "overflowing" half of multiplication will be called the high part. In all cases, the return convention is `(low, high)` and left unchanged by this PR, to be litigated later.
## API Changes
The original API:
```rust
impl uN {
// computes self * rhs
pub const fn widening_mul(self, rhs: uN) -> (uN, uN);
// computes self * rhs + carry
pub const fn carrying_mul(self, rhs: uN, carry: uN) -> (uN, uN);
}
```
The added API:
```rust
impl uN {
// computes self * rhs + carry1 + carry2
pub const fn carrying2_mul(self, rhs: uN, carry: uN, add: uN) -> (uN, uN);
}
impl iN {
// note that the low part is unsigned
pub const fn widening_mul(self, rhs: iN) -> (uN, iN);
pub const fn carrying_mul(self, rhs: iN, carry: iN) -> (uN, iN);
pub const fn carrying_mul_add(self, rhs: iN, carry: iN, add: iN) -> (uN, iN);
}
```
Additionally, a naive implementation has been added for `u128` and `i128` since there are no double-wide types for those. Eventually, an intrinsic will be added to make these more efficient, but rather than doing this all at once, the library changes are added first.
## Justifications for API
The unsigned parts are done to ensure consistency with overflowing addition: for a two's complement integer, you want to have unsigned overflow semantics for all parts of the integer except the highest one. This is because overflow for unsigned integers happens on the highest bit (from `MAX` to zero), whereas overflow for signed integers happens on the second highest bit (from `MAX` to `MIN`). Since the sign information only matters in the highest part, we use unsigned overflow for everything but that part.
There is still discussion on the merits of signed bigint *addition* methods, since getting the behaviour right is very subtle, but at least for signed bigint *multiplication*, the sign of the operands does make a difference. So, it feels appropriate that at least until we've nailed down the final API, there should be an option to do signed versions of these methods.
Additionally, while it's unclear whether we need all three versions of bigint multiplication (widening, carrying-1, and carrying-2), since it's possible to have up to two carries without overflow, there should at least be a method to allow that. We could potentially only offer the carry-2 method and expect that adding zero carries afterword will optimise correctly, but again, this can be litigated before stabilisation.
## Note on documentation
While a lot of care was put into the documentation for the `widening_mul` and `carrying_mul` methods on unsigned integers, I have not taken this same care for `carrying_mul_add` or the signed versions. While I have updated the doc tests to be more appropriate, there will likely be many documentation changes done before stabilisation.
## Note on tests
Alongside this change, I've added several tests to ensure that these methods work as expected. These are alongside the codegen tests for the intrinsics.
The people updated in this commit have contributed under different email
addresses than the ones they have used in rust-lang/team.
A new change will use team data for thanks reviewers, which requires this to be in
sync.
Therefore, I have updated many of the people that I've noticed being
duplicated after the change.
Account for C string literals and `format_args` in `HiddenUnicodeCodepoints` lint
This is stacked on #134955, and either that can land first or both of them can land together here. I split this out because this is a bit more involved of an impl.
Fixes#94945
Fix doc for read&write unaligned in zst operation
### PR Description
This PR addresses an inconsistency in the Rust documentation regarding `read_unaligned ` and `write_unaligned` on zero-sized types (ZSTs). The current documentation for [pointer validity](https://doc.rust-lang.org/nightly/std/ptr/index.html#safety) states that for zero-sized types (ZSTs), null pointers are valid:
> For zero-sized types (ZSTs), every pointer is valid, including the null pointer.
However, there is an inconsistency in the documentation for the unaligned read operation in the function [ptr::read_unaligned](https://doc.rust-lang.org/nightly/std/ptr/fn.read_unaligned.html)(as well as `write_unaligned`), which states:
> Note that even if T has size 0, the pointer must be non-null.
This change is also supported by [PR #134912](https://github.com/rust-lang/rust/pull/134912)
> the _unaligned method docs should be fixed.
Windows: Enable issue 70093 link tests
Tracking issue for `-Z link-native-libraries`: #134948
Tracking issue for `-Z link-directives`: #134947
`-Zlink-native-libraries=no` and `-Zlink-directives=no` *should* work on Windows, at least for msvc. The fly in ointment is that `default-linker-libraries` doesn't. On unixy platforms rustc calls another compiler which in turn calls the linker along with the default libraries. On MSVC rustc calls the linker directly therefore it would need to be the one to implement `default-linker-libraries`. Except it doesn't so we workaround that in the test by using `-C link-arg` to talk to the linker.
Avoid short writes in LineWriter
If the bytes written to `LineWriter` contains at least one new line but doesn't end in a new line (e.g. `"abc\ndef"`) then we:
- write up to the last new line direct to the underlying `Writer`.
- copy as many of the remaining bytes as will fit into our internal buffer.
That last step is inefficient if the remaining bytes are larger than our buffer. It will needlessly split the bytes in two, requiring at least two writes to the underlying `Writer` (one to flush the buffer, one more to write the rest). This PR skips the extra buffering if the remaining bytes are larger than the buffer.
Rollup of 3 pull requests
Successful merges:
- #134291 (Use python built in type annotations in LLDB visualizer scripts)
- #134857 (Unsafe binder support in rustdoc)
- #134957 (chore: fix some typos)
r? `@ghost`
`@rustbot` modify labels: rollup
Unsafe binder support in rustdoc
Adds rustdoc support for unsafe binder types: `unsafe<'a> Foo<'a>`. Doesn't add json support yet.
Tracking:
* https://github.com/rust-lang/rust/issues/130516
Use python built in type annotations in LLDB visualizer scripts
Replaces type annotation comments with python's built-in type annotations.
Built-in type annotations were added in python 3.5. LLDB [currently recommends (and as of LLVM 21, will enforce)](https://github.com/llvm/llvm-project/pull/114807) a minimum python version of 3.8. Rust's test suite also requires python 3.10.
Rollup of 8 pull requests
Successful merges:
- #134919 (bootstrap: Make `./x test compiler` actually run the compiler unit tests)
- #134927 (Make slice::as_flattened_mut unstably const)
- #134930 (ptr docs: make it clear that we are talking only about memory accesses)
- #134932 (explicitly set float ABI for all ARM targets)
- #134933 (Make sure we check the future type is `Sized` in `AsyncFn*`)
- #134934 (Fix typos)
- #134941 (compiler: Add a statement-of-intent to `rustc_abi`)
- #134949 (Convert some `Into` impls into `From` impls)
r? `@ghost`
`@rustbot` modify labels: rollup
compiler: Add a statement-of-intent to `rustc_abi`
This just documents the most basic idea of what the crate is even for in my view, rather than leaving that strewn about GitHub issues, PR reviews, and Zulip streams. In particular, I hope to make it clearer what code should go in `rustc_abi` and what should not, which is of immediate relevance to contributors.
I considered going even further and explaining ideas like "ABI compatibility", prologues, and so on. However, because of the cross-cutting nature of ABI, I think such explanations should probably live in the place for cross-cutting documents: the rustc dev guide. This is only meant to be a quick "by the way".
explicitly set float ABI for all ARM targets
We currently always set the `FloatABIType` field in the LLVM target machine to `Default`, which means LLVM infers the ARM float ABI (hard vs soft) from the LLVM target triple. This causes problems such as having to set the LLVM triple to `*-gnueabi` for our `musleabi` targets to ensure they get correctly inferred as soft-float targets. It also means rustc doesn't really know which float ABI ends up being used, which is a blocker for https://github.com/rust-lang/rust/pull/134794. So I think we should stop doing that and instead explicitly control that value. That's what this PR implements.
See [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/187780-t-compiler.2Fwg-llvm/topic/Softfloat.20ABI.2C.20hardfloat.20instructions) for more context.
Best reviewed commit-by-commit. I hope I got all those `llvm_floatabi` values right...
ptr docs: make it clear that we are talking only about memory accesses
This should make it harder to take this sentence out of context and misunderstand it.
Stabilize `style_edition = "2024"` in-tree
This PR stabilizes the `style_edition` flag in rustfmt.
**Why am I doing this in-tree?** The beta release cut is imminent (according to forge, on January 3) and this is the most lightweight approach to getting this flag stable on nightly. It's imperative (as far as I can tell -- `@traviscross` can verify or disagree) that we stabilize the `style_edition` flag so that users can control their style edition separately from the edition.
I'm happy to move this PR to the rustfmt repo and subsequently prepare a subtree sync if someone on `@rust-lang/rustfmt` believes that we should get this landed on the rustfmt side then synced. If this is the right recourse, I'd like to note that this is still quite time-sensitive. However, I'm happy to dedicate time to get this done if necessary, since I'd really like to un-jeopardize the style edition.
Tracking:
- https://github.com/rust-lang/rust/issues/123799
