fix #1994 gorge, staticExec now error at CT on exitCode !=0

[timotheecour]

• fix Can't tell return value of programs with staticExec #1994
• uses a different approach than fix #1994 gorge, staticExec now raise Assert on exitCode !=0; simplified implementation #10345 because I couldn't figure out how to address technical difficulty mentioned here fix #1994 gorge, staticExec now raise Assert on exitCode !=0; simplified implementation #10345 (comment)
• Use --experimental:gorgeIgnoreExitCodeDeprecated to get old behavior, or use gorgeEx to get tuple[output: string, exitCode: int]

an altenative would be:--experimental:gorgeHonorsExitCode and if this flag isn't passed, show a deprecation notice when gorge is used

note

• in this PR the VM errors (with stacktrace) when gorge fails, it doesn't raise doAssert and error can't be caught:

block:
  static:
    doAssertRaises(AssertionError): const a = gorge("nonexistant") # doesn't work

unlike in previous PR which allowed that: https://github.com/nim-lang/Nim/pull/10345/files#diff-353c91db729fe1f641027ea2a4e781b2
if someone has an idea (that they tested to work) for allowing that (or even allowing raising OSError), please let me know; otherwise the workaround mentioned above should cover all usability cases

[GULPF]

Use --experimental:gorgeIgnoreExitCodeDeprecated to get old behavior, or use gorgeEx to get tuple[output: string, exitCode: int]

Using --experimental to enable deprecated behavior looks really weird, it's the opposite of experimental

[timotheecour]

Using --experimental to enable deprecated behavior looks really weird, it's the opposite of experimental

i know, my 1st draft had: --transition:gorgeIgnoreExitCode but that required duplicating a bit of machinery (Feature, advopt.txt post-processing, etc) so i went for simplicity instead; I could do that if that PR is gonna be accepted. Note that --transition:gorgeIgnoreExitCode is better than yet another top-level flag --gorgeIgnoreExitCode (got this idea from dmd:

dmd -transition='?'
Language changes listed by -transition=id:
  =all              list information on all language changes
  =field,3449       list all non-mutable fields which occupy an object instance
  =import,10378     revert to single phase name lookup
  =dtorfields,14246 destruct fields of partially constructed objects
  =checkimports     give deprecation messages about 10378 anomalies
  =complex,14488    give deprecation messages about all usages of complex or imaginary types
  =intpromote,16997 fix integral promotions for unary + - ~ operators
  =tls              list all variables going into thread local storage
```)

[Araq]

Why not simply deprecate gorge and tell people to use gorgeEx instead?

[timotheecour]

Why not simply deprecate gorge and tell people to use gorgeEx instead?

i'd love that, but thought i'd face pushback from some ppl;

@Araq is there any loss of usability wrt using it inside a pragma ? (ie a user defined proc foo that calls gorgeEx work inside a pragma); sorry i guess i could just try

## `gorge <#gorge>`_ is an alias for ``staticExec``. Note that you can use
  ## this proc inside a pragma like `passC <nimc.html#passc-pragma>`_ or `passL
  ## <nimc.html#passl-pragma>`_.

if gorgeEx(or user defined variant) works inside a pragma and there's no loss of functionality, i'll go ahead and update PR to just mark gorge,staticExec as deprecated (w no change of behavior in them)

[dom96]

error can't be caught:

This is a big problem, I should be able to catch this error and set my const to a different value if the staticExec fails.

Why not simply deprecate gorge and tell people to use gorgeEx instead?

I vote for removing these aliases. They just don't serve much of a purpose and many often wonder why they're there. Just deprecate them and break staticExec to raise exceptions, the exception will happen at compile time so the worst case is that your program won't compile.

[Araq]

I vote for removing these aliases. They just don't serve much of a purpose and many often wonder why they're there. Just deprecate them and break staticExec to raise exceptions, the exception will happen at compile time so the worst case is that your program won't compile.

Ok, fine with me, so we deprecate all 4 of them. And then, tada (!) we can introduce variants that work that are not in system.nim.

[dom96]

Ok, fine with me, so we deprecate all 4 of them. And then, tada (!) we can introduce variants that work that are not in system.nim.

That's going too far, I'm happy with staticExec :P

[krux02]

well I am voting for Araq solution here. staticExec is certainly useful, but not so much that it's dominant position in system.nim is justified.

I think we should introduce a proper deprecation path for changes like these. The current deprecation mechanism is great when the name of a function changes. Old code works as it was without breakage and error messages point out what to use to update the code. But moving procs into different modules is not that simple. If the same deprecation mechanism is applied here, the new name will very likely collide with the deprecate procedure.

Something that says: `foobar` is now in module `xyz` that doesn't create a collision would be nice. That would certainly be very usable, not just for core Nim development.