-
Notifications
You must be signed in to change notification settings - Fork 213
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
assert
field in record triggers an Invalid Input
error
#2402
Comments
I think the parser simply became a bit stricter about checking for disallowed keywords in record labels. To use a keyword as a record label, enclose it in backticks: { `assert` = 1 } |
Oh I get it now. So the original file where the field is declared indeed uses backticks (it's a purescript package set, which i've not authored), but our CI uses an old dhall version to combine files, and this one does not keep backticks around assert. So updating dhall in the CI job should fix my issue. No code fix needed, yay! However, this looks like a breaking change that was not properly advertised in the changelog. Is it too late to add it? (I'm not sure of the exact version where the change was introduced) |
Do bugfixes count as breaking changes? I'm not sure.
Feel free to send a PR. |
I'm fine amending the CHANGELOG to mention this change as a breaking change, but for future reference, I don't treat bug fixes as breaking changes from a versioning standpoint. |
Sure, it's purely for documentation purposes: when I hit this failure and narrowed it down to a couple releases, i went to the changelog to see if something was mentioned and found nothing, hence my surprise; the introduction of If "breaking change" is too strong for bug fixes, no worries, but mentioning that programs could break would have helped me. Anyway i'm fine, but it might help people in the same situation |
Also discussed in #1896. |
Starting between
dhall-1.32.0
anddhall-1.34.0
, having a record field namedassert
causes the following issue:For reference, the expected behaviour is
I've checked on the changelog, asserts were introduced before 1.32, so
assert
being a reserved keyword might not be the issue directly. I'm not familiar with grammar changes that occurred between 1.32 and 1.34The text was updated successfully, but these errors were encountered: