rust-lang / rust

…-morse

Add bit removal methods to SparseBitMatrix and factor *BitSet relational methods into more extensible trait

I need the ability to clear the bits out of a row from `SparseBitMatrix`. Currently, all the mutating methods only allow insertion of bits, and there is no way to get access to the underlying data.

One approach is simply to make `ensure_row` public, since it grants `&mut` access to the underlying `HybridBitSet`. This PR adds the `pub` modifier. However, presumably this method was private for a reason, so I'm open to other designs. I would prefer general mutable access to the rows, because that way I can add many mutating operations (`clear`, `intersect`, etc.) without filing a PR each time :-)

r? `@ecstatic-morse`

Improve errors for recursive type aliases

Fixes #17539.

Introduce `let...else`

Tracking issue: #87335

The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..`, but I decided against this because, when a "mismatched type" error is found in typeck, there is no way to trace where in the HIR the expected type originated, AFAICT. In order to pass down this information, I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType`, but I left that as a future enhancement. For now, I simply assert that the block is `!` with a custom `ObligationCauseCode`, and I think this is clear enough, at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect.

Overall, I believe this PR is feature-complete with regard to the RFC.

Concrete regions can show up in mir borrowck if the originated from there

We used to not encounter them here, because we took regions from typeck's opaque type resolution by renumbering them. We don't do that anymore. Instead mir borrock does all the logic, and it can handle concrete regions just fine, as long as it created them itself.

fixes #83190 which was introduced by #87287

r? `@spastorino`

Fix loading large rlibs

Bumps object crate to permit parsing archives with 64-bit table entries. These
are primarily encountered when there's more than 4GB of archive data.

cc gimli-rs/object#365

Helps with #88351, but will also need a beta backport

r? `@ehuss` (mostly for the test)

Rollup of 10 pull requests

Successful merges:

 - #85017 (Add carrying_add, borrowing_sub, widening_mul, carrying_mul methods to integers)
 - #86362 (Avoid cloning LocalDecls)
 - #88391 (Fix json tuple struct enum variant )
 - #88399 (Disallow the aapcs CC on Aarch64)
 - #88418 (Allow `~const` bounds on trait assoc functions)
 - #88445 (Clean up the lowering of AST items)
 - #88495 (Add `TcpStream::set_linger` and `TcpStream::linger`)
 - #88501 (Use right span in prelude collision suggestions with macros. )
 - #88504 (Keep turbofish in prelude collision lint.)
 - #88524 (Remove unnecessary `mut` from udp doctests)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

Remove unnecessary `mut` from udp doctests

I don't think this `mut` is necessary, since both `recv_from` and `send_to` take `&self`.

Keep turbofish in prelude collision lint.

Fixes #88442

… r=estebank

Use right span in prelude collision suggestions with macros.

Fixes #88347

r? `@estebank`

Add `TcpStream::set_linger` and `TcpStream::linger`

Adds methods for getting/setting the `SO_LINGER` option on TCP sockets. Behavior is consistent across Unix and Windows.

