Skip to content

Make std functions patchable on unsupported platforms #140451

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

Open
quininer opened this issue Apr 29, 2025 · 2 comments
Open

Make std functions patchable on unsupported platforms #140451

quininer opened this issue Apr 29, 2025 · 2 comments
Labels
C-discussion Category: Discussion or questions that doesn't represent real issues. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@quininer
Copy link
Contributor

Currently std generates dummy functions and panics on unsupported platforms. using binary patch to replace dummy functions is a practical way to implement support externally. but since dummy functions are currently inlined and optimized away, this is not possible.

Make dummy functions more patch-friendly would be helpful to ecosystem. I did some experimentation to prove this is possible. see #140440

The main motivation for this change is to support std time on wasm without intrusive dependencies. see #48564

This does not require std to guarantee the stability of dummy functions, and it is always the responsibility of the person doing the binary patch to check that the patch is correct.

There are still some unresolved issues

  1. inline(never) is not enough to prevent all optimizations, other compiler flags are needed to prevent places where Instant::now() is used from being optimized away.
  2. binary patch does not work on other std functions. for example, the File type is actually ! on unsupported platforms.

cc @bjorn3 @ChrisDenton

@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Apr 29, 2025
@RossSmyth
Copy link
Contributor

Currently std generates dummy functions and panics on unsupported platforms.

This isn't actually true. It's just wasm32-unknown-unknown (that I know of), and is widely regarded as a mistake.

@hanna-kruppe
Copy link
Contributor

The “unresolved issues” are inherent, fatal flaws of trying to do this patching post-hoc (presenting one version of the code to the compiler and then substituting another version afterwards). The proper way to allow standard library functionality to be supplied separately would be something kind of externally implementable items (#125418) so that the compiler knows which parts are supplied later. Applying this to parts of the standard library that were never designed to be pluggable also faces high hurdles w.r.t. stability (and customizing types isn’t part of any current proposal in this direction), but at least it can be made to work in principle.

This does not require std to guarantee the stability of dummy functions, and it is always the responsibility of the person doing the binary patch to check that the patch is correct.

These restrictions aren’t compatible with the motivation of simplifying the ecosystem by just letting everyone use std::time on wasm32-unknown-unknown. Either the ecosystem comes to rely on this sort of patching working and everyone uses std::time (in which case there will be pitchforks if the patching breaks) or they must still have the third-party-crate replacements to keep working without the binary patching.

@lolbinarycat lolbinarycat added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. C-discussion Category: Discussion or questions that doesn't represent real issues. labels Apr 30, 2025
@jieyouxu jieyouxu removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Apr 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-discussion Category: Discussion or questions that doesn't represent real issues. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants