Polymorphic types don't seem to work across crate boundaries

[marijnh]

If I use the rustc crate, I can't match on a std.option.t coming from that crate — firstly, the compiler thinks it is of type rustc.std.option.t, but even if I qualify it like that, I get errors like

error: mismatched types: expected rustc.std.option.t but found rustc.std.option.t

Maybe this isn't planned for rustboot. It makes it rather hard to pretty-print an AST, but that can be worked around by moving all this into the rustc crate.

(At some point, having the parser in a separate crate, and with an API that doesn't require creation of compiler sessions and environments, would be nice too.)

[graydon]

Yeah, this is a bug in rustboot; you have a 'diamond import' situation (you're importing std from two locations) and it's not properly mapping the two crates to the same crate ID. If you like I can have a quick go at fixing it today -- I fixed the typestate bug you noted yesterday, fwiw, thanks for the motivation! -- but if the solution appears to be really involved I'd recommend just moving your work into rustc. Sorry, I forgot about this rustboot bug. I've actually seen it before, just .. I guess didn't fix it. It's definitely a bug and definitely ought to be implemented 'correctly' in rustc.

(I think possibly we shied away from fixing it in rustboot because we hadn't decided on an equality operation on crates -- what it means for crate A and crate B to be equal -- but we have a better idea of that now, and we have to bite the bullet eventually!)

[graydon]

I had a further look into this today and it'll take some serious work to fix. Opaque IDs never got crate-qualified in rustboot (I thought we got to that, but apparently not) and dwarf it not, in any case, carrying around crate ID mappings. So it would take several days to fix; I'd prefer to just avoid it if you can stand moving your work into rustc.

I also spent a few more hours profiling rustboot and looking for more low-hanging fruit. Very little is forthcoming; the main source of compile-time with rustboot is simply that we generate far too much code, and a large fraction of that is glue calls (copy/drop). We can't make those much more efficient without a lot of work (reworking the glue ABI or something), but again, we're talking days of work. If it were the long-term compiler I'd dig in, but for something slated to die soon I am hesitant.

Wish I had better answers on these matters. I'll look a bit more on monday but I don't think I'm likely to find much.

[marijnh]

Fair enough. I'll accept these as unavoidable for the time being, and try to work out an acceptable compilation routine.