`{=0=}` should not be a valid time literal

[cmnrd]

While working on the handling of time values within our compiler, I found many inconsistencies, redundant code and weird constructs. The code regarding handling of time values (ASTUtils) and their validation (LFValidator) should be revised. One particular change that is needed is the handling of {=0=}. Currently, we interpret this as the time 0. However, we should refrain from evaluating values escaped with {=...=}.

[lhstrh]

Why? The brackets are there predominantly for situations where we can't parse what's inside, but if it turns out we can, why shouldn't we? I never interpreted the funny brackets to denote "don't look inside of this" but rather "what you find in here is target-specific."

[cmnrd]

Exactly, the brackets denote target code. Interpreting the 0 only works if time is represented as an integer in the target language. This is not the case in C++ and 0 is not a valid time literal in C++ code. So {=0=} should also not be a valid time in LF. We say that we treat everything inside {=...=} as a black box and I think we should stick to this rule. Otherwise, we will get all sorts of weird behavior. For instance, why can I write timer t({=0=}) but not timer t({=foo()=})? Why can I write timer t({=0=}) which is illegal in C++, but cannot write timer t({=0s=} which would be proper C++ code?

[oowekyala]

Related to #657

[cmnrd]

Right, I remembered this issue but did not find it anymore. Thanks!

[oowekyala]

I am closing this as a duplicate because #657 has more references than this one (eg in todos in the code, and in Github issues)