nickchapman-da 68b323635d [engine] prefer lastLocation to stackTrace (#15111) ... TLDR: Remove broken code which constructs stackTrace(). Happy never to have to read those NOTE(MH) comments in the pushLocation code again! (1) This code was fundamentally broken for various reasons: - It doesn't make sense to track location info on the continuation stack. The continuation stack is a record of the evaluation still to come; not a context for the current evaluation. - Stack traces can't sensibly be provided in a language such as Daml which promises that tail-recursion is evaluated in constant stack-space. - Attempting to keep location info on the continuation stack does not play well when exceptions are thrown and the stack is unwound. (2) The stack-trace management code was also very hacky: - The pushLocation code contained special cases when the continuation stack was headed by a KArg/SToken continuation. This is an internal implementation detail. The KArg doesn't even exist when we stop using the deprecated SEAppGeneral expression constructor. - The pushLocation code also contained special support for copying stack-traces into SEVal and SDefinition caches, and then later back on to the continuation stack. Yuck! (3) The stackTrace() code was barely used: - Some time ago an alternative/simpler location tracking system (lastLocation) was implemented. - Only ScenarioRunner makes use of the stackTrace() - Only a single test changes behaviour when we drop use of stackTrace() in favour of getLastLocation		2022-09-28 13:15:08 +01:00
..
src	[engine] prefer lastLocation to stackTrace (#15111)	2022-09-28 13:15:08 +01:00
BUILD.bazel	LF: Add LoggingContext to Speedy Machine (#12976)	2022-02-21 13:34:46 +01:00