Allow expressions with type constructors #1313
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rsmmr
force-pushed
the
topic/robin/gh-1123-ctor-expressions
branch
2 times, most recently
from
ab4f12b
to
81d72a8
Compare
rsmmr
changed the title
bbannier
previously approved these changes
Dec 9, 2022
|
I'm going to iterate a bit more on this. Turns out we do need to do constant folding at more places to really cover the cases we need. |
rsmmr
force-pushed
the
topic/robin/gh-1123-ctor-expressions
branch
from
85cc2fc
to
b408c1c
Compare
…rval_ns(...)`. So far we used constructor expressions like `interval(...)` to create *constants* of the given type, and for that we required that the argument was a single atomic value. The result was that these constructor expressions were really more like literals for the corresponding types than "normal" expressions. While that's useful internally, it's confusing for the user. This commits is beginning to change that, using `interval`/`interval_NS` as the first instances that now supports arbitrary expressions as its argument. In follow-up commits, we'll port other constructor expressions over to that new syntax. (This also unifies HILTI & Spicy to each provide both of those interval constructors.) To make this change without loosing a way to create actual constants (which we need at some places), we implement this in two stages: the parser initially turns such `interval(...)` expressions into call operators[1] that the types now define for each desired constructor. We then extend the normalizer to look at all the relevant call operators: if they are just receiving a constant value as their argument, then it substitutes them with a plain ``Ctor`` node (``ctor::Interval`` in our cases here). That check for "if they just receive a constant value" isn't quite trivial in general. In our case, where we just want to go back to what we had, it's not that difficult, but more generally it would be nice if we had a constant folder that could compute results even for more complex, but constant, expressions. As that's a piece that our AST infrastructure is still missing, this commit starts going that route by adding a new "constant folder" visitor. Right now, it's covers only the simple cases we need here, but it's something we can extend going forward. Addresses #1123. [1] These call operators are a bit special because they actually don't have anything to call: in `interval(42)` the `interval` isn't any kind of actual value; we just need it for overload resolution. To make that work, we use a `expression::Member` as the first operand, which models a predefined ID. Normally `Member` is just for field lookups in, e.g., structs, but it works just as well elsewhere.
This moves `time/time_ns/stream/error/intN/uintN` over to the new call operator model that we introduced for `interval`. One HILTI-side syntax change: HILTI now also uses `intN(x)` and `uintN(x)` instead of `int<N>`/`uint<N>`. This is to avoid having to introduce two separate set of operators. This change slightly changes timing for when exactly some errors are caught, which required tweaking a couple of tests a bit.
The normalizer now attempts to fold any expression through the constant folder.
Plus, a bit of cleanup.
Note: The original plan was to have this fully replace the optimizer's boolean folding. However, it turns out that that doesn't quite work because it would mess up the optimizer's tracking of feature usage. For now, we special-case the feature constants in the folder and don't touch them.
I believe this path never triggered so far, but it does now with the new constant folding.
The intent has always been to normalize ID scopes so that they aren't prefixed with the current module. However, that wasn't always working because we lost the state of the current scope. Now moving that into a global to retain it across different printing streams.
rsmmr
force-pushed
the
topic/robin/gh-1123-ctor-expressions
branch
from
17a5676
to
a44ecdc
Compare
rsmmr
force-pushed
the
topic/robin/gh-1123-ctor-expressions
branch
from
f71f2e2
to
78ae64b
Compare
|
@bbannier This is now ready for review again. The changes are in commits on top of the previous version, hope that works. |
bbannier
approved these changes
Jan 19, 2023
|
I'm going to hold off merging this for a little bit more to not block CI, assuming, @bbannier, you're cutting a release. |
bbannier
reviewed
Jan 30, 2023
| @@ -3,7 +3,7 @@ | |||
| url = https://github.com/onqtam/doctest.git | |||
| [submodule "3rdparty/SafeInt"] | |||
| path = 3rdparty/SafeInt | |||
| url = https://github.com/dcleblanc/SafeInt | |||
| url = https://github.com/rsmmr/SafeInt.git | |||
There was a problem hiding this comment.
@rsmmr, do you plan to upstream your patch? Also, using a private fork is not ideal as it makes pulling in upstream fixes impossible for anyone but you.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.