frontend: Add built-in check function

[BadGraphixD]

Adds an optional check function to built-ins, which the type-checker calls. This check function can return a Diagnostic, which is thrown by the type-checker. This is currently only used to verify that the two float-types passed to VADL::fcvt do not have the same encoding, and that converting between float and int only involves 32- or 64-bit integers.

This check function will also be used after the transition to type parameters.

Also changes how float-types are stored in the AST. Previously, only the bit-size was stored in the AST. Now, the whole FloatEncoding is stored there.

Closes #1058

[flofriday]

The quality of typechecker builitin diagnostics is a real problem but I don't love the approach here.

For one check and takes are two very generic sounding functions and even if the docs explain how they need to be used in tandem, nobody reads every function doc in a codereview. Also I mentioned them now in the wrong order but their names don't indicate any order. Making their names more complex (and ugly) to reflect their semantics would already help something (like takesConstArgsAndArgsButNotCheckTheirValidityToEachOther and checkConstArgsAndArgsAndTheirValidityToEachOther)

The bigger issue I see is that I don't really get why should have two functions in the first place. Right now it's really hard to tell why we would have two steps, and (as the example show above) for me how to name them. I think we can merge both functions, and always return a diagnostic.

This is a problem we had for a longer time, thus in the Typechecker this longstanding TODO stands to remind us:

    if (!builtIn.takes(constArgs, argTypes)) {
      // FIXME: Further improve these error messages.
      var calledParamsAndTypes = String.join(", ", Stream.concat(
          constArgs.stream().map(Constant::toString),
          argTypes.stream().map(Type::toString)
      ).toList());
      var areSomeConst = originalArgTypes.stream().anyMatch(ConstantType.class::isInstance);
      addErrorAndStopChecking(
          error("Type Mismatch", location)
              .locationDescription(location, "The builtin has the signature `%s` but got `%s`.",
                  builtIn.signature(), calledParamsAndTypes)
              .applyIf(areSomeConst, b -> b.locationHelp(location,
                  "Try casting some of the constant arguments to explicit types."))
              .build());
    }

I'd suggest to merge take and check with the two only differing in the type they return. So for everyone who already uses take the API will still exist but under the hood there is just a single implementation that verifies the constArgs and Args, and a single call to either is enough to determin if the builtin call is semantically correct.f

All the newly added diagnostics for this can be supper generic and improved later but we should get the infrastructure right.

If this explodes in work, please DM me and we figure something out how to split this work across the two of us or defer it for later.

Sorry for the long reply. 😅

[BadGraphixD]

@flofriday So you want the API to contain a takes and a check method, which both check the same thing and use the same functionality underneath, but takes simply returns a boolean result, while check creates diagnostics right? So the type-checker would only use check, and the ViamVerificationPass could then only use takes right?

I am all for this idea, but I'd like to implement it in a separate PR after #1074 is merged, since doing it here would require me to rewrite the behaviour twice (here and in #1074).

[flofriday]

Yes exactly. 😅

Yeah fair, that would require some git shenanigains, to still be able to rebase the other branch on this one (no history rewrites).
So yeah I'm fine with doing that after #1047 is merged.

[flofriday]

Almost done, just minor stuff 🎬🎉

[flofriday]

LGTM 🐎🎉