Skip to content

Condition types do not support non-static-lifetime borrowed pointers #5370

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

Closed
brson opened this issue Mar 14, 2013 · 6 comments
Closed

Condition types do not support non-static-lifetime borrowed pointers #5370

brson opened this issue Mar 14, 2013 · 6 comments
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@brson
Copy link
Contributor

brson commented Mar 14, 2013

pub struct ReaderError(&'self mut int);

condition! {
    reader_error: super::ReaderError -> bool;
}

fn main() {
}
<core-macros>:63:20: 63:48 error: cannot infer an appropriate lifetime due to conflicting requirements
<core-macros>:63                     ::core::condition::Condition {
                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
note: first, the lifetime cannot outlive lifetime re_bound(br_anon(0))...
<core-macros>:63:20: 63:48 note: ...due to the following expression
<core-macros>:63                     ::core::condition::Condition {
                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
note: but, the lifetime must be valid for the static lifetime...
<core-macros>:63:20: 63:48 note: ...due to the following expression
<core-macros>:63                     ::core::condition::Condition {
                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error

@pnkfelix
Copy link
Member

�The case documented by brson in the description seems like it works now (after updating the ReaderError declaration to bind 'self ... :

% cat ~/Dev/Rust/iss5370-a.rs
pub struct ReaderError<'self>(&'self mut int);

condition! {
    pub reader_error: super::ReaderError -> bool;
}

fn main() {
}
% rustc --version
/Users/fklock/opt/rust/bin/rustc 0.6 (e650399 2013-06-12 23:10:15 -0700)
host: x86_64-apple-darwin
% rustc ~/Dev/Rust/iss5370-a.rs
warning: no debug symbols in executable (-arch x86_64)
% ~/Dev/Rust/iss5370-a
% 

... however, my attempt to investigate more carefully (by putting in a use of the condition) yielded similar problems:

% cat ~/Dev/Rust/iss5370-c.rs
pub struct ReaderError<'self>(&'self mut int);

condition! {
    pub reader_error: super::ReaderError -> bool;
}

fn main() {
    let mut x : int = 1;
    do reader_error::cond.trap(|z| {
        println(fmt!("Hi from handler I think z: %?", z));
        true
    }).in {
        println("Start of try");

        reader_error::cond.raise(ReaderError(&mut x));

        println("Finis of try");
    }
}
% rustc ~/Dev/Rust/iss5370-c.rs
/Users/fklock/Dev/Rust/iss5370-c.rs:15:45: 15:51 error: borrowed value does not live long enough
/Users/fklock/Dev/Rust/iss5370-c.rs:15         reader_error::cond.raise(ReaderError(&mut x));
                                                                                    ^~~~~~
note: borrowed pointer must be valid for the static lifetime...
/Users/fklock/Dev/Rust/iss5370-c.rs:7:10: 19:1 note: ...but borrowed value is only valid for the block at 7:10
/Users/fklock/Dev/Rust/iss5370-c.rs:7 fn main() {
/Users/fklock/Dev/Rust/iss5370-c.rs:8     let mut x : int = 1;
/Users/fklock/Dev/Rust/iss5370-c.rs:9     do reader_error::cond.trap(|z| {
/Users/fklock/Dev/Rust/iss5370-c.rs:10         println(fmt!("Hi from handler I think z: %?", z));
/Users/fklock/Dev/Rust/iss5370-c.rs:11         true
/Users/fklock/Dev/Rust/iss5370-c.rs:12     }).in {
                                       ...
error: aborting due to previous error
% 

and:

% cat ~/Dev/Rust/iss5370-b.rs
pub struct ReaderError<'self>(&'self mut int);

condition! {
    pub reader_error: super::ReaderError -> bool;
}

fn foo<'b>(err: ReaderError<'b>) -> bool {
    reader_error::cond.raise(err)
}

fn main() {
    let mut x : int = 2;
    let mut y : int = 3;
    let err = ReaderError(&x);
    do reader_error::cond.trap(|z| {
        println(fmt!("Hi from handler I think z: %?", z));
        true
    }).in {
        foo(err, &mut y);
    }
}
% rustc ~/Dev/Rust/iss5370-b.rs
/Users/fklock/Dev/Rust/iss5370-b.rs:8:29: 8:32 error: internal compiler error: Cannot relate bound region as subregion: br_anon(0)
/Users/fklock/Dev/Rust/iss5370-b.rs:8     reader_error::cond.raise(err)
                                                                   ^~~
% 

So I am going to leave this ticket open for now. The test case in the description should probably be revised to something that exposes the bug, but I do not like my current examples (they are the results of my playing around, and do not necessarily denote a sane scenario), so I am going to wait to come up with something better before revising the description.

@catamorphism
Copy link
Contributor

Re-nominating for milestone 3, feature-complete. I don't think this is backwards-incompatible.

@graydon
Copy link
Contributor

graydon commented Aug 15, 2013

accepted for backwards-compatible milestone

@pnkfelix
Copy link
Member

pnkfelix commented Sep 4, 2013

FYI, the examples I provided now consistently yield the error:

/Users/pnkfelix/Dev/Rust/iss5370-c.rs:4:22: 4:40 error: Illegal anonymous lifetime: only 'static is allowed here
/Users/pnkfelix/Dev/Rust/iss5370-c.rs:4     pub reader_error: super::ReaderError -> bool;
                                                              ^~~~~~~~~~~~~~~~~~
error: aborting due to previous error

I'm reviewing to see if this means we can close this ticket.

Update (later): Well, duh, the title of the ticket says that this is still a problem. so the question is whether we actually want to support this or not. Since condition handlers are executed in the context of where they are raised, it sounds like we should be able to do this. The current problem arises due to the implementation strategy we are using; I do not think it is intrinsic to the feature itself (of offering a condition system, at least not one where the handlers are executed in the dynamic context of where the raise occurred, so that all borrowed state should indeed still be available).

@brson
Copy link
Contributor Author

brson commented Oct 10, 2013

cc #9795

@flaper87
Copy link
Contributor

std::condition and the condition! macro were removed as of #12039

bors added a commit to rust-lang-ci/rust that referenced this issue May 2, 2020
Remove dependency on `matches` crate

The std equivalent works exactly the same.

changelog: none
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

5 participants