Don't use erlang:get_stacktrace/0 in OTP >= 21

[mikpe]

As of OTP-23 erlang:get_stacktrace/0 doesn't work in any meaningful way, so we need to replace its uses in source and tests with the OTP-21 syntax for binding the stack trace in exception handling clauses.

The question is whether we can do this unconditionally, thus raising the oldest supported OTP to OTP-21, or if you want some conditional compilation macrology to handle OTP < 21 as well as OTP >= 21? (We have standard macros for this scenario, but avoiding them is nicer.)

[kostis]

Hi @mikpe !

As you can see in other issues (e.g., #312), Concuerror does not yet support 23.0. It's up to @aronisstav when / if that support will come. After the change in Core Erlang (taking out receive and substituting it with 4 primops whose semantics are nowhere specified), out of principle, I refuse to be personally involved in adapting any tool which is based on Core Erlang beyond support for 22.3.

However, before finding out what happened with Core Erlang, I have opened a PR (#311) for investigating how support for 23.0 can be added. There, we had decided to take out all support for versions prior to 19.0. Again, it's up to @aronisstav to decide whether he wants to upgrade that to dropping support for versions prior to 21.0 or not.

But, at least judging from e.g. the macro that PropEr uses, using that macro in exception handling clauses is not very invasive to the code base.

A bigger problem, at least as I see it, is that Concuerror uses explicit calls to erlang:get_stacktrace in other situations, and it's not clear how these need to be rewritten. But perhaps @aronisstav may have some idea.

Finally, a smaller issue is that certain code bases (e.g. gproc, poolboy) that are currently used as tests in Concuerror and are also using get_stacktrace will also need to be adapted (or taken out).

[aronisstav]

Hi @mikpe! Thank you for opening this issue!

While I did try to make Concuerror "preserve" stacktraces for "user" code despite instrumentation, I did not test this feature thoroughly, so I would greatly appreciate contributions there.

Regarding version support, I don't mind much raising the minimum version to 21.0, and referring users to older versions for older OTP support, as I don't mind patching "external code" in tests. In the interest of discussion I will open a separate issue about dropping support for versions prior to 21.0, in case anyone has something to say.