-
Notifications
You must be signed in to change notification settings - Fork 14k
Check for intrinsic to fn ptr casts in unified coercions #149160
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
Check for intrinsic to fn ptr casts in unified coercions #149160
Conversation
|
r? @chenyukang rustbot has assigned @chenyukang. Use |
This comment has been minimized.
This comment has been minimized.
|
Can you please add regression test and fix commit description (remove #149143 from it) The fix itself seems reasonable to me |
|
|
We don't store tests under crates but rather under |
Yeah my bad I searched for |
Very likely it were not a tests, but maybe a comments or something that explains that this part of code addresses an issue |
|
For some reason my file picker really likes |
|
Is there something particular you searching for that I can help you with? |
20a2f5a to
afb35ba
Compare
|
Alright I got it, I was just fighting with how the error messages need to be specified. I'm not sure I did it correctly but the test tool doesn't complain anymore. |
|
it looks like flake.nix got leaked in this pr :) |
|
Hehe oops |
afb35ba to
9dfb004
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's wait on CI green (I know it will be green but just to make 1000% sure)
|
It was kinda annoying getting nix to work with it, since I either had to use Is there any better way to do this? |
|
Hmm, I don't actually use Nix, so I can't help here, but, you might want to join the Rust Zulip, think of it as a Discord for Rust developers You can create a topic there about Rust development on Nix, and you'll very likely get some answers from people who actually work with it |
|
Alright will do, thanks for the help btw! |
|
Oh I just realized the ICE still happens if I switch the branches 😄 |
|
Hm, can you show the example |
fn main() {
unsafe {
let f = if true {
safe_transmute
} else {
std::mem::transmute
};
let _: i64 = f(3i64);
}
}
unsafe fn safe_transmute<A, B>(x: A) -> B {
panic!()
} |
|
I don't get ICE with your fix, it just panics, but... it should panic gh-Kivooeo@dev-desktop-eu-1 ~/rust (pr-branch) [101]> ./build/aarch64-unknown-linux-gnu/stage1/bin/rustc ~/test_/src/main.rs
warning: unused variable: `x`
--> /home/gh-Kivooeo/test_/src/main.rs:13:32
|
13 | unsafe fn safe_transmute<A, B>(x: A) -> B {
| ^ help: if this is intentional, prefix it with an underscore: `_x`
|
= note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default
warning: 1 warning emitted
gh-Kivooeo@dev-desktop-eu-1 ~/rust (pr-branch)> ./main
thread 'main' (3589235) panicked at /home/gh-Kivooeo/test_/src/main.rs:14:5:
explicit panic
note: run with `RUST_BACKTRACE=1` environment variable to display a backtraceHm, it don't give error for some reason |
|
Now it works for me too, I am just confused at this point. I guess I should use |
|
I don't know, should this give error in both cases or just in the one from issue? |
|
Both cases should error |
|
At very first glance, it seems that you also should add this to |
|
I'm not sure what you mean, it errors in both cases |
|
Should I add a second test or just expand the other one? |
|
Just expand the current test, something like let f2 = if true { safe_transmute } else { transmute };
//~^ ERROR `if` and `else` have incompatible types
let _: i64 = f2(5i64); |
|
Oh yeah I also had to add it in |
Ensures that when coercing multiple expressions to a unified type, the same "intrinsic to fn ptr" check is applied as for other coercions.
9dfb004 to
ebf1c38
Compare
|
It's a bit weird that the note "cannot coerce intrinsics to function pointers" always points at the second expression, but that has apparently been the case before 1.84 too |
well, I always use directly the compiled compiler to test something locally and not cargo, like this |
Does rustc not use incremental compilation? |
|
it does |
|
Then I don't see how it would be immune to this, |
|
I guess I had no reason to be using it on my 'experiment' folder anyway, since I could've just used a test :) |
afaik yes the point is you directly call latest builded locally compiler with your fix, and not having trouble with cache and other stuff |
hmm good to know, more ergonomic than going through |
|
(fyi, im not going to wait on CI one more hour to merge this right away because it's 4 in a morning to me, and I would not be able to merge this later today as well, because I will lost access to internet in 3 hours for few days (in perfect scenario), so you would have to wait for another reviwer, it's very likely will be Yukang that is already assigned by a rustbot) |
You don't have to, I can wait. It's late for me too, have a good night :) And thanks again! |
|
@bors r=Kivooeo,BoxyUwU rollup |
Rollup of 5 pull requests Successful merges: - #148990 (Exhaustively specify names and stability of `--print` values) - #149127 (unwrap ret ty of `iter::ArrayChunks::into_remainder` ) - #149134 (std: sys: net: uefi: Implement read_vectored) - #149135 (Constify `residual_into_try_type`) - #149160 (Check for intrinsic to fn ptr casts in unified coercions) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of #149160 - maxdexh:fix-instrinsic-unifying-coercion-ice, r=Kivooeo,BoxyUwU Check for intrinsic to fn ptr casts in unified coercions Fixes #149143 by ensuring that when coercing multiple expressions to a unified type, the same "intrinsic to fn ptr" check is applied as for other coercions.
Fixes #149143 by ensuring that when coercing multiple expressions to a unified type, the same "intrinsic to fn ptr" check is applied as for other coercions.