r? `@joshtriplett` (I noticed you've been reviewing net related PRs)

Clean up the lowering of AST items

This PR simplifies and improves `rustc_ast_lowering::item` in various minor ways. The reasons for the changes should mostly be self evident, though I'm happy to specifically explain anything if needed.

These changes used to be part of #88019, but I removed them after it was pointed out that some of my other changes to `rustc_ast_lowering` were unnecessary. It felt like a bad idea to clean up code which I didn't even need to touch anymore.

r? `@cjgillot`

Allow `~const` bounds on trait assoc functions

r? `@oli-obk`

Disallow the aapcs CC on Aarch64

This never really worked and makes LLVM assert.

…lid,notriddle

Fix json tuple struct enum variant

Fixes #87887.

cc `@dsherret` `@camelid`

r? `@notriddle`

Avoid cloning LocalDecls

Add carrying_add, borrowing_sub, widening_mul, carrying_mul methods to integers

This comes in part from my own attempts to make (crude) big integer implementations, and also due to the stalled discussion in [RFC 2417](rust-lang/rfcs#2417). My understanding is that changes like these are best offered directly as code and then an RFC can be opened if there needs to be more discussion before stabilisation. Since all of these methods are unstable from the start, I figured I might as well offer them now.

I tried looking into intrinsics, messed around with a few different implementations, and ultimately concluded that these are "good enough" implementations for now to at least put up some code and maybe start bikeshedding on a proper API for these.

For the `carrying_add` and `borrowing_sub`, I tried looking into potential architecture-specific code and realised that even using the LLVM intrinsics for `addcarry` and `subborrow` on x86 specifically, I was getting exactly the same assembly as the naive implementation using `overflowing_add` and `overflowing_sub`, although the LLVM IR did differ because of the architecture-specific code. Longer-term I think that they would be best suited to specific intrinsics as that would make optimisations easier (instructions like add-carry tend to use implicit flags, and thus can only be optimised if they're done one-after-another, and thus it would make the most sense to have compact intrinsics that can be merged together easily).

For `widening_mul` and `carrying_mul`, for now at least, I simply cast to the larger type and perform arithmetic that way, since we currently have no intrinsic that would work better for 128-bit integers. In the future, I also think that some form of intrinsic would work best to cover that case, but for now at least, I think that they're "good enough" for now.

The main reasoning for offering these directly to the standard library even though they're relatively niche optimisations is to help ensure that the code generated for them is optimal. Plus, these operations alone aren't enough to create big integer implementations, although they could help simplify the code required to do so and make it a bit more accessible for the average implementor.

That said, I 100% understand if any or all of these methods are not desired simply because of how niche they are. Up to you. 🤷🏻

Co-authored-by: Mara Bos <[email protected]>

…here.

We used to not encounter them here, because we took regions from typeck's opaque type resolution by renumbering them. We don't do that anymore.

This is kept to a separate commit so that the test itself is preserved in the
commit history.

Rollup of 14 pull requests

Successful merges:

 - #88394 (Document `std::env::current_exe` possible rename behaviour)
 - #88406 (Tait nest infer test)
 - #88408 (Add inference cycle TAIT test)
 - #88409 (Add auto trait leakage TAIT test)
 - #88413 (Add weird return types TAIT test)
 - #88450 (fix(rustc_parse): correct span in `maybe_whole_expr!`)
 - #88462 (rustdoc: Stop using resolver for macro loading)
 - #88465 (Adding examples to docs of `std::time` module)
 - #88486 (Remove unused arena macro args)
 - #88492 (Use MaybeUninit::write in functor.rs)
 - #88496 (Fix prelude collision lint suggestion for generics with lifetimes)
 - #88497 (Fix prelude collision suggestions for glob imported traits. )
 - #88503 (Warn when [T; N].into_iter() is ambiguous in the new edition. )
 - #88509 (Don't suggest extra <> in dyn suggestion.)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

…ingle-angle-brackets-please-thanks, r=petrochenkov

Don't suggest extra <> in dyn suggestion.

Fixes #88508

Warn when [T; N].into_iter() is ambiguous in the new edition.

Fixes #88475

In #88475, a situation was found where `[T; N].into_iter()` becomes *ambiguous* in the new edition. This is different than the case where `(&[T; N]).into_iter()` resolves differently, which was the only case handled by the `array_into_iter` lint. This is almost identical to the new-traits-in-the-prelude problem. Effectively, due to the array-into-iter hack disappearing in Rust 2021, we effectively added `IntoIterator` to the 'prelude' in Rust 2021 specifically for arrays.

This modifies the prelude collisions lint to detect that case and emit a `array_into_iter` lint in that case.

Fix prelude collision suggestions for glob imported traits.

Fixes #88471

cc `@nikomatsakis`

… r=petrochenkov

Fix prelude collision lint suggestion for generics with lifetimes

Fixes #88470

cc `@nikomatsakis`

Use MaybeUninit::write in functor.rs

MaybeUninit::write is stable as of 1.55.0.

Remove unused arena macro args

Adding examples to docs of `std::time` module

And adding missing link to `Duration` from `Instant`.

rustdoc: Stop using resolver for macro loading

r? `@jyn514`

…llot

fix(rustc_parse): correct span in `maybe_whole_expr!`

Fixes #87812

…li-obk

Add weird return types TAIT test

r? `@oli-obk`

Related to #86727