-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
cast to &Trait causes code to segfault on method call #5008
Comments
Fun fact: the |
Possibly related to #4333? |
Not critical for 0.6; removing milestone |
The code does not compile for me, by the way; I get the following error from rustc:
|
Probably related; this results in a segfault:
Switching from owned to managed boxes removes the crash. |
I vaguely recall from this meeting that we are going to remove "as ~Trait"; it seems like that might "address" the note from @thatfreakingguy (unless the analogous assignability-code also crashes). In any case, I worry that the two issues are actually orthogonal; lets not conflate them prematurely. (That is, I'd like to keep the focus of the discussion on @mitsuhiko's original report, unless someone can provide concrete evidence that the two issues are related.) Also, I do not want to nominate this bug for a maturity milestone nor close it until I determine what the current status of the original test is. (Last I checked, rustc flagged it as erroneous; that's one reason why I am saying I am not convinced it is related to the note from @thatfreakingguy.) It could be that the code needs to be massaged slightly to get past rustc's checks, or it could be that there was a fundamental problem in it that rustc is now rightfully flagging. I just don't know, yet. |
Trying to reproduce on current master a bit fruitless. I got this far: trait Debuggable {
fn debug_name(&self) -> ~str;
}
struct Thing {
name: ~str,
}
impl Thing {
fn new() -> Thing { Thing { name: ~"dummy" } }
}
impl Debuggable for Thing {
fn debug_name(&self) -> ~str { copy self.name }
}
fn print_name(x: &Debuggable) {
println(fmt!("debug_name = %s", x.debug_name()));
}
fn main() {
let thing = Thing::new();
print_name(&thing as &Debuggable);
} which yields
|
Example 1 trait Debuggable {
fn debug_name(&self) -> ~str;
}
#[deriving(Clone)]
struct Thing {
name: ~str,
}
impl Thing {
fn new() -> Thing { Thing { name: ~"dummy" } }
}
impl Debuggable for Thing {
fn debug_name(&self) -> ~str { self.name.clone() }
}
fn print_name(x: &Debuggable)
{
println(fmt!("debug_name = %s", x.debug_name()));
}
fn main() {
let thing = Thing::new();
print_name(&thing as &Debuggable);
} I guess it isn't an issue anymore. Any opinions? |
Huzzah! Flagging as needstest |
Closes rust-lang#2074. Closes rust-lang#5008. Closes rust-lang#7519. Closes rust-lang#7673. Closes rust-lang#7770. Closes rust-lang#8171.
Do not trigger `let_and_return` lint on macros Fixes rust-lang#4997 changelog: Fix false positive in `let_and_return`
This code segfaults with this traceback:
It fixes itself if the
&Trait
is changed to@Trait
.The text was updated successfully, but these errors were encountered: