-
-
Notifications
You must be signed in to change notification settings - Fork 138
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
[Twig] Improve Twig types support #1035
Labels
Comments
Iterators call also not resolved properly: class GeneratedReport implements \IteratorAggregat
{
/**
* @return Row[]
*/
public function getIterator()
{
// ...
}
} {% for report in reports %}
{# @var report \App\Reporting\Generated\GeneratedReport #}
<table cellspacing="0" border="0">
{% for row in report %}
{{ row.<NO AUTOCOMPLETE HERE> }}
<tr>
{% for cell in row %}
<td
{% if cell.colspan > 1 %}colspan="{{ cell.colspan }}"{% endif %}
{% if cell.rowspan > 1 %}colspan="{{ cell.rowspan }}"{% endif %}
class="{{ cell.purpose }}"
>
{{ cell.value }}
</td>
{% endfor %}
</tr>
{% endfor %}
</table>
{% endfor %} Also I've tryed write |
This was referenced Dec 16, 2017
Ref #576 |
Haehnchen
added a commit
that referenced
this issue
Dec 18, 2017
Haehnchen
added a commit
that referenced
this issue
Dec 18, 2017
first comment done. |
Really cool, thank you! |
Haehnchen
added a commit
that referenced
this issue
Dec 19, 2017
Haehnchen
added a commit
that referenced
this issue
Dec 19, 2017
great work 👍 |
Haehnchen
added a commit
that referenced
this issue
Dec 21, 2017
One interesting thing: types loosing inside nested blocks: {% block one %}
{# @var \Foo a #}
{% set a = func() %}
{{ a.<AUTOCOMPLETE OK> }}
{% block two %}
{{ a.<NO AUTOCOMPLETE HERE> }}
{% endblock %}
{% endblock %} Maybe PS bug |
Haehnchen
added a commit
that referenced
this issue
Dec 26, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Follow-up of #972
MeterValueDTO
is not clickableitem
type not resolves properly because I've changed order of type and variable name. But PS supports both standards, even more second is consistent with@param
declaration for methods - type first, variable name - secondThe text was updated successfully, but these errors were encountered: