"Unfortunate copy" in syntax::parse::new_parser_from_file

[catamorphism]

syntax::parse::new_parser_from_file has a FIXME that says "this copy is unfortunate". Actually I think the comment is out of date, because all that's being copied is a box. However, I'm wondering about the related issue of whether codemap::filemap should have an @str field as it currently does, or whether that should be a str (since it's not shared). I don't understand what's going on well enough to really fix this (though I tried), so I'm filing this so someone who knows why the comment is there (like maybe @brson ) can weigh in.

[brson]

It's there because codemap is expecting a boxed string and we have a string trapped inside a result type, so we have to do a copy of the full source code. pfox has a branch somewhere with result::unwrap which could be used to extract the string from the result and move it into the box.

[catamorphism]

Could codemap just have a str field instead (does it need to be shared)?

[brson]

It looks like codemap doesn't need to box that string, but that doesn't actually help because we can't get the string out of the result without copying.

[catamorphism]

The fix involving unwrap seems to be implemented and the FIXME is no longer there. Closing.

[jbclements]

@catamorphism : looks to me like there's still a FIXME in librustc/driver/driver.rs that points to this. It looks like it only happens for parsing input strings, so it may not be such a big deal, but it's still there....

[emberian]

I have this fixed locally, will be in my next batch of libsyntax cleanup.

[emberian]

[thestinger]

@cmr: is this still an issue?

[emberian]

Yes. See libsyntax/parse/mod.rs, the to_managed on line 278 is part of it. Using ~str rather than @str is the fix the above graph demonstrates.

[sanxiyn]

What happened to this?

[alexcrichton]

Closing, this looks like it's long out of date, and many things have internally changed in the compiler in the meantime. I can't find anything reference in this issue any more.