Skip to content
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 10 pull requests #88535

Merged
merged 28 commits into from
Aug 31, 2021
Merged

Rollup of 10 pull requests #88535

merged 28 commits into from
Aug 31, 2021

Conversation

m-ou-se
Copy link
Member

@m-ou-se m-ou-se commented Aug 31, 2021

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

clarfonthey and others added 28 commits August 26, 2021 19:52
This never really worked and makes LLVM assert.
…ou-se

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. 🤷🏻
…t, r=camelid,notriddle

Fix json tuple struct enum variant

Fixes rust-lang#87887.

cc `@dsherret` `@camelid`

r? `@notriddle`
…rochenkov

Disallow the aapcs CC on Aarch64

This never really worked and makes LLVM assert.
…r=oli-obk

Allow `~const` bounds on trait assoc functions

r? `@oli-obk`
…cjgillot

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 rust-lang#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`
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)
…ros-help, r=estebank

Use right span in prelude collision suggestions with macros.

Fixes rust-lang#88347

r? `@estebank`
…i-obk

Keep turbofish in prelude collision lint.

Fixes rust-lang#88442
Remove unnecessary `mut` from udp doctests

I don't think this `mut` is necessary, since both `recv_from` and `send_to` take `&self`.
@rustbot rustbot added the rollup A PR which is a rollup label Aug 31, 2021
@m-ou-se
Copy link
Member Author

m-ou-se commented Aug 31, 2021

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Aug 31, 2021

📌 Commit f5cf967 has been approved by m-ou-se

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Aug 31, 2021
@bors
Copy link
Contributor

bors commented Aug 31, 2021

⌛ Testing commit f5cf967 with merge 0a84708...

@bors
Copy link
Contributor

bors commented Aug 31, 2021

☀️ Test successful - checks-actions
Approved by: m-ou-se
Pushing 0a84708 to master...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.