Open cfallin opened 2 years ago
cc @cfallin, @fitzgen
.github/subscribe-to-label.json
configuration file.
[Learn more.](https://github.com/bytecodealliance/subscribe-to-label-action)
FWIW, we use $true
and $false
elsewhere, eg:
Not convinced that #t
and #f
is really that much of an improvement.
Yep, we'd want to clean up said uses all at the same time.
I'm not as concerned about syntax; we could even just accept tokens true
and false
; my concern is more that $true
and $false
are abusing a feature meant for other things (externally-defined constants) and if we have bool values, we should represent them as such in the IR. Getting the type right there would also allow us to use them in the future in other DSL-compiler optimizations.
ISLE's prototype compiler was built with the simplifying assumption that all constants are integers. "Symbolic constants" (imported opaque values) like
$MYVALUE
were added later. It's possible to definebool
as a primitive type, but the syntax for bool constants,#t
and#f
, results in generated code that uses integer values1
and0
because... everything is (was) an integer. This is clearly suboptimal! In #3572 @alexcrichton used the clever workaround of$false
, leveraging the support for arbitrary passthrough of constant names to actually get afalse
in the code.We should (i) add a
ConstBool
alongsideConstInt
in the IR (PatternInst
andExprInst
), and (ii) codegen these properly as Rust bool types. We might also consider at some point making our "primitive" type hierarchy a bit richer and distinguishing ints and bools, but that's lower-priority.