cargo run does not reflect any code changes in main.rs

Question

cargo run or cargo rebuild ignore any code changes.

I have a program

fn main() {
    println!("Hello, World!");
}

Then I do cargo run and see:

   Compiling myproject v0.1.0 (/Volumes/.../myproject)
    Finished dev [unoptimized + debuginfo] target(s) in 0.52s
     Running `target/debug/myproject`
Hello, World!

Then I change the code to:

fn main() {
    println!("Hello, Worldaefafeff!");
    print!("22222412414");
}

cargo run again:

   Compiling myproject v0.1.0 (/Volumes/.../myproject)
    Finished dev [unoptimized + debuginfo] target(s) in 0.76s
     Running `target/debug/myproject`
Hello, World!

Even if I see the "Compiling" line that means cargo knows that file has been changed, the output is the same. The same happens when I run cargo build. Do I need to run cargo clean every time?

I see that many people say I'm doing something wrong. I repeated all my steps in one terminal. Is there something wrong?

Genychs-iMac:~ defake$ z /Volumes/MainBrain/Programming/Projects/Personal
Genychs-iMac:Personal defake$ cargo new notworking
     Created binary (application) `notworking` package
Genychs-iMac:Personal defake$ cd notworking/
Genychs-iMac:notworking defake$ cargo run
   Compiling notworking v0.1.0 (/Volumes/MainBrain/Programming/Projects/Personal/notworking)
    Finished dev [unoptimized + debuginfo] target(s) in 0.55s
     Running `target/debug/notworking`
Hello, world!
Genychs-iMac:notworking defake$ printf 'fn main() {' > src/main.rs
Genychs-iMac:notworking defake$ printf '\n\tprintln!("Other text");' >> src/main.rs
Genychs-iMac:notworking defake$ printf '\n}\n' >> src/main.rs
Genychs-iMac:notworking defake$ cargo run
   Compiling notworking v0.1.0 (/Volumes/MainBrain/Programming/Projects/Personal/notworking)
    Finished dev [unoptimized + debuginfo] target(s) in 0.33s
     Running `target/debug/notworking`
Hello, world!
Genychs-iMac:notworking defake$ cd src
Genychs-iMac:src defake$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
     Running `/Volumes/MainBrain/Programming/Projects/Personal/notworking/target/debug/notworking`
Hello, world!
Genychs-iMac:src defake$ cat main.rs
fn main() {
    println!("Other text");
}
Genychs-iMac:src defake$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
     Running `/Volumes/MainBrain/Programming/Projects/Personal/notworking/target/debug/notworking`
Hello, worlGenychs-iMac:src defake$ cargo clean
Genychs-iMac:src defake$ cargo run
   Compiling notworking v0.1.0 (/Volumes/MainBrain/Programming/Projects/Personal/notworking)
    Finished dev [unoptimized + debuginfo] target(s) in 0.48s
     Running `/Volumes/MainBrain/Programming/Projects/Personal/notworking/target/debug/notworking`
Other text
Genychs-iMac:src defake$

"Compiling" happens, but the output is the same. The second time there's no "Compiling" step. I clearly don't understand what I'm doing wrong.

And there's no mistake, the penultimate launch actually shows "Hello, worl". I did copy the terminal content properly

Genychs-iMac:secondtry defake$ cargo run
   Compiling secondtry v0.1.0 (/Volumes/MainBrain/Programming/Projects/Personal/secondtry)
    Finished dev [unoptimized + debuginfo] target(s) in 1.13s
     Running `target/debug/secondtry`
Other text 15
Genychs-iMac:secondtry defake$ ls -l target/debug/
total 776
drwxr-xr-x  0 defake  staff       0 Jul 20 18:03 build
drwxr-xr-x  0 defake  staff    4096 Jul 20 18:03 deps
drwxr-xr-x  0 defake  staff       0 Jul 20 18:03 examples
drwxr-xr-x  0 defake  staff       0 Jul 20 18:03 incremental
drwxr-xr-x  0 defake  staff       0 Jul 20 18:03 native
-rwxr-xr-x  2 defake  staff  291112 Jul 20 18:03 secondtry
-rw-r--r--  1 defake  staff     159 Jul 20 18:03 secondtry.d
lrwxr-xr-x  1 defake  staff       0 Jul 20 18:03 secondtry.dSYM -> deps/secondtry-d4f28f61785f1e66.dSYM

Then updated the code

Genychs-iMac:secondtry defake$ cargo run
   Compiling secondtry v0.1.0 (/Volumes/MainBrain/Programming/Projects/Personal/secondtry)
    Finished dev [unoptimized + debuginfo] target(s) in 0.36s
     Running `target/debug/secondtry`
