I believe 'backtrace' and 'track_caller' are currently nightly only but not in stable. Is there a timeline for when these features will be moved in to stable? (I have a code base that sometimes run into linking problems w/ nightly + incremental compile, but I also want to use these two features on.)
if you are having trouble with nightly now you'll see that trouble on stable in 6-12 weeks unless someone fixes it on nightly in the mean time.
so, please report these bugs :)
I can't help with your actual question though, sorry. Maybe try finding the tracking issues to see what the outstanding concerns are?
they should be in this list
I'm doing something like tdd in Rust, running a recompile + unit test ever 5-10 minutes. The 'bug' I run into is that on my 20-30k loc project, with incremental compile enabled, every few hours, rustc runs into a linking error. The only way to fix this linking error is a 'cargo clean', after which it rebuilds fine. The source code is not open source. I have no idea how to even begin filing a bug for this.
I've also had the occasional linking error with
cargo watch test, but a
cargo clean has always solved it.
This bug is non-deterministic, no idea how to reproduce, depends on some hidden state (cached compile units in target/debug) that may be GB's in size. I've been using nightly I think from he start, but this issue has pushed me to stable.
Are you on recent nightly?
@Lokathor : Yeah, IntelliJ/Code are probably calling 'cargo test' behind the scenes. So I guess we've made the progress of narrowed it from 'cargo build' to 'cargo test' :-)
I seem to recall a similar bug being fixed by @pnkfelix not too long ago...
I am on
rustc 1.44.0-nightly (7f3df5772 2020-04-16)
@simulacrum : It's currently uninstalled, but I think I did a "rustup toolchain install nightly" within the past few days (and got a link error after that in vs code)
it's almost certainly an incremental bug -- one thing that may work is if you can catch it and the codebase is public you can create a zip / tarball of the project state as a whole (including target directory) and then post that in an issue
(this is pure speculation); I think one way to cause it involves trait names that overlap so if trait Foo1T nas a fn foo, and trait Foo2T has a fn foo, then there are situations where ...
(and some object impls both Foo1T and Foo2T)
I agree it's almost certainly an incremental issue. 'cargo clean' and/or rm target/debug has always fixed it
codebase is definitely not public; if I can manage to trigger the linking error again, would it be helpful to the compiler team ?
without having the code and a snapshot of the target directory probably no
unfortunately linker errors as a result of incremental without a reproduction that is reliable are pretty much impossible to fix I think
good to know; also, is there some other linker that can be used for faster linking (during dev time)? for whatever reason, linking seems to take quite a bit of time these days
lld is the common recommendation