Skip to content
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

"unsafe" on methods doesn't work #3080

Closed
bblum opened this issue Aug 1, 2012 · 10 comments
Closed

"unsafe" on methods doesn't work #3080

bblum opened this issue Aug 1, 2012 · 10 comments
Labels
A-type-system Area: Type system E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@bblum
Copy link
Contributor

bblum commented Aug 1, 2012

This compiles, and shouldn't:

enum x = ();
impl x {
    unsafe fn with() { }
}

fn main() {
    x(()).with();
}
@eholk
Copy link
Contributor

eholk commented Aug 1, 2012

This might be related to #2587.

@vertexclique
Copy link
Member

Latest head solved this with throwing error case

@eholk
Copy link
Contributor

eholk commented Nov 26, 2012

I just tried compiling this program with the latest incoming, and it still compiled successfully. @vertexclique, did you say you got an error with this test program?

@catamorphism
Copy link
Contributor

Still wrong as of b60a0be (no error message)

@kud1ing
Copy link

kud1ing commented Feb 6, 2013

Can this be closed? I have a working example of unsafe fn foo() methods.

@pnkfelix
Copy link
Member

Indeed, I am wondering the same thing as kud1ing.

I quickly hacked up an example program that uses unsafe features, and it seems to compile and run properly. (I've included the example at the end of this comment.)

I do not know enough about how traits and methods are implemented, especially in the case of dynamic dispatch in object types, to say that we currently support unsafe methods; all I can see is that we do not obviously fail to support them. :) So I won't close this ticket immediately, but I'd like someone else on the team to consider doing so (or provide me with a pointer to something saying why we do not and/or can not support unsafe methods).


unsafe fn f(x:*int) -> int {
    let p = x as int;
    let q = p + 8; // danger: assumes sizeof(int*) in a vec is 8 !
    let y = q as *int;
    *y
}

trait x { unsafe fn uwith(&self, x:*int) -> int; }
impl x for () {
    unsafe fn uwith(&self, x:*int) -> int {  3+f(x) }
}

impl x for @() {
    unsafe fn uwith(&self, x:*int) -> int { 13+f(x) }
}

impl x for @int {
    unsafe fn uwith(&self, x:*int) -> int { 23+f(x) }
}

fn main() {
    let obju = ();
    let objo = @();
    let obji = @3;
    let vec = [0,7,1000];
    io::print(fmt!("%?\n", obju.uwith(&vec[0])));
    io::print(fmt!("%?\n", objo.uwith(&vec[0])));
    io::print(fmt!("%?\n", obji.uwith(&vec[0])));
}

@pnkfelix
Copy link
Member

(either way, this is not a 0.6 milestone issue.)

@pnkfelix
Copy link
Member

In case it is not clear: I was able to compile and run the code from the comment above. I had meant for this to demonstrate that unsafe methods might be implemented and might work; Niko separately pointed out that the code in the comment also demonstrates that there is a bug, since the calls to the unsafe uwith method should have been required to be enclosed in an unsafe block within their invocations inside main.

@nikomatsakis
Copy link
Contributor

More examples in #6331

@brson
Copy link
Contributor

brson commented Jul 19, 2013

This is fixed.

@brson brson closed this as completed Jul 19, 2013
bors pushed a commit to rust-lang-ci/rust that referenced this issue May 15, 2021
Format macro calls with item-like arguments
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
This is a follow-up to rust-lang#3063 that turns off that MIR pass while
compiling `std` as well to ensure any bugs of the same nature in `std`
are captured by Kani.

Resolves rust-lang#3079
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-type-system Area: Type system E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

No branches or pull requests

8 participants