Skip to content

ICE with cross-crate resources and channels #2444

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
eholk opened this issue May 25, 2012 · 5 comments
Closed

ICE with cross-crate resources and channels #2444

eholk opened this issue May 25, 2012 · 5 comments
Assignees

Comments

@eholk
Copy link
Contributor

eholk commented May 25, 2012

Here's a test program:

import comm::{port, chan, methods};
use std;
import std::arc;

enum e<T: send> { e2, e(chan<arc::arc<T>>) }

resource r<T: send>(x : comm::chan<e<T>>) {
    x.send(e2);
}

fn foo<T: send const>(-x : T) -> r<T> {
    fail
}

fn main() {
    foo([some(1)]);
}

This gives an internal compiler error. The problem is that type variable leaks into trans. If I define a resource like arc::arc in the same file and use that instead, the program compiles successfully. Here is some of the log from compiling this:

rust: "cleanup_and_leave: leaving [block 389]"
rust: "new insn_ctxt: cleanup_and_Br"
rust: "new insn_ctxt: cleanup_and_leave"
rust: "cleanup_and_leave: leaving [block 7fb923853d50]"
rust: "cleanup_and_leave: leaving [block 391]"
rust: "new insn_ctxt: finish_fn"
rust: "new insn_ctxt: tie_up_header_blocks"
rust: "new insn_ctxt: trans_args"
rust: "new insn_ctxt: alloc_ty"
rust: upcall fail 'Assertion !ty::type_has_params(t) failed', /Users/eholk/Documents/projects/mozilla/rust/src/rustc/middle/trans/base.rs:4233

The uninstantiated type variable is the data field in the arc.

@nikomatsakis
Copy link
Contributor

@eholk and I tracked this down. The problem is how we handle shape tables for generic enums. We still generate one table for the 'Generic enum' and then encode the values of the type parameters. This is pre-monomorphization thinking. We need to rewrite that code.

@ghost ghost assigned nikomatsakis May 25, 2012
@eholk
Copy link
Contributor Author

eholk commented May 25, 2012

Here's a simpler test case:

use std;
import std::arc;

enum e<T: const> { e(arc::arc<T>) }

resource r(x : e<int>) {
}

fn foo() -> r {fail;}

fn main() {
    let x = foo();
}

@eholk
Copy link
Contributor Author

eholk commented May 25, 2012

Here's an even simpler test. It's not a cross-crate issue at all.

resource r<T> (x: T) { fail }

enum e<T: const> { e(r<T>) }

fn foo() -> e<int> {fail;}

fn main() {
    let x = foo();
}

eholk added a commit that referenced this issue May 29, 2012
…n tasks.

Also added some asserts and logging to trans.

Modified graph500 to use the shared_arc, but this unfortunately doesn't work due to #2444.
nikomatsakis added a commit that referenced this issue May 29, 2012
this is hacky, but shape code is going away anyway and I didn't
want to invest too much effort into it
@nikomatsakis
Copy link
Contributor

I believe this to be fixed now.

@eholk
Copy link
Contributor Author

eholk commented May 30, 2012

I just verified that this fixes the program that originally caused this problem.

eholk added a commit that referenced this issue May 30, 2012
Sadly, this exposes another ICE when trying to use the new version with Graph500
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
…lfJung

Add default impls for `FileDescriptor` methods

I felt like it was just noisy to have to write the "can't do this here" defaults
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants