A macro to print into log of the compiler during compile time?

[Wandalen]

Does it exist ( hopefully )?
If not maybe some kind of extension or feature?

[Ideator]

What do you mean by the "log of the compiler" exactly? Compiler's job isn't to log things out, if you need a log, either implement your own by interfacing with stdout/stderr or use an existing crate such as env_logger to keep things as simple as possible. Unless you want some information pertaining to the compilation process itself, then you'll need to use --verbose) and/or -g flags with rustc. There are no macros for printing any info that doesn't directly relate to the program itself, as far as I know.

[Wandalen]

@Ideator thanks for the reply.

I meant printing notes during compilation in similar way trace_macro! do, but with custom content:

note: trace_macro
  --> rust/test/fundamental_test.rs:75:17
   |
75 |     let src : ( TheModule::for_each2!( dup as ! ( i32, u32, f32 ) ) ) = ( 1, 1, 2, 2, 3., 3. );
   |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: expanding `for_each2! { dup as! (i32, u32, f32) }`
   = note: to `$crate :: for_each2! (dup as! (i32)) ; $crate :: for_each2!
           (dup as! (u32, f32)) ;`
   = note: expanding `for_each2! { dup as! (i32) }`
   = note: to `dup! (i32) ;`
   = note: expanding `dup! { i32 }`
   = note: to `i32, i32,`

[Ideator]

@Wandalen

custom content

How custom? - you can define your own macro_rules!-like functions to print what you want, if the trace_macro crate doesn't provide enough tools for the job

[Wandalen]

I guess I formulate my question not clear enough because I have feeling it's not understood.

Example of what I am looking for:

compiler_println!( "custom" ); /* that goes to output( log ) of compiler at compile-time, not to output of application */

[Ideator]

I'm not a compiler expert by any means, and perhaps this question would be a bit more pertinent to the internals forum - but as far as I'm aware, there no features baked in the rustc to make it interpret the lines it reads to print what you want it to print. It simply processes your files as giant sequences of UTF-8 characters, transforming them into tokens, which get parsed into an abstract syntax tree or whatever it's called, which is then gets compiled down to the machine code through the LLVM toolchain.

Any macros you pass into it simply expand into proper functions (or sequences of statements, depending on their complexity), which get compiled along with everything else into your final binary. I'm not sure having an opportunity to stop the compilation at any point in time to print arbitrary info is a good idea either.

Anyhow, you might want to reach to folks in the Internals forum - but you're most likely trying to find a solution to the wrong kind of problem. Inspecting the compilation process directly is seldom necessary.

[Wandalen]

Must be it's possible with custom procedural macro for such need. Maybe such already exists on crates?

[Wandalen]

That's useful for diagnostics and improving readability of compile-time errors. Thanks anyway.

[stonerfish]

After years of gnu systems; make, gcc etc, I also find it strange when running

cargo b --release

I just see the minimal output, the names of the crates as they are being compiiled. Only on error, then good error message. It is OK, it just seems strange. With 'make', building a system, I can watch and log all the details as it compiles. All of those lines of output to watch from the very first './configure' to the 'make install'
So for years I felt I was supposed to pay attention as things compiled and I enjoyed the show. Loved to see the text flow up my terminal. Loved to peruse the log files and see what compiled when.

cargo makes it cleaner, but I feel like I am missing something. When it compiles, I dont "see" what is happening.

[kornel]

There's cargo build --verbose.

But printing from the compiler isn't that simple. This is not a single-pass batch process like in C. For example, Cargo invokes the compiler at least twice per crate, once for metadata extraction, then for rlib code generation. The compiler has incremental cache, so it doesn't recompile whole crates even when you tell it to. Even for regular compiler warnings Cargo has a special cache to hide this fact and "replay" and deduplicate old warnings, because otherwise you wouldn't see all the warnings every time (clippy used to suffer from this).

• There's compile_error!. Unfortunately, there isn't a warning equivalent.

• proc_macros may be able to emit warnings

• You could try triggering existing code warnings, e.g. #[deprecated(note=…)] may be useful.

• build.rs has an option of printing cargo:warning=, but I think it's only visible if the compilation fails.

[Wandalen]

Wonderful ! Thank you for the very informative answer, @kornel

[bjorn3]

@kornel

Cargo invokes the compiler at least twice per crate, once for metadata extraction, then for rlib code generation.

It only runs rustc once. Rustc tells cargo when the metadata generation is done to allow cargo to start dependent rustc processes, but the original rustc keeps running for creating the rlib.