v: add a new v.comptime stage COMPTIME, that runs after the checker (CHECK), and before the transformer (TRANSFORM), to simplify the work that later stages do #26068

[Eliyaan]

I'm still very new to the compiler so I'm not very confident in these changes. (feel free to push changes)
See #26068 for the issue talking about this change

The idea behind this is to move all the comptime logic in a new stage so no later stages need to manage this.
I tried to keep his PR minimal, by introducing the new stage and moving only 1 small comptime resolution from cgen to the new comptime stage.

The most of the code in the new comptime stage is a simplified version of the transformer. (without this code the PR is small)

@spytheman @kbkpbot and other contributors what do you think?

[kbkpbot]

I notice that you are currently moving the comptime stage to after the checker, which facilitates code generation by backends like cgen. I'm wondering if we could take a more radical approach and move comptime before the checker? This might also simplify the design of the checker. Of course, this could pose some challenges, such as many types being empty since the checker hasn't done its work yet.

This is definitely a deliberate attempt.

Is this possible?

+--------+
| parser |
+--------+
    |
    |-----------------------+
    |                       |
    v                       v
+---------+        +----------------+
|  vfmt   |        | type_resolver  |
+---------+        +----------------+
                           |
                           v
                 +------------------+
                 | comptime&generic |
                 +------------------+
                           |
                           v
                      +---------+
                      |markused |
                      +---------+
                           |
                           v
                       +-------+
                       |autostr|
                       +-------+
                           |
                           v
                       +--------+
                       |checker |
                       +--------+
                           |
                           v
                        +------+
                        | cgen |
                        +------+

[JalonSolov]

It's tough to separate these stages, but the compiler will be better for it in the end.

For example: It would almost be better to check at least some of the comptime stuff before the type resolver, as there is no reason to resolve something that won't be included...

If the parser took care of comptime $if, such as $if windows, then it would know whether or not to even bother parsing that section depending on the target OS.

However, that starts getting very complex very quickly. Later stages simply need to know what to keep and what to throw out.

comptime section before checker does make sense, as the checker wouldn't be able to check stuff that's already been removed... same argument as for the parser - if it didn't bother to parse things in the $else blocks, they wouldn't be in the AST for the rest of the code to deal with.

It all comes down to which tradeoffs to make in memory vs performance.

[Eliyaan]

@kbkpbot
I agree that your stage order seems better for performance.
But one thing is bothering me, the code that is not used (either eliminated through comptime or markused) is not getting checked by the checker. So errors could go undetected.

[Eliyaan]

the CI failures seem unrelated as it does fail in this commit too https://github.com/vlang/v/actions/runs/20527758186/job/58974092824

[spytheman]

markused should stay as close to the end (before the backends) as possible imho, because otherwise it would have to predict the work that the next stages do, which is tough and error prone (just like most of the complexity in it, currently is there, because it tries to predict what cgen would do and generate calls for, instead of just walk an AST that is completely processed)

[spytheman]

the code that is not used (either eliminated through comptime or markused) is not getting checked by the checker. So errors could go undetected

There is -os cross, which makes all comptime branches to be checked afaik, beside other things, so you should be able to v -os cross -check . and be reasonably sure that you get all errors (except perhaps from constructs like $when_first_existing(), $pkgconfig(), $d() and $env(), which depend on the local filesystem/env variables).

[spytheman]

the CI failures seem unrelated as it does fail in this commit too https://github.com/vlang/v/actions/runs/20527758186/job/58974092824

yes, that is fixed on master, but please do not rebase, since the CI is a bit clogged now.

[spytheman]

LGTM, thank you @Eliyaan .