Other text 15
Genychs-iMac:secondtry defake$ ls -l target/debug/
total 776
drwxr-xr-x  0 defake  staff       0 Jul 20 18:03 build
drwxr-xr-x  0 defake  staff    4096 Jul 20 18:04 deps
drwxr-xr-x  0 defake  staff       0 Jul 20 18:03 examples
drwxr-xr-x  0 defake  staff       0 Jul 20 18:03 incremental
drwxr-xr-x  0 defake  staff       0 Jul 20 18:03 native
-rwxr-xr-x  2 defake  staff  291112 Jul 20 18:04 secondtry
-rw-r--r--  1 defake  staff     159 Jul 20 18:04 secondtry.d
lrwxr-xr-x  1 defake  staff       0 Jul 20 18:03 secondtry.dSYM -> deps/secondtry-d4f28f61785f1e66.dSYM
Genychs-iMac:secondtry defake$ strings target/debug/secondtry
Other text 15
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
 <... and possibly more>RUST_BACKTRACE0full  :  -
<unknown>

  at .:  at
main
called `Option::unwrap()` on a `None` valuesrc/libcore/option.rscalled `Result::unwrap()` on an `Err` valuefailed to get environment variable ``: src/libstd/env.rs
src/libstd/sync/once.rsassertion failed: state & STATE_MASK == RUNNINGOnce instance has previously been poisoned
assertion failed: `(left == right)`
  left: ``,
 right: ``memory allocation of  bytes failed
<unnamed>' panicked at '',
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
thread panicked while processing panic. aborting.
thread panicked while panicking. aborting.
failed to initiate panic, error
src/libstd/sys/unix/os.rsstrerror_r failure
src/libstd/sys/unix/rwlock.rsrwlock maximum reader count exceededrwlock read lock would result in deadlock
Box<Any>thread '...
called `Option::unwrap()` on a `None` valuesrc/libcore/option.rsfailed to write the buffered data
stack overflowsrc/libstd/sys/unix/stack_overflow.rsfailed to allocate an alternative stack
called `Option::unwrap()` on a `None` valuesrc/libcore/option.rscalled `Result::unwrap()` on an `Err` valueuse of std::thread::current() is not possible after the thread's local data has been destroyedsrc/libstd/thread/mod.rsinconsistent park stateassertion failed: `(left == right)`
  left: ``,
 right: ``: park state changed unexpectedly
failed to generate unique thread ID: bitspace exhaustedthread name may not contain interior null bytesinconsistent state in unpark
data provided contains a nul byteunexpected end of fileother os erroroperation interruptedwrite zerotimed outinvalid datainvalid input parameteroperation would blockentity already existsbroken pipeaddress not availableaddress in usenot connectedconnection abortedconnection refusedpermission denied
 (os error )
connection resetentity not found
already borrowed
: src/libcore/result.rs
cannot access stdout during shutdownfailed printing to src/libstd/io/stdio.rsstdout
failed to write whole bufferformatter errorsrc/libstd/sys_common/at_exit_imp.rsassertion failed: queue != DONE
src/libstd/sys/unix/mod.rsassertion failed: signal(libc::SIGPIPE, libc::SIG_IGN) != libc::SIG_ERR
src/libcore/slice/mod.rsassertion failed: `(left == right)`
  left: ``,
 right: ``: destination and source slices have different lengths
src/libstd/sync/condvar.rsattempted to use a condition variable with two mutexes
SomeNoneinternal error: entered unreachable codesrc/liballoc/raw_vec.rsTried to shrink to a larger capacity
/private/tmp/rust-20190704-90201-o56ua9/rustc-1.36.0-src/src/libcore/str/pattern.rs
attempt to calculate the remainder with a divisor of zero
src/liballoc/vec.rsassertion failed: end <= len
__rust_begin_short_backtracePoisonError { inner: .. }failed to allocate libbacktrace state
src/libstd/sys/unix/thread.rsassertion failed: PAGE_SIZE != 0
src/libstd/sys/unix/thread.rsfailed to allocate a guard pagefailed to protect the guard page
failed to write whole bufferformatter error
unexpected return value while unwinding:
src/libstd/sys/unix/backtrace/tracing/gcc_s.rs
UnwindError
NulErrorkind
/private/tmp/rust-20190704-90201-o56ua9/rustc-1.36.0-src/src/libcore/str/pattern.rsalready mutably borrowedcalled `Option::unwrap()` on a `None` valuesrc/libcore/option.rs
AccessError
cannot access a TLS value during or after it is destroyed
__rust_begin_short_backtrace
src/libstd/sys_common/thread_info.rsassertion failed: c.borrow().is_none()fatal runtime error:
thread '' has overflowed its stack
<unknown>StringErroralready borrowedcalled `Option::unwrap()` on a `None` valuesrc/libcore/option.rs
/private/tmp/rust-20190704-90201-o56ua9/rustc-1.36.0-src/src/libcore/str/pattern.rscalled `Option::unwrap()` on a `None` valuesrc/libcore/option.rscalled `Result::unwrap()` on an `Err` value.llvm.
E._ZNZN::_$.@*&<>()$C$,$u7e$~$u20$ $u27$'$u3d$=$u5b$[$u5d$]$u7b${$u7d$}$u3b$;$u2b$+$u22$"
__ZN$SP$$BP$$RF$$LT$$GT$$LP$$RP$
: src/libcore/result.rs_URC_FAILURE_URC_CONTINUE_UNWIND_URC_INSTALL_CONTEXT_URC_HANDLER_FOUND_URC_END_OF_STACK_URC_FATAL_PHASE1_ERROR_URC_FATAL_PHASE2_ERROR_URC_FOREIGN_EXCEPTION_CAUGHT_URC_NO_REASON
_URC_NORMAL_STOPsrc/liballoc/raw_vec.rscapacity overflow0x00010203040506070809101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899
src/libcore/option.rs
,  { } }(
5556

:index out of bounds: the len is  but the index is called `Option::unwrap()` on a `None` valuesrc/libcore/option.rs
./?\]_
)147:;=IJ]
)14:;EFIJ^de
)EIWde
EIde
INOWY^_
FGNOXZ\^~
/_&./
NOZ[
no7=?BE

';>NO
6=>V
67VW
)14:EFIJNOdeZ\
;>fi
:?EQ
 #%&(38:HJLPSUVXZ\^`cefksx}
