I am having trouble debugging a rust #[proc_macro] using traditional debugger tooling. I have found resources online, some can be found here, which suggests either expanding the macro and debugging the output or writing error messages/printlns.
I'm using CLion Rust and VSCode rust-analyzer (individually) to set breakpoints in the macro. The debugger does not execute due to compile time failures related to a panic in the proc_macro declaration. I was thinking there may be some way to step through the execution of a macro.
Related
Bear with me, I am an avid Matlab user - debugging here is very convenient: it is flexible, easy to use and fast. Coming from this, I struggle with using the basic debugging provided by Visual Studio Code (when using Python).
My basic code generation routine involves using breakpoints for the generation of new code. That is, I set a breakpoint at where I want to insert new code, then run my code up to the breakpoint and upon stopping at the breakpoint, I extend the code with the desired functionality, using the debug console to move through functions, checking the respective workspace and finally and importantly to check if the logics of my new code are right. This has always worked very well in Matlab, but does not in VS Code.
I use VS Code 1.73.1 (newest as of todays writing) and Python 3. I imagine my problem is more of a VS Code issue than related to Python, i.e. language agnostic.
Questions:
Doing what is described above in VS Code, I randomly receive a debugger notice "Timeout waiting for debuggee to spawn". Sometimes, this disappears when running the debugging button, sometimes it does not. It often appears repeatedly, and sometimes resolves after hitting the "Debug Python Code for the n-th time. Then I can debug my code for a few times without that notice until it appears again. It appears out of the blue and is highly annoying. What can I do about it? Should I need to configure anything in a launch.json, I'd need a complete and self-containing description of what (and ideally why) to do as I am really new to this way of engineering software.
The debugger is incredibly slow to reach the first debugging points. In Matlab, I reach my debugging points "immediately" after hitting "run/debug code" - in VS Code, this may take up to a minute. What can be done about this? It makes my code generation routine described above infeasible, as I frequently repeat that routine while iterating the code's design. It also leads me to the next question.
What are your thoughts on the above approach, given the VS Code and Python context? How to do better without configuring break point options? I just want a simple standard debugging configuration setting breakpoints and then clicking "Debug Python File".
What I did:
Restart VS Code, switch between "Run Python File" and "Debug Python File", randomly configure a launch.json file based on what I read (but likely did not fully understand) on internet fora.
tl;dr I'm trying to figure out why the avr-delay::delay function doesn't cause any delay when imported as an external crate, but when copy/pasting the code from avr-delay/src/lib.rs into my main.rs, it all works as expected and creates the 1000ms delays I was expecting. Source code for avr-delay here and my modified and working correctly avr-rust/blink code is here
I'm trying to learn Arduino the hard way, with Rust, and I'm doing a sort of Hello World by making an LED blink. I've gotten the light to blink at 1000ms intervals just as expected when I copy paste the contents of avr-delay's lib.rs into my main.rs, but when I import the avr-delay crate and use it that way, the delay is barely perceptible.
I've ensured I'm doing a 1:1 test by cloning the avr-delay repo and importing the local copy in my Cargo.toml, and I've tried hardcoding the CPU frequency on this line in my local copy of avr-delay just in case it was a problem with reading the env var that I'm setting or something.
I'm just really confused why the exact same code works in my main.rs but not in its own crate? Since this seems to be an issue with the build or Cargo.toml, here's how I'm actually building the bin. Could be related? I'm using the same command to build every time:
cargo +nightly-2021-01-07 build -Z build-std=core --target avr-atmega328p.json --release --verbose
Also worth mentioning that I'm playing with a knockoff Arduino, but it's still the same microcontroller (atmega328p) as an Arduino Uno, and since I can get the blinking to work sometimes it makes me think that's not the issue either.
Any help appreciated, I know this is a really specific question but I'm hoping there's something about the build or Cargo that I'm not understanding, since the code itself seems to be good.
The solution was to add #[inline(always)] to the functions in avr-delay, or add lto = true to my project's Cargo.toml. The delay code simply doesn't work when not inlined. I'm still not fully understanding why, but I'm guessing some of the low-level stuff didn't work when not inlined.
The unused imports and dead code warnings are the most common that I've found while learning Rust, and they get annoying after awhile (a very short while, like a few seconds). Especially when they are mixed with compiler errors, because it makes the console difficult to read.
I was able to turn off these warnings:
#![allow(unused_imports)]
#![allow(dead_code)]
This will disable the warnings for all builds, but I want the warnings enabled for release builds.
I tried disabling them like this:
#![cfg(dev)]
#![allow(unused_imports)]
#![allow(dead_code)]
But, this removed the entire Rust file from release builds (not what I want).
I tried to configure using cfg_attr but it had no effect for either builds.
#![cfg_attr(dev, allow(unused_imports))]
#![cfg_attr(dev, allow(dead_code))]
I have Googled and read all the related questions on StackOverflow but can't figure this out.
dev isn't a supported predicate for conditional compilation, so your examples will never include the affected code. As far as I know, the best way to detect debug mode is instead with #[cfg(debug_assertions)]. With my testing, #![cfg_attr(debug_assertions, allow(dead_code, unused_imports))] seems to work to disable the lints for debug builds but enable them in release builds.
You can see a list of supported predicates in the Rust reference.
As soon as I start writing any undefined variable in my C code in MSVC, I see a red line comes under the statement automatically. This is indeed a very good feature. But my question is how is this error reported even though the compilation has not been initiated by me?
MSVC has a special background compiler for that. First it was introduced for Visual Basic, then to C# and now it is available for C/C++.
I'm using Visual Studio 2008 Pro programming in c++. When I press the run button in debugging mode, are any compiler optimizations applied to the program by default?
The debugger will by default be running a debug build, which won't have optimizations turned on.
If optimizations are enabled, you may notice that "Step" and "Next" sometimes appear to cause the program flow to jump around. This is because the compiler sometimes re-order instructions and the debugger is doing it's best.
I suppose it depends on what you'd classify as optimizations, but mostly no. Just for example, recent versions of VS do apply the (anonymous) return value optimization, at least in some cases, even with optimization disabled (/O0) as is normal for a debug build.
If you want to debug optimized code, it's usually easiest to switch to a release build, and then tell it to generate debug info. In theory you can turn on optimization in a debug build, but you have to change more switches to do it.