core: new inference system for constraints

[alexarice]

I've gone through a few different refactors this week and have eventually settled on this slightly smaller refactor for the constraint system. The key addition is that each constraint now returns a dictionary of "resolvers" (name can maybe be improved) which resolve a variable from the given attribute. This allows inference to be decoupled entirely from verification, and inference should no longer be quite as fragile/maybe slightly quicker.

In this version, the resolvers are not used for verification, as I had originally planned, and instead the previous verification framework is left as is. I believe this change can enable the following changes in the future:

• Allow constraints on properties to resolve variables in a clean way (see core: with-type-constraint #3318)
• Allow the introduction of "length/int constraints" for managing the length of variadics (see misc: raise error if variadic results types aren't referenced in assembly format #3416)
• Potentially facilitate extensions to assembly format (i.e. directly supplying a variable)
• Resolvers could be used to automate construction of initialiser methods for operation.

PS. as of time of writing it appears this saves 4 lines of code

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.21%. Comparing base (863db56) to head (90d9d10).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3456      +/-   ##
==========================================
+ Coverage   90.20%   90.21%   +0.01%     
==========================================
  Files         459      460       +1     
  Lines       57634    57662      +28     
  Branches     5564     5557       -7     
==========================================
+ Hits        51987    52021      +34     
+ Misses       4201     4198       -3     
+ Partials     1446     1443       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[superlopuh]

Suggested change

	def print_resolve_type(r: ResolveType | None) -> str:
	if isinstance(r, Attribute):
	return str(r)
	elif isinstance(r, Sequence):
	return str(tuple(str(x) for x in r))
	return "None"
	def _format_resolve_type(r: ResolveType | None) -> str:
	if isinstance(r, Attribute):
	return str(r)
	elif isinstance(r, Sequence):
	return str(tuple(str(x) for x in r))
	return "None"

[superlopuh]

Also a doc string would be good

[alexarice]

Seems like this is dead code so I've removed it

[superlopuh]

This seems like it conveys the message a bit more directly

Suggested change

	match="i32 should be of base attribute test.param_one",
	match="unexpected attribute i32, expected test.param_one",

[superlopuh]

hmm actually is this just an existing constraint string? In that case I won't recommend PR creep, it might just be worth changing in the future.

[alexarice]

The key change here is that the exception happens during verification, rather than at parse time

[superlopuh]

Overall looks good, although I'm still not sure what the motivation for this is. Is it better error messages? Or is there more downstream? Also, my first instinct would be to somehow be a bit more lazy about the resolver situation, would it make sense to make them into lazy model objects, that let the user iterate over the keys, and define each function only once, instead of creating wrappers of wrappers. Not 100% sure if it would work, but might be worth a try in this PR?

[alexarice]

I tried to put some motivation in the PR description and there is a bit more discussion in #3318 about needing to verify properties during parsing with the old system (I have rebased that PR onto this PR).

[superlopuh]

Thank you, happy to approve once the CI passes

[alexarice]

It might be worth making a type alias for this, as it appears in a few places

[alexarice]

Also, my first instinct would be to somehow be a bit more lazy about the resolver situation, would it make sense to make them into lazy model objects, that let the user iterate over the keys, and define each function only once, instead of creating wrappers of wrappers. Not 100% sure if it would work, but might be worth a try in this PR?

I'm also not sure how happy I am about stacks of wrappers. Another option which could be worth trying is to have a resolver be a list of "accessors" where each accessor is a piece of data (such as the attribute name, or operand index). I haven't tried putting this into action so I'm not sure how messy it would get.

Could you expand on what you mean by "lazy model objects"?

[superlopuh]

Something like

class AbstractResolver(abc.ABC):
    @abstractmethod
    def iter_variables() -> Iterator[str]: ...

     @abstractmethod
    def resolve(attr: Attribute) -> Attribute | Sequence[Attribute]:
        ...

@dataclass
class WhateverResolver(AbstractResolver):

    a: AbstractResolver
    b: AbstractResolver

    def iter_variables() -> Iterator[str]:
        yield from a.iter_variables()
        yield from b.iter_variables()

    def resolve(attribute: Attribute) -> Attribute | Sequence[Attribute]:
        return a.resolve(attribute) if creative_condition else b.resolve(attribute)