Skip to content

assign_op with overloaded operator evaluates receiver twice #2528

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
catamorphism opened this issue Jun 7, 2012 · 3 comments
Closed

assign_op with overloaded operator evaluates receiver twice #2528

catamorphism opened this issue Jun 7, 2012 · 3 comments
Labels
A-codegen Area: Code generation I-slow Issue: Problems and improvements with respect to performance of generated code.

Comments

@catamorphism
Copy link
Contributor

The user-defined operator case in trans::base::trans_assign_op passes an expr evaluating to the callee's address, rather than the callee address, to trans_call_inner. Since the callee is known, this should be the statically known callee address (as per a FIXME).

@nikomatsakis
Copy link
Contributor

This is much worse than this description makes it sound. If I'm reading the code correctly, what's actually happening here is that expr_x += expr_y results in expr_x being trans'd twice (e.g., foo().x += 3 would call foo() twice) if + is overloaded. The proper fix is to refactor the impl::trans_method_callee callee function to take a pre-evaluated self expression, I think, or perhaps have it be a shallow wrapper around a function which does.

@pcwalton
Copy link
Contributor

I have a PR to fix this by removing overloaded operator assign ops altogether.

@thestinger
Copy link
Contributor

These are removed for the time being.

celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-codegen Area: Code generation I-slow Issue: Problems and improvements with respect to performance of generated code.
Projects
None yet
Development

No branches or pull requests

4 participants