-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Allow overriding lang-items from different crates #7901
Comments
I think that this would be fairly difficult to do, and the semantics should definitely be fleshed out before any work is done. When translating, if there's a spot which uses the One possible route to take that has other benefits would be to canonicalize all lang_item names to the same value. Something like So we could create a Basically
I'm curious how feasible this is. What do others think? |
You can't rely on the same trick used by |
Triage: I don't know of any progress. |
I don't think it makes sense to override these. Thanks to inter-procedural optimization, you cannot replace functions defined in a compiled binary with alternate functions. It's possible to override weak symbols defined in a dynamic library like |
…p1995 Prevent clippy::needless_lifetimes false positive in async function definition Scan `OpaqueDef` bounds for lifetimes as well. Those `OpaqueDef` instances are generated while desugaring an `async` function definition. This fixes rust-lang#7893 changelog: Prevent [`clippy::needless_lifetimes`] false positive in `async` function definition
Building on the new optional lang items, this would, for example, allow someone to substitute a new version of malloc (e.g. because they want to count the number of allocations, or have a specialised, high-performance implementation).
Only allowing it cross crate would mean there wouldn't be any confusion about which takes precedence in:
This possibly couldn't work at all, because the other crates have had the original lang-item compiled into the appropriate places.
The text was updated successfully, but these errors were encountered: