-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problems with guessing error locations #20
Comments
I never much like the heuristic approach, since I could never remember when So... What if we added a new kind of srcloc called "caller-loc", which can What else besides arity mismatch still needs to report the caller's frame?
|
I don't understand what a I'm not really concerned with the stack trace showing an extra frame or not. I'm mostly concerned with thinking through the cases of what the caller could be (can it be nothing? can it be built-in code and what should we show in that case?) Other than arity mismatch, things like array operations and reference initialization also don't take explicit source locations themselves, but (usually) have their caller as the most relevant code to blame before going into internals of the runtime. |
Error messages contain a source location that says where they occurred. The If there are no useful frames on the stack, I think all we can show is
|
Errors don't always contain a location (or the ideal location). arity-mismatch only knows the location of the callee, and ref-init and invalid-array-index don't have a location at all, because the contexts that throw the error don't have a location available. The location in the error message is never ignored that I know of (at least I didn't write code intending to do that!). Some errors just don't come with that information pre-attached for a number of reasons --- usually it's because function calls aren't compiled passing the location in, so errors that happen inside the runtime via function calls don't have a location passed in the way, say, getField does. |
OK... So then having caller-loc would/should allow all errors to have a When do errors contain a "location that isn't ideal"? And what do we (Note: if it wasn't clear, I'm using "caller" to mean "the first ancestor
|
arity mismatch contains the location of the callee and not the caller. That's not ideal; ideal would be both.
This convention is the entirety of what I intended this issue to be about. This definition of "caller" has been hard to keep straight and led to bugs in rendering when stacks contain no frames that fit this definition, and when the right caller was actually the second ancestor frame, which was true for a while. That's currently causing some arity mismatch errors to get swallowed. If I understand right, caller-loc is a value that means "do the heuristic we're currently doing," and I think that will still be hard to maintain. I don't think there's a particularly easy fix for this -- the runtime/compilation strategy ends up playing into what locations we have available and are easy to report, unless we change the calling convention to include the caller's location. I think the most helpful thing would be to get the renderer for errors to be more easily testable, so we can know when it breaks because we made a compiler change. Right now the rendering is unfortunately stuck in a bunch of hard-to-test JS, and when something changes it's really hard to know if any renderings broke. |
Are there heuristics other than figuring out which location the caller is at? |
I'm trying to distinguish "when should the discard-some-frames heuristic We could enhance that value with a number specifying how many frames to For arity errors specifically, why don't we just include two locations-:
|
What I think would help most is to write a function, possibly in Pyret, that has the signature:
Where Even if we write it in JS, we should try to follow that signature so it's easier to test just what we're producing for rendering. Doing it in Pyret has the advantage that we could use it in console output as well. We could do this with compiler and type errors, too. Then error-ui.js would become the 50 or so lines required to call this correctly, highlight srclocs (or link srclocs to other frames/give builtin warnings), etc, and the whole thing will get tested with Pyret's testing.
|
I could get behind the design for a function like that, sure. Then my
|
@blerner is this still an issue? |
If this is still an issue it'll crop up as a fresh one. Closing. |
Arity mismatches and a few other errors use a heuristic of "the top user-defined stack frame" to guess the location to report. If the stack doesn't have any frames (for whatever reason), or if the stack consists only of built-in frames,
undefined
s can result and break other parts of the rendering. This needs a more principled solution for what to show.The text was updated successfully, but these errors were encountered: