#9176 Fix inconsistent behavior of compile time macros when assigned to a constant

[ianmcxa]

Very simple change marking gorge, gorgeEx and staticExec as .compileTime. to fix inconsistent behavior when setting the result of gorgeEx to a constant.

[timotheecour]

great!

• do you know if there more cases like this?
  ie, what @LemonBoy described here:

Ehh, it's a stupid bug in the implementation of some compile-time only procs.

• a test would be needed I think, eg maybe something like:

when defined(posix):
  const cmd = "echo foo" # or if you have another idea that makes it clear it's being run at CT, not at RT; but at least it'll catch the empty output bug of https://github.com/nim-lang/Nim/issues/9176
  var ret1 = staticExec(cmd)
  const tmp = staticExec(cmd)
  var ret2 = tmp
  doAssert ret1 == ret2

[ianmcxa]

Should I make a test for each of the commands?

[timotheecour]

meh, at least 1 is a good start

[krux02]

Interesting diff, I like it. Please add a test case that fails on the old behavior and works correctly on the new behavior.

[ianmcxa]

I've gone ahead and added a fix for getProjectPath and a test case to verify the fix in tests/system/compiletime.nim. I didn't see anything else that appeared to have this problem in vmopts.nim, but I am very new to the project so I may have missed something.

[timotheecour]

I've gone ahead and added a fix for getProjectPath

maybe update PR title

[mratsim]

Related: #8051

I've noticed that {.compileTime.} pragma doesn't work in many cases while static T return value works.

[dom96]

This is great! But it has the disadvantage that it allows these compile-time-only procedures to be assigned in a runtime context, previously you would get a "Error: 'staticExec' can only be used in compile-time context" whereas with this PR you won't.

Unfortunately I think we need a different solution.

[Clyybber]

@dom96 I think this is an acceptable tradeoff, because we have "static" in the name of the proc (ignoring gorge, since that alias is wierd anyways imo).

[ianmcxa]

Why do we have gorge and gorgeEx anyway?

[skellock]

gorgeEx gives you the exit code in addition to the stdout/stderr.

slurp and gorge are odd names for sure. I do prefer the much more boring static* nomenclature.

[ianmcxa]

My question was just why do we have that naming convention in the first place? Why not a single proc that does what gorgeEx does now, but with a more descriptive name?

[skellock]

Not sure of the heritage, but I like where you're going. #1994 is distantly related if we're talking about tidying up the API before 1.0.

[Araq]

Why do we have gorge and gorgeEx anyway?

Because some young fool (@Araq) had fun designing the language and added a single bad joke.

[Araq]

Removing this magic here cannot be right.

[Araq]

Removing this magic here cannot be right.

[Araq]

This needs to be solved differently.