Closed PieterOlivier closed 2 weeks ago
Attention: Patch coverage is 0%
with 2 lines
in your changes missing coverage. Please review.
Project coverage is 49%. Comparing base (
fc72dc7
) to head (5cc0b90
). Report is 81 commits behind head on main.
Files with missing lines | Patch % | Lines |
---|---|---|
...g/rascalmpl/values/RascalFunctionValueFactory.java | 0% | 1 Missing and 1 partial :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
@jurgenvinju do you remember if this was intentional? it seems to me like a small bug, but there might have been an explicit reason for it to ignore that origin parameter?
The reason for this extra parameter was the overloads on the generated parse function. One has a str as first parameter and the second has LOC as first parameter. The second loc parameter is only important for the str case.
We couldn't catch this with a keyword parameter because those couldn't be expressed in function types. And so we ended up with this mixed solution.
The bug is well identified still. I guess we never triggered it because only the above two use cases are in vogue. Still could be useful to have this. Tricky since it breaks the contract between the actual file and the src origins in the tree!
Thinking about this I'd rather assert that both locations are the same than override one with the other. Throw an illegal argument exception otherwise. Consider the havoc different locs would do to the semantics of the LSP servers, for example.
The str case is meant for experimenting on the repl and testing and debugging purposes.
I have changed to approach so now een IllegalArgumentException
is thrown when there is a mismatch between origin and input.
Thanks
The
parse
function has an extra parameter in case the origin was not the same as the input location. But the origin was never properly passed on.