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

Implement Function Call Graph #10332

Closed
wants to merge 23 commits into from
Closed

Implement Function Call Graph #10332

wants to merge 23 commits into from

Conversation

Marenz
Copy link
Contributor

@Marenz Marenz commented Nov 18, 2020

No description provided.

@stackenbotten
Copy link

There was an error when running chk_coding_style for commit 9ed0514f8ecf655253d8bd3a20775981782a1c33:

Coding style error:
 libsolidity/codegen/ir/IRGenerator.cpp:138: for(auto& [hash, functionType]: _graph.contract.interfaceFunctionList())

Please check that your changes are working as intended.

if (auto node = std::get_if<ASTNode const*>(&m_currentNode))
callableNode = dynamic_cast<CallableDeclaration const*>(*node);

ContractDefinition const* super =
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please extract CompilerContext::superFunction to a common place instead of re-implementing it here.

@Marenz Marenz force-pushed the function-call-graph branch 2 times, most recently from 37d1e0d to 3fff79e Compare November 30, 2020 18:07
@Marenz Marenz marked this pull request as ready for review November 30, 2020 18:09
@Marenz Marenz force-pushed the function-call-graph branch 4 times, most recently from c923dd5 to 294f805 Compare December 1, 2020 12:02
@ekpyron
Copy link
Member

ekpyron commented Dec 7, 2020

In general: Are getters for public state variables intentionally exempt from both the call graph and its verification?

@chriseth
Copy link
Contributor

chriseth commented Dec 8, 2020

I don't think getters are too important for now. The following components are planned to use the call graph and none needs support for getters:

  • improved unassigned return variable analysis
  • determine which contracts will be created from this one
  • determine which events and error codes will be used from the current contarct

return m_graph->edges[_caller].insert(_callee).second;
}

void FunctionCallGraphBuilder::processFunction(CallableDeclaration const& _callable, bool _calledDirectly)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe rename: functionReferenced to make it clear that this is not something like processFunctionCall

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. I was planning to rename things to be clearer once I finish looking for failing cases anyway.


for (auto arg: contract->baseContracts())
arg->accept(*this);

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we have to reset m_currentNode here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. Probably. I think this is what makes functions called from constructors have an edge from EntryCreation rather than from the constructor itself. I left it like that for now because it wasn't outright broken but I was planning to change that once I'm done with the fixes/tests.

add(m_currentDispatch, &_callable);

if (!m_graph->edges.count(&_callable))
visitCallable(&_callable);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would feel safer if we just added this to a queue instead of visiting it right away.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. Right now it's recursive and we might run out of stack space on some very long call chains. I'll change that.

@cameel cameel force-pushed the function-call-graph branch 2 times, most recently from ee4c282 to 222f4bc Compare February 11, 2021 18:17
@cameel
Copy link
Member

cameel commented Feb 11, 2021

I went through all the comments and marked the ones that have been fixed as resolved. There are actually quite a few that are still relevant. I'll be fixing them now along with the rest of the stuff I mentioned in my previous comment,

@cameel
Copy link
Member

cameel commented Feb 11, 2021

This PR has become too big for it's own good and there seem to be problems with discussing some of the older comments. When I have another batch of fixes ready, I'm going to close it and just create a new one.

@cameel cameel mentioned this pull request Feb 17, 2021
@cameel
Copy link
Member

cameel commented Feb 18, 2021

I'm closing this PR in favor of #10973 which is now down and has fixes for nearly all stuff mentioned in the comments above.

I didn't push any new code here to preserve it so that we can go back to older implementation and comments if needed.

@cameel cameel closed this Feb 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants