Only I am not accessing such attributes, I am simply calling a macro on the template line that triggers this. More specifically, the generated call throwing this is:.
echo twig_get_attribute($this->env, $this->getSourceContext(), ($context["util"] ?? null), "toc", array(), "method");
This happens from a file included using the {% include ... %} tag.
I have also gotten bunch of these: Warning: in file [ROOT]/vendor/Twig/Extension/Escaper.php, on line 72: call_user_func() expects parameter 1 to be a valid callback, no array or string given. But I am still investigating on their exact cause.
As for the second thing, just checked the changelog for 1.30, that seems to have provided the answer for that. As for the first one though, still confused.
In case someone else comes across this problem, the "solution" is to reimport the macros again in the included file. Perhaps this is intended or then it isn't.
Either way, props for a very confusing error message. Not to mention behavior that is not intuitive in the slightest. Per include docs, the context of the parent is inherited by the included file (barring the use of only and with etc.), and as I understand macros are imported into that context, which should be inherited by the included template (though obviously it isn't or then your definition of inherit is rather fuzzy).
Looks like a duplicate of #2336
If you treat this as a duplicate of #2336, then there is still an issue here. The behavior and documentation do not match, regardless of whether 1.x gave deprecation warnings or not.
From include documentation;
Included templates have access to the variables of the active context.
From import documentation:
The easiest and most flexible is importing the whole module into a variable.
The above phrasing is implicitly the same as "...into a variable in the active context." Because variables exist in a context. So, the now deprecated 1.x behavior matched the documentation whereas 2.0 behavior does not.
Ignoring the unhelpful error message here (as it is both not descriptive, and is shown for the wrong file and line). Not to mention this new intended behavior reduces the utility of macros and increases boilerplate template code.
Error message were improved a while ago, and #2953 makes the documentation clearer about the expectations.
Most helpful comment
In case someone else comes across this problem, the "solution" is to reimport the macros again in the included file. Perhaps this is intended or then it isn't.
Either way, props for a very confusing error message. Not to mention behavior that is not intuitive in the slightest. Per include docs, the context of the parent is inherited by the included file (barring the use of only and with etc.), and as I understand macros are imported into that context, which should be inherited by the included template (though obviously it isn't or then your definition of inherit is rather fuzzy).