fix[lang]: allow type expressions inside pure functions #3906
Conversation
20432c5 introduced a regression where type expressions like the following would raise a compiler error instead of successfully compiling: ``` @pure def f(): convert(..., uint256) # raises `not a variable or literal: 'uint256'` ``` the reason is because `get_expr_info` is called on `uint256`, which is not a regular expr. this commit introduces a fastpath return to address the issue. longer-term, we should generalize the rule so that ast traversal does not progress into type expressions.
charles-cooper
requested review from
fubuloubu,
harkal,
cyberthirst and
pcaversaccio
There was a problem hiding this comment.
Tested all snekmate contracts and they passed successfully.
[UNRELATED TO THIS PR; ADDED FOR DOCUMENTATION PURPOSES]
While reviewing this PR, I realised something else weird in the NatSpec output of the compiler. The __init__ function is ignored.
Example to reproduce:
vyper src/snekmate/governance/mocks/TimelockControllerMock.vy -f devdoc,userdocwill produce:
{"title": "TimelockController Module Reference Implementation", "custom:contract-name": "TimelockControllerMock", "license": "GNU Affero General Public License v3.0 only", "author": "pcaversaccio"}But it completely ignores my NatSpec comments in the ctor (see here). I opened an issue for tracking #3907.
Codecov ReportAll modified and coverable lines are covered by tests ✅
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## master #3906 +/- ##
==========================================
- Coverage 90.92% 88.88% -2.04%
==========================================
Files 95 95
Lines 14386 14389 +3
Branches 3185 3187 +2
==========================================
- Hits 13080 12790 -290
- Misses 904 1138 +234
- Partials 402 461 +59 ☔ View full report in Codecov by Sentry. |
20432c5 introduced a regression where type expressions like the following would raise a compiler error instead of successfully compiling: ``` @pure def f(): convert(..., uint256) # raises `not a variable or literal: 'uint256'` ``` the reason is because `get_expr_info` is called on `uint256`, which is not a regular expr. this commit introduces a fastpath return to address the issue. longer-term, we should generalize the rules in `vyper/semantics/analysis/local.py` so that AST traversal does not progress into type expressions.
#3895 introduced a regression where type expressions like the following would raise a compiler error instead of successfully compiling:
the reason is because
get_expr_infois called onuint256, which is not a regular expr. this commit introduces a fastpath return to address the issue. longer-term, we should generalize the rule so that ast traversal does not progress into type expressions.What I did
How I did it
How to verify it
Commit message
Commit message for the final, squashed PR. (Optional, but reviewers will appreciate it! Please see our commit message style guide for what we would ideally like to see in a commit message.)
Description for the changelog
Cute Animal Picture