doAssertRaises: stmt catch all, including foreign exceptions

[timotheecour]

this PR adds an overload for doAssertRaises that catches all exceptions (including foreign ones which wasn't possible before this PR with doAssertRaises, which is useful for cpp and js backends):

doAssertRaises: fn()

• followup after doAssertRaises improvements; nimscript supports except Exception as e #15765
• add tests for c,cpp,js,vm (tests/stdlib/tassertions.nim)

#15765 (comment)

This overload overloads untyped on an inconsistent position so it's unlikely to work well.

overloading works in this case, each overload has a distinct number of non-optional parameters; tests check for this.

[Araq]

overloading works in this case, each overload has a distinct number of non-optional parameters; tests check for this.

But it violates the spec... Also, why do we need it? If you write a test case with doAssertRaises why not specify which exception should be raised?

[timotheecour]

If you write a test case with doAssertRaises why not specify which exception should be raised?

because this won't work with foreign exceptions as I explained in #15765 (comment) (see P2)

But it violates the spec...

I'm not sure which section of spec explicitly forbids this case but I think you'll agree the spec should allow overriding in this case:

• there's 0 ambiguity
• sigmatch already handles this correctly
• it's useful, and I've been using this kind of overloading many times (likely others too); it's in fact a common pattern where you have a last block argument preceded by several params; the fact that optionals currently don't work with a last block argument (optional params don't work with block argument(s) in last position #14346) means ppl rely in overloading instead (eg see Let arguments be left as optional when using "do" notation. #884 (comment))

EDIT: I just remembered #14827 ; let me think whether there's 0 ambiguity still holds in this case (or whether this statement stays true with more precise wording)

EDIT: https://nim-lang.github.io/Nim/manual.html#overloading-resolution-lazy-type-resolution-for-untyped says: "But one has to watch out because other overloads might trigger the argument's resolution:"
in the case of this PR, it's fine since each argument is essentially a disguised typed param; maybe that could be the distinction that makes this overloading sane: when untyped params are disguised typed params (undergo semantic analysis), then overloading can happen even if position of untyped params don't match

[Clyybber]

because this won't work with foreign exceptions as I explained in #15765 (comment) (see P2)

But those work with doAssertRaises(void): ... no?

[timotheecour]

But those work with doAssertRaises(void): ... no?

no:

when defined case2:
  {.emit:"""
  #include <stdexcept>
  void fn(){throw std::runtime_error("asdf");}""".}
  proc fn(){.importcpp.}
  doAssertRaises(void): fn()

gives: Error: only a 'ref object' can be raised

(note that in 1st commit of #15765 (see ab6dc1f) I was supporting void to fit this bill, but @Araq decided against it)

[timotheecour]

ping @Araq I'd like to use this in #16727:

    var ok = false
    try: discard big"2" ** big"-1" # raises foreign `RangeError`
    except: ok = true
    doAssert ok

=>

    doAssertRaises: discard big"2" ** big"-1"

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. If you think it is still a valid PR, please rebase it on the latest devel; otherwise it will be closed. Thank you for your contributions.