Skip to content
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

Evaluate the use of Handle pointers as results #3962

Closed
iposva-google opened this issue Jul 2, 2012 · 5 comments
Closed

Evaluate the use of Handle pointers as results #3962

iposva-google opened this issue Jul 2, 2012 · 5 comments
Assignees
Labels
area-vm Use area-vm for VM related issues, including code coverage, FFI, and the AOT and JIT backends. P3 A lower priority bug or feature request type-code-health Internal changes to our tools and workflows to make them cleaner, simpler, or more maintainable

Comments

@iposva-google
Copy link
Contributor

During an unrelated code review I noticed this:

const Instance* StaticGetterNode::EvalConstExpr() const { ... }

We should evaluate all of the places where we return pointers to handles instead of RawXYZ*.

@DartBot
Copy link

DartBot commented Jul 3, 2012

This comment was originally written by @mhausner


The EvealConstGetter() method on AstNode returns a pointer on purpose. Actually, for two reasons:

  1. The return value NULL means that the expression is not a compile time constant.
  2. Each node in the expression tree would have to allocate a new handle for its operand(s), only to look at the type of the operand(s), and then return a raw value for which the parent of the node will have to allocate another handle.

I didn't want to "waste" handles, thus the scheme of returning pointers. The handles are not used for anything else once the evaluation of the expression is complete.

Another scheme might be that the caller provides the handle, but nodes with 2 operands would still have to allocate an additional handle.

@iposva-google
Copy link
Contributor Author

Added this to the Later milestone.
Removed Type-Defect, Priority-Medium labels.
Added Type-CodeHealth, Priority-Low labels.

@kasperl
Copy link

kasperl commented Jul 10, 2014

Removed this from the Later milestone.
Added Oldschool-Milestone-Later label.

@kasperl
Copy link

kasperl commented Aug 4, 2014

Removed Oldschool-Milestone-Later label.

@iposva-google iposva-google added type-code-health Internal changes to our tools and workflows to make them cleaner, simpler, or more maintainable P3 A lower priority bug or feature request area-vm Use area-vm for VM related issues, including code coverage, FFI, and the AOT and JIT backends. Accepted labels Aug 4, 2014
@mhausner
Copy link
Contributor

mhausner commented Dec 4, 2015

I think we can close this now. The sky hasn't fallen in the past 3.5 years :-)

@mhausner mhausner closed this as completed Dec 4, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-vm Use area-vm for VM related issues, including code coverage, FFI, and the AOT and JIT backends. P3 A lower priority bug or feature request type-code-health Internal changes to our tools and workflows to make them cleaner, simpler, or more maintainable
Projects
None yet
Development

No branches or pull requests

5 participants