fix[lang]: reject type names passed as builtin varargs - #5195
Open
beardthelion wants to merge 1 commit into
Open
beardthelion wants to merge 1 commit into
beardthelion wants to merge 1 commit into
Conversation
Sporarum
approved these changes
Sep 9, 2026
Sporarum
left a comment
Collaborator
There was a problem hiding this comment.
Looks very good !
One small potential nitpick below
Builtins with variable arguments (abi_encode, print, raw_create, create_from_blueprint) inferred each vararg's type for its side effects but never checked the argument was a runtime value. A bare type name infers to TYPE_T, which passed the vararg check and slipped through to codegen, where it panicked (`TYPE_T does not implement abi_type`, `'IntegerT' object has no attribute 'typ'`). Reject a TYPE_T vararg during semantic analysis with the same "not a variable or literal" error the language already raises for a type name in value position (e.g. `x: uint256 = uint256`). Part of vyperlang#4609
beardthelion
force-pushed
the
fix/vararg-type-name-panic
branch
from
September 9, 2026 13:05
7e30e47 to
7781981
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What I did
Builtins that take variable arguments never semantically checked them, so a bare type name passed as a vararg reached codegen and crashed the compiler with an internal panic. This rejects that case during semantic analysis. Part of #4609
How I did it
BuiltinFunctionT._validate_arg_typesinferred each vararg's type only for its side effects and discarded the result. A bare type name likeuint256infers toTYPE_T, which is exactly inferable, so it passed the check and slipped through to codegen, whereTYPE_Thas noabi_type/typ/locationand the compiler panicked. The vararg loop now inspects the inferred type and rejectsTYPE_TwithInvalidReference, the same "not a variable or literal" error the language already raises for a type name in value position (x: uint256 = uint256).How to verify it
On master both of these panic:
After this change both raise
InvalidReference: not a variable or literal: 'uint256'at compile time. Regression tests are intests/functional/syntax/test_abi_encode.pyandtests/functional/syntax/test_print.py.Commit message
Description for the changelog
Reject a bare type name passed as a builtin vararg (e.g.
abi_encode(uint256)) with a clear error instead of an internal compiler panic.Cute Animal Picture