Compile time "time bomb" macro?

1

This sounds silly, but I'm seriously considering this.

The Problem:

Often times, I write code by (1) copy/pasting existing code, (2) making some minor changes, and (3) mentally telling myself to refactor at a later point. The reason for (3) is to avoid 'breaking flow' -- i.e. I'd rather have messy-end-to-end working code rather than "clean but not working" code.

Most of the time, I forget about (3). I would like the compiler enforce this. I want to have a macro where I specify a (year, month, day) triplet. If the current time stamp (from OS) is earlier than the triplet, the macro compiles fine. If the current time stamp is after the triplet, it generates a compiler error.

The goal here is that I can write messy/ugly code, drop a macro "time bomb" for 2-3 days, later, ... and at that time, the compiler will tell me to refactor the code.

[Yes, I realize it is terrible to have production code whose compile status depends on the OS time stamp. If you know of a better idea, I'm happy to listen.]

2

I think this can be done as a proc-macro. But I don't know how that plays with incremental compilation.

1 Like
3

This could be handled with an alarm on your computer... If it needs to be in the code, it would probably be better to have a macro that just emits a compile warning which won't go away until you remove it. I can't think of any good reason to make a compile fail as a result of a procedural decision external to the code.

1 Like
4

I agree it should generate a warning but in general I think this is a great idea. A needs_refactor macro would be really nice.

1 Like
5

Interesting feedback.

  1. I did not take into account incremental compilation. Depending on OS time sounds like a bad idea now.

  2. I don't think warning is enough. If we have 40+ crates in a workspace, do a recompile, and ignore some crate that generated warning (but compiled successfully). I don't believe the crate will recompile unless one of it's dependencies is modified.

  3. Maybe the following can work:

  4. We define a crate needs_refactor which has two implementations of needs_refactor (with one of them commented out.)

  5. One macro maps needs_refactor(_) to ``

  6. Other impl maps needs_refactor(x) to let _: u64 = x;

During "just get it work" state, we uncomment impl on line 5. during "refactor" state, we uncomment impl on line 6.

Commenting/uncommenting needs_refactor crate should also cause all dependencies to recompile.

6

I have something like: (in progress)

/*
#[macro_export]
macro_rules! needs_refactor {
    ($( $args:expr ),+) => {{}};
}
*/

#[macro_export]
macro_rules! needs_refactor {
    ( $arg:expr ) => {{
        let _: u64 = $arg;
    }};
}

in mind.

7 
#[macro_export]
macro_rules! needs_refactor {
    ( $arg:expr ) => {{}};
}

/*
#[macro_export]
macro_rules! needs_refactor {
    ( $arg:expr ) => {{
        let _: u64 = $arg;
    }};
}

appears to work, but commenting / uncommenting is a bit clunky. Is there a easier way to "toggle" the macro?

8

Just toggle the line with let:

#[macro_export]
macro_rules! needs_refactor {
    ( $arg:expr ) => {{
        //let _: u64 = $arg;
    }};
}
1 Like
9

For a better error mesage use the compile_error macro

2 Likes
10

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.