[crater] Add impl From<f16> for f32 by beetrees · Pull Request #142723 · rust-lang/rust (original) (raw)

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 andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation11 Commits1 Checks10 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

@beetrees

Crater run to see what the effects of adding impl From<f16> for f32 without changing the fallback (a.k.a. things that would be caught by the FCW in #139087). This needs a @craterbot check.

@beetrees

@rustbot rustbot added T-compiler

Relevant to the compiler team, which will review and decide on the PR/issue.

T-libs

Relevant to the library team, which will review and decide on the PR/issue.

labels

Jun 19, 2025

@traviscross

@rust-bors

⌛ Trying commit e4ad46e with merge 8d46be7

To cancel the try build, run the command @bors2 try cancel.

rust-bors bot added a commit that referenced this pull request

Jun 19, 2025

@rust-bors

[crater] Add impl From<f16> for f32

Crater run to see what the effects of adding impl From<f16> for f32 without changing the fallback (a.k.a. things that would be caught by the FCW in #139087). This needs a ``@craterbot check.

@rust-bors

☀️ Try build successful (CI)
Build commit: 8d46be7 (8d46be77cd48fdbcced888d027457e2c9cf2aa16, parent: 2fcf1776b9ccef89993dfe40e9f5c4908e2d2d48)

@tgross35

@craterbot

@craterbot

🚧 Experiment pr-142723 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@craterbot

@traviscross

Various versions of epaint, glyph_brush, and taffy seem to account for the vast majority of the breakage. Whatever else we do, it'd probably be worth putting in PRs for those.

@joshtriplett

@traviscross I don't think we should submit any PRs to those crates until we have agreement that we're prepared to break passing e.g. 2.0 to a method taking Into<f32>. Because I think the likely response to such a PR is "wait, what?".

@traviscross

We've speculatively submitted PRs before in these kind of cases. Such PRs said, essentially, that the code being changed was relying on something that had become an open question. But I'm happy with whatever the people pushing this forward want to do (or not do) in this regard.

@beetrees

taffy is actually already fixed from when the impl was breifly added on nightly a year ago (DioxusLabs/taffy#643): all the regressions caused by that crate are from other crates using outdated 0.3.* and 0.4.* versions of it (the fix is in 0.3.19 and 0.4.3 and later).

(I plan to do a full write-up of the Crater run soon, I just haven't had time yet.)

Labels

S-experimental

Status: Ongoing experiment that does not require reviewing and won't be merged in its current state.

S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

T-compiler

Relevant to the compiler team, which will review and decide on the PR/issue.

T-libs

Relevant to the library team, which will review and decide on the PR/issue.