refs #17292 fix repr: (discard) now does't render as discard which gave illegal code

[timotheecour]

refs #17292

let f = () => (discard)

now renders as:

let f = () => (discard)

instead of this:

let f = () => discard

which is illegal (it was making runnableExamples invalid prior to #17282, but the underlying bug remained and affected things like parseExpr, parseStmt, or operations based on renderModule)

[Araq]

Hardly acceptable. Special case, what about an empty return? Why is a statement list with a discard special for the renderer? Makes no sense to me.

[timotheecour]

(return) is not legal but (discard) is legal and useful; for eg, it's the simplest way to write a sugar lambda returning void: let f = (x: int) => (discard)

these work as you'd expect after this PR:

macro deb(a) =
  echo a.repr

deb:
  block:
    discard
  discard

  block:
    when true: discard

  # let a = b => discard # illegal
  let a = b => (discard) # legal but, before this PR, repr rendered it incorrectly

  block:
    return

unless you can find an example that gets worse after this PR, I think this is a useful bugfix.

[Araq]

Why does

  block:
    discard

not produce the () after this patch? Subtle logic here...

[timotheecour]

PTAL

Why does ...
not produce the () after this patch? Subtle logic here...

because:

• block: discard is handled by gstmts directly
• a=>(discard) is handled by gsub

the PR does the correct thing in both cases. I've added more tests.

[timotheecour]

@Araq ping on this

[Araq]

Still reviewing it -- it's adhoc and as I said, who knows if return doesn't need the same. And then what about break and raise?

[timotheecour]

Still reviewing it -- it's adhoc and as I said, who knows if return doesn't need the same. And then what about break and raise?

I can't find any case involving return, break, raise where repr gives incorrect results, and I can't find a case that would break as a result of this PR. This PR fixes a known bug, if we later find another bug, it can always be fixed then.