Skip to content

Rollup of 6 pull requests #86417

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # 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
# for free to join this conversation on GitHub. Already have an account? # 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