-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
[experiment] Introduce a reliable way to refer to the standard library and use it for calling panic
#62002
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
cc @rust-lang/lang |
What prevents us from writing this as |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
@joshtriplett If |
We discussed this in the @rust-lang/lang meeting and were all fairly apprehensive about this approach. There are a number of strange interactions e.g. around As a potential alternative, we discussed that Example: mod some_private_mod {
#[no_mangle]
pub extern "C" fn __panic_internal() {
println!("the one from core");
}
}
extern "C" {
fn __panic_internal();
}
pub fn function_in_core() {
unsafe { __panic_internal() }
} in crate // whether or not this function is included will change what is printed
// this is analogous to including `std` or not
#[no_mangle]
pub extern "C" fn __panic_internal() {
println!("the one from std");
}
fn main() {
// prints "the one from std" or "the one from core" based on whether or not the
// above function is commented out
corelike::function_in_core();
} |
@nikomatsakis also mentioned @alexcrichton might have opinions about my linkage hack idea, so cc'ing them here. |
Sorry I haven't followed this a ton so I wouldn't say I'm at all up to speed on all the relevant ins and outs here. That being said there's an important difference between the std/core macros which I think justifies their current state. For invocations like That functionality difference may be resolvable with linkage still, but I'd have to dig into it myself to get a better idea. I'm not really entirely certain though what the motivation is to make these hygienic. I feel like it'd be nice to do so but it doesn't really seem like we need to bend over backwards. I could be missing something though! |
I'll close this PR since this should preferably be solved through lang items and/or linkage rather than name resolution, and I won't work on that in the near future.
I'm not sure what is the practical impact, but the situation with the |
The second part of #61629.
__rustc_standard_library
is introduced (it can be further uglified as much as necessary, but it must be a valid identifier).__rustc_standard_library
refers to the standard library crate when used in a path.#![no_std]
settings, regardless of shadowing or renaming.This PR is minimal, but
__rustc_standard_library
could also be used for std paths likestd::option::Option
in built-in derives, which currently use a special compiler hack ($crate
in built-in macros specifically is re-routed to the standard library).Unlike
$crate
re-routing, this PR's approach feels like a "proper" solution to the problem to me, the only downside is an introduction of a niche keyword.TODO: Feature gating.