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
Allow the presence of type casts for return values in Ltac2. #13914
Conversation
I also need to tweak the syntax described in the refman, but I don't remember what's the recommended process for that. Should I regenerate it using the dedicated script? cc @jfehrle |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Except for the editorial comment on the change list, this looks good to me! Thanks for looking into it!
doc/changelog/05-tactic-language/13914-ltac2-cast-fun-return.rst
Outdated
Show resolved
Hide resolved
All you need to do is:
|
be20f0e
to
aba594c
Compare
Should be ready. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The doc update looks good. But was the parsing code reorganized recently? I'm surprised to see massive changes in the fullGrammar
file.
This is the bane of autogenerated files not kept in track with the CI. We're bound to lag behind. |
Yep. I think we'll add this file to CI soon. |
Generally this file has been quite stable. Its order depends on the order in which the mlgs are specified on I think the underlying cause is that This seems to be reversing a change that was just committed in #13707. This is probably a one-time hiccup, but worth looking into if it happens frequently. |
Indeed. Unfortunately, the order in |
@MSoegtropIMC This is ready to merge from what I can tell. |
|
The order I get from |
It looks like If I hide that file, I can't do a
Sanity checking makes sense. |
Looking into it a bit more, I see that
|
It looks like the issue is on your side only, doesn't it? Then, there's no harm in committing this PR as is, since it only reverts an unwanted change. |
Perhaps so. We should sanity-check updates to |
@MSoegtropIMC I believe this PR is ready to merge. Sorry for the false alarm above but the conclusion was that nothing needed to change in this PR. |
Thanks for the reminder - I will likely do it today. |
@MSoegtropIMC ping |
Following popular demand from @MSoegtropIMC.
Kind: feature.