?qr{^"{
PI73
<dS

t
 Y'

ParseIntErrorUnderflowInvalidDigitEmpty
ZeroOverflow
) when slicing `
BorrowError
BorrowMutErrorcalled `Option::unwrap()` on a `None` valuesrc/libcore/option.rs
src/libcore/slice/mod.rsindex  out of range for slice of length slice index starts at  but ends at attempted to index slice up to maximum usize
src/libcore/str/mod.rs[...]byte index  is out of bounds of ``begin <= end ( is not a char boundary; it is inside ) of `
Utf8Errorvalid_up_toerror_len <=  (bytes called `Option::unwrap()` on a `None` valuesrc/libcore/option.rssrc/libcore/fmt/mod.rs
src/libcore/str/pattern.rs
src/libcore/unicode/bool_trie.rs
malloc
realloc
.debug_info
unrecognized DWARF version
DWARF underflow
%s in %s at %d
abbrev offset out of range
.debug_abbrev
LEB128 overflows uint64_t
invalid abbreviation code
DW_FORM_strp out of range
unrecognized DWARF form
unrecognized address size
signed LEB128 overflows uint64_t
ranges offset out of range
.debug_ranges
unit line offset out of range
.debug_line
unsupported line number version
invalid directory index in line number program header
invalid directory index in line number program
invalid file number in line number program
invalid file number in DW_AT_call_file attribute
abstract origin or specification out of range
invalid abstract origin or specification
function ranges offset out of range
failed to read executable information
/proc/self/exe
/proc/curproc/file
/proc/%ld/object/a.out
libbacktrace could not find executable to open
close
lseek
read
file too short
backtrace library does not support threads
executable file contains out of range command offset
executable file is missing an identifying UUID
__TEXT
executable is missing __TEXT segment
dSYM file contains out of range string table index
dSYM file contains unterminated string
dSYM file is missing an identifying uuid
dSYM file contains out of range command offset
__DWARF
/Contents/Resources/DWARF
could not open DWARF directory in dSYM
executable file is not loaded
could not open directory containing executable
.dSYM
__debug_info
__debug_line
__debug_abbrev
__debug_ranges
__debug_str
no debug info in Mach-O executable
no symbol table in Mach-O executable
"#$%&
,-./0
>?@ABCDEF

What I noticed is that if I run target/debug/secondtry the output is outdated, but if I run target/debug/deps/secondtry-8f71784d4f2f1e66 then I get correct output.

Answer 1

This happened in my case while working on a server clocking app. Manual updates in the system time to test the feature were failing to show changes if the clock was backdated.

Hope this helps someone.

Answer 2

This is an old thread, but I will post what worked for me.

The problem OP described is exactly what is happening to me right now. I am on a btrfs partition using Fedora 36 (bash).

I tried using the sync command, but the filesystem cache wasn't the problem. Tried to delete Cargo.lock, but still not the problem. I tried to recursively search all files for old strings (strings that rust run is currently compiling), but found nothing.

Well, the solution was simpler than I thought. I just updated the source files timestamp (just the main.rs in my case), using the touch command, like this (inside the project directory):

$ touch src/main.rs

After that the cargo run and build found the updated file and compiled like a charm.

Answer 3

It turns out no one answered this question, so I'll close it.

I suppose the problem was related to the combination of cargo fs operations and mac working with external HDDs. As I wrote in the comments, it worked on mac's SSD and after I migrated to a new laptop the problem is not actual for me anymore.

If somebody meets the same poltergeist again, try to use a different disk to store the project on.

Answer 4

When I encountered this issue, what I was doing wrong was that I had added a main.rs to the project root instead of the /project_name/src/ folder.

When you first run cargo new project_name it will create the directory structure for you, as well as add a /src/ which contains a main.rs, this is where you should be working.

Answer 5

print! is not flushed immediately.

stdout is frequently line-buffered by default so it may be necessary to use io::stdout().flush() to ensure the output is emitted immediately.