Operator overloading

[SimplyTheOther]

Rust supports overloading some operators using traits in std::ops or std::cmp, as mentioned in the reference.

The operators that can be overloaded are:

• DereferenceExpr (with std::ops::Deref::deref(&x) or std::ops::DerefMut::deref_mut(&mut x))
• NegationExpr (with std::ops::Neg or std::ops::Not)
• ArithmeticOrLogicalExpr (with std::ops::x where x is Add, Sub, Mul, Div, Rem, BitAnd, BitOr, BitXor, Shl, or Shr)
• ComparisonExpr (with std::cmp::PartialEq::x where x is eq, ne, gt, lt, ge, or le)
• CompoundAssignmentExpr (with std::ops::xAssign where x is one of the values listed in ArithmeticOrLogicalExpr)

Currently, gccrs does not implement operator overloading and presumably just creates GENERIC/GIMPLE of the operator expression with a type that can't be handled.

One method of implementing operator overloading could be a pass that replaces certain OperatorExprs with function calls. This has some issues:

• If this pass occurs after name resolution but before lowering to HIR, the types involved are not known. As such, there is no way to know which function calls to replace (as you can't overload the operators on integers, for instance).
• If this pass occurs after type resolution (in HIR), then the extent to which the HIR can be simplified is limited. For example, currently the HIR has no representation for a CompoundAssignmentExpr - it converts one into an AssignmentExpr and an ArithmeticLogicalExpr. But it is possible to overload operator +=, for instance, without also overloading operator +. So the HIR would have to have a separate CompoundAssignmentExpr representation for this reason.

Another method of implementing operator overloading could simply be to convert every OperatorExpr to a function call at some point, even ones for primitive types. This would also lead to some issues:

• Type resolution would be more difficult, as some type inference can conceivably be performed by knowing certain properties about an operator (e.g. that ComparisonExprs have a boolean output). Either type resolution would not be able to access this information or more complicated code would be required to allow it.
• Additional code would be required to convert some of these function calls back to operators when converting to GENERIC/GIMPLE so that primitive types don't require a function call every time an operation is performed on them.

---

• Implement a lang-item parsing and lookup at type-resolution level
• Revert the desugaring of the HIR CompoundAssignmentExpr into an assignment
• Refactor backend method call expression logic to be more reusable for operator overloading
• Let GCC inline the operator overloading and support the inline attribute
• Implement ArithmeticOrLogicalExpr logic
• Implement CompoundAssignmentExpr TREE_ADDRESSABLE is not being set when required #804
• Implement DereferenceExpr Deref operator overloading #809
• Implement NegationExpr

[bjorn3]

Rustc keeps these intact up to the HIR. After typechecking, while lowering to MIR it generates THIR (typed HIR) on the fly, which does lower it to function calls as necessary I believe. It may also happen during the THIR to MIR lowering. The HIR is always immutable in rustc.

[NalaGinrut]

• If this pass occurs after name resolution but before lowering to HIR, the types involved are not known. As such, there is no way to know which function calls to replace (as you can't overload the operators on integers, for instance).

Generally speaking, the pass could be immutable by just recording the necessary information and delay the actual replacement to the later pass.

• Additional code would be required to convert some of these function calls back to operators when converting to GENERIC/GIMPLE so that primitive types don't require a function call every time an operation is performed on them.

I'm afraid the IR recovery back and forth is a bad way to go. We may record the op-func relationship in a table. So we don't have to recover the node. I presume there would be a recursive node replacement, which introduces complexity.

[philberty]

This is something that will have to be tackled as part of traits in my opinion.

[philberty]

I think we need to be able to do #442 and #434 with #471 before we can do operator overloading.

I suspect there is some GENERIC magic that will help here from C++ or there is an example in libgccjit and operator overloading for primitive types as well.

For the first pass this will need to fix #367 as well.

Though thinking we also need to fix #241 and I am starting to think we should enforce our HIR to be immutable now since it has been the case so far. Then we can emit THIR so we have a chance during type resolution to fix up type coercions and adjustments properly without resorting to wierd hacks in the GENERIC generation.

[philberty]

I think THIR will solve a lot of niggly issues for the traits milestone: https://rustc-dev-guide.rust-lang.org/thir.html

[philberty]

I just made a toy compiler explorer to see how GCC in C++ handles inlining of operator overloading:

https://godbolt.org/z/7G4xh5WYE

It seems we won't need to mark any operator overloads as inline if optimizations are turned on we get the inlining for free. I have a toy branch working on this, but its only handling custom ADTTypes that implement the add trait, I have some issues with primitive types which also implement the trait at the moment, there might be something to do with lang-items that helps here but I have a lot of buggy code in this branch to deal with first.

[philberty]

The deref operator overloading is tracked over: #809