Implement a basic model for functools.total_ordering

[fangyi-zhou]

This PR adds modelling of functools.total_ordering (closes #491), which allows a class with (at least) one rich comparison method to automatically have all other rich comparison methods.

At a high level, this PR incorporates the following changes:

1. Capture is_total_ordering in class metadata if the decorator is present.
2. Synthesize missing rich comparison methods for those decorated classes.
3. Report an error if the decorator is present but no rich comparison method is present.

I have some open issues that can be fixed either in this PR after receiving some code pointers, or in subsequent PRs.
Open issues (marked in FIXMEs):

• Error is currently raised on class declaration, ideally it should be on the decorator
• Type information for synthesized rich comparison methods are not following the comparison method they're synthesizing from: e.g. if __lt__ is synthesized from __gt__, then they should have the same type. Currently we model the synthesizing order, but we are not giving the same type.
• Classes that have synthetic methods via multiple pathways will not have all the synthetic methods. For example, it's possible to decorate a class with @dataclass and @total_ordering at the same time, and they should have synthesized methods from both decorators.

[yangdanny97]

Error is currently raised on class declaration, ideally it should be on the decorator

For this, instead of using a boolean flag in the class metadata you can have a TotalOrderingMetadata that holds a range instead (or just an Option<TextRange> to keep it simple, with is_total_ordering being a method that checks that it's not None).

Then you can emit the error according to that range.

[yangdanny97]

Classes that have synthetic methods via multiple pathways will not have all the synthetic methods. For example, it's possible to decorate a class with @dataclass and @total_ordering at the same time, and they should have synthesized methods from both decorators.

We could probably add a merge method to ClassSynthesizedFields and calculate + merge total_ordering separately from the other stuff.

pyrefly/pyrefly/lib/alt/types/class_metadata.rs

Line 281 in 39f10dd

pub struct ClassSynthesizedFields(SmallMap<Name, ClassSynthesizedField>);

[fangyi-zhou]

Error is currently raised on class declaration, ideally it should be on the decorator

For this, instead of using a boolean flag in the class metadata you can have a TotalOrderingMetadata that holds a range instead (or just an Option<TextRange> to keep it simple, with is_total_ordering being a method that checks that it's not None).

Then you can emit the error according to that range.

Is there a way to get a text range of the decorator in class_metadata_of? I don't seem to find a way to find the text range from the decorator.

[yangdanny97]

BindingClassMetadata doesn't give this information, but we could change its decorator representation from pub decorators: Box<[Idx<Key>]>, to pub decorators: Box<[(Idx<Key>, TextRange)]>, and populate the range when we create the binding.

decorator_list of the parsed node will have the ranges, so maybe we could edit this function to return the range along with the key

pyrefly/pyrefly/lib/binding/class.rs

Line 118 in 231ac8d

self.ensure_and_bind_decorators(mem::take(&mut x.decorator_list), class_object.usage());

[fangyi-zhou]

Thanks so much for the code pointers, @yangdanny97! Really appreciate your help!

[facebook-github-bot]

@yangdanny97 has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[yangdanny97]

Great work, thanks! We'll get this merged soon.

[facebook-github-bot]

@yangdanny97 merged this pull request in d415773.