Skip to content

Rollup of 6 pull requests #86417

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

Merged
merged 16 commits into from
Jun 18, 2021
Merged

Rollup of 6 pull requests #86417

merged 16 commits into from
Jun 18, 2021

Conversation

m-ou-se
Copy link
Member

@m-ou-se m-ou-se commented Jun 17, 2021

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

clarfonthey and others added 16 commits June 1, 2021 23:09
Linear interpolation

rust-lang#71016 is a previous attempt at implementation that was closed by the author. I decided to reuse the feature request issue (rust-lang#71015) as a tracking issue. A member of the rust-lang org will have to edit the original post to be formatted correctly as I am not the issue's original author.

The common name `lerp` is used because it is the term used by most code in a wide variety of contexts; it also happens to be the recently chosen name of the function that was added to C++20.

To ensure symmetry as a method, this breaks the usual ordering of the method from `lerp(a, b, t)` to `t.lerp(a, b)`. This makes the most sense to me personally, and there will definitely be discussion before stabilisation anyway.

Implementing lerp "correctly" is very dififcult even though it's a very common building-block used in all sorts of applications. A good prior reading is [this proposal](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0811r2.html#linear-interpolation) for the C++20 lerp which talks about the various guarantees, which I've simplified down to:

1. Exactness: `(0.0).lerp(start, end) == start` and `(1.0).lerp(start, end) == end`
2. Consistency: `anything.lerp(x, x) == x`
3. Monotonicity: once you go up don't go down

Fun story: the version provided in that proposal, from what I understand, isn't actually monotonic.

I messed around with a *lot* of different lerp implementations because I kind of got a bit obsessed and I ultimately landed on one that uses the fused `mul_add` instruction. Floating-point lerp lore is hard to come by, so, just trust me when I say that this ticks all the boxes. I'm only 90% certain that it's monotonic, but I'm sure that people who care deeply about this will be there to discuss before stabilisation.

The main reason for using `mul_add` is that, in general, it ticks more boxes with fewer branches to be "correct." Although it will be slower on architectures without the fused `mul_add`, that's becoming more and more rare and I have a feeling that most people who will find themselves needing `lerp` will also have an efficient `mul_add` instruction available.
…-ou-se

Specialize `io::Bytes::size_hint` for more types

Improve the result of `<io::Bytes as Iterator>::size_hint` for some readers. I did not manage to specialize `SizeHint` for `io::Cursor`

Side question: would it be interesting for `io::Read` to have an optional `size_hint` method ?
…, r=m-ou-se

Rely on libc for correct integer types in os/unix/net/ancillary.rs.

This PR is a small maintainability improvement. It simplifies `unix/net/ancillary.rs` in `std` by removing the `cfg_ifs` for casting to the correct integer type, and just rely on libc to define the struct correctly.
…Artichaut

Make `s` pre-interned

Now we should be able to pre-intern `s` as the test `ui/lint/rfc-2457-non-ascii-idents/lint-confusable-idents.rs` no longer fails.
…tichaut

Fix ICE when using `#[doc(keyword = "...")]` on non-items

This pull request fixes rust-lang#83512. The code for checking attributes calls `expect_item()` when it shouldn't, thus causing an ICE. I have implemented a proper check for the node kind, so that an error is reported instead of the ICE.
…te, r=Mark-Simulacrum

Add incr-comp note for 1.53.0 relnotes
@rustbot rustbot added the rollup A PR which is a rollup label Jun 17, 2021
@m-ou-se
Copy link
Member Author

m-ou-se commented Jun 17, 2021

@bors r+ rollup=never p=6

@bors
Copy link
Collaborator

bors commented Jun 17, 2021

📌 Commit 4ec05e0 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 Jun 17, 2021
@bors
Copy link
Collaborator

bors commented Jun 17, 2021

⌛ Testing commit 4ec05e0 with merge a6bc43e...

@bors
Copy link
Collaborator

bors commented Jun 18, 2021

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

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 18, 2021
@bors bors merged commit a6bc43e into rust-lang:master Jun 18, 2021
@rustbot rustbot added this to the 1.55.0 milestone Jun 18, 2021
@m-ou-se m-ou-se deleted the rollup-vo2y1rz branch June 18, 2021 04:42
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.

9 participants