You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should construct FunctionVariables for each StackFrame, but currently we don't care about inlining (we are fine with the logic being wrong if there are more frames than 1 in a substack) since:
We are in MVP stage.
Only cases where inlining is present are #[inline(always)] cases and they are rare (user can always comment out the attribute if they want to debug such a function).
When creating FunctionVariables when we are on the given statement, we would still be, from sierra POV, in a body of a ONE function which may contain bodies of OTHER function that were inlined. For each statement from beginning of the function to the current statement: compare profiler mappings and current sierra call stack to tell if a statement is a part of inlined function body or "real" function body. Then based on that, assign the variable value to the proper function (so we would in fact create Vec<FunctionVariables>).
We should construct
FunctionVariablesfor eachStackFrame, but currently we don't care about inlining (we are fine with the logic being wrong if there are more frames than 1 in a substack) since:#[inline(always)]cases and they are rare (user can always comment out the attribute if they want to debug such a function).To handle inlines, do as follows:
FunctionVariableswhen we are on the given statement, we would still be, from sierra POV, in a body of a ONE function which may contain bodies of OTHER function that were inlined. For each statement from beginning of the function to the current statement: compare profiler mappings and current sierra call stack to tell if a statement is a part of inlined function body or "real" function body. Then based on that, assign the variable value to the proper function (so we would in fact createVec<FunctionVariables>).