I don't really think this is a bug, but according to the error message I received ("note: the compiler unexpectedly panicked. this is a bug.") it is. It's more likely something I'm doing wrong, though (I've just started to learn the language). I'm trying to compile the "guessing game" example from "The Rust Programming Language" and received this error message. I have been able to compile and run the "Hello World" program, though.
Attached is a listing of the source code and a screen capture. If there's any more information you need, let me know.
David.
use std::io;
fn main() {
println!("Guess the number!");
println!("please input your guess.");
let mut guess = String::new();
io::stdin().read_line(&mut guess).expect("Failed to read line");
println!("You guessed: {}",guess);
}
It looks like Dropbox was backing up an incremental compilation folder while the compiler tried to delete it. I don't know what the correct behavior should be: Crash, silently fail, retry, or something else?
Ah, good catch, I didn't notice the "dropbox" in the folder name. Yeah, that seems like the most likely scenario.
I think this should be an error, just not an internal compiler error.
@dkettle I would suggest, at a minimum, arranging to put the results of compilation outside a Dropbox folder; you can set Rust's target directory, for instance.
I think you're right. I couldn't see any processes running that were obviously related to Rust, although I'm not sure what names the processes would have. So I rebooted the computer and I was able to compile and run the program. I haven't been able to reproduce the problem since I rebooted, even though I'm still compiling inside a Dropbox folder. I also do some development in Python, C, etc., in Dropbox folders and this has never been a problem. If the problem reoccurs, I'll move my Rust folder outside of my Dropbox folder and see if that fixes the problem. Maybe it was just a timing issue.
P.S. I looked in the 'incremental' directory and noticed that there are dozens of object files with names that seem to be randomly generated. I guess these are the files that the compiler couldn't delete. Is it safe to delete them manually?
These files are cached intermediary compilation products, kept around to speed up future recompilations of a project. In that sense, you can think about them like the .o files of C/++, though the underlying compilation process is actually different.
That's another case where it'd help if Cargo was using a proper system temp directory (e.g. C:\temp\somehash\) instead of dumping temp files in ./target.
I don't think the system temporary directory is necessarily the right place, as these files have value to avoid rebuilds, so they should stick around as long as the user has space. Something like $XDG_CACHE_DIR might make sense as an option, though. That would certainly make it easier to clean up object files in a central place.
We might want to talk about that on one of the cargo issues or threads that's already talking about sharing builds between projects on the system, since those seem quite related.
