fix[lang]: improve error message for exprs in type position

[rafael-abuawad]

What I did

Fixed a compiler panic when a name in a type position resolves to a VarInfo. The compiler now raises InvalidType with the existing '…' is not a type! message for that case, and keeps CompilerPanic for other unexpected non-VyperType namespace values.

How I did it

In _type_from_annotation in vyper/semantics/types/utils.py, after resolving a Name through the namespace and unwrapping ModuleInfo, the code now checks isinstance(typ_, VarInfo) before the fallthrough CompilerPanic. If it is a VarInfo, it raises InvalidType(err_msg, node) using the existing error message; otherwise the CompilerPanic is preserved for truly unexpected values.

How to verify it

1. Minimal repro using GH 4865
2. Local compiler

Commit message

when a name used in a type position resolves to `VarInfo` (e.g.
`empty(MAX_MESSAGES)` where `MAX_MESSAGES` is a constant, or using a
constant as a type annotation like `x: N`), the compiler raised
`CompilerPanic`. the namespace can legitimately contain `VarInfo`
entries — constants, immutables, state variables, and function
parameters all resolve to `VarInfo` — so hitting this branch is a
user error, not a compiler bug.

raise `InvalidType` with the existing "not a type" message for
`VarInfo`, and keep `CompilerPanic` for other unexpected non-type
namespace values.

Description for the changelog

Semantics: treat VarInfo in type position as InvalidType, not CompilerPanic (GH 4865).

Cute Animal Picture

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.06%. Comparing base (eab4648) to head (1625cb7).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #4898   +/-   ##
=======================================
  Coverage   92.06%   92.06%           
=======================================
  Files         187      187           
  Lines       27132    27135    +3     
  Branches     4758     4759    +1     
=======================================
+ Hits        24978    24981    +3     
  Misses       1437     1437           
  Partials      717      717           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[charles-cooper]

thanks for the submission, looks fine overall, requested style changes

[Sporarum]

I'm not sure this is the right fix, it seems to me like a better error for

MAX_MESSAGES: constant(uint256) = 64

@external
def parse_blob(blob: Bytes[4096]):
    starts: DynArray[uint16, MAX_MESSAGES] = empty(MAX_MESSAGES)

would be something like:
"Only literal constants and expressions (10, 1 + 1) are allowed as lengths for DynArray"

Because 2 is not a type either, but DynArray[uint16, 2] is valid !

There's also the question of whether we should just allow the above, since MAX_MESSAGES is a compile-time constant

[rafael-abuawad]

@Sporarum The error is not that they are using a constant for the length of the DynArray. The issue is that they are calling empty(<CONSTANT>) and the compiler panics

[Sporarum]

@rafael-abuawad oh, of course

Then I think it would make sense to add a couple more tests (if they don't already exist) of similar cases, for example:

convert(something, MAX_MESSAGES)

(and every other spot where a type can be)

[rafael-abuawad]

@Sporarum im going to add a few more tests maybe 2 or 3 to see how it handles that. And going to remove the compile panic line

[Sporarum]

@rafael-abuawad did you get around to add more tests ?

[rafael-abuawad]

@rafael-abuawad did you get around to add more tests ?

Hey @Sporarum , no, not yet I'm going to do so this weekend hopefully

[rafael-abuawad]

@Sporarum I've added more tests, but I don't know if that's enough

[Sporarum]

@rafael-abuawad
My idea was more to test more breadth of errors than more cases of specifically empty(<something which is not a type>)

For example:

x: <not a type>
convert(x, <not a type>)
x: <not a type>[10]
def foo(x: <not a type>)
def foo() -> <not a type>

But it's also something I can do myself if you prefer

[rafael-abuawad]

My idea was more to test more breadth of errors than more cases of specifically empty(<something which is not a type>)

@Sporarum understood, I’ve added more tests. Sorry, I became too short-sighted. I didn’t want to go overboard with the tests, but I think this list covers enough

[Sporarum]

Very nice, thanks !

[rafael-abuawad]

@Sporarum @charles-cooper do you need anything else from my side to have this merged?

[charles-cooper]

Looks good, will merge shortly

[charles-cooper]

@rafael-abuawad looks like there is something not resolving correctly on initialization, can you fix? probably if you get lint passing it should be good

[rafael-abuawad]

@charles-cooper I think that was it, I was able to run the lint properly, but I don't know how to re-run the checks