Improving Beginner Accessibility in Vyper's Compiler Error Messages While Considering User-Defined Types

Improving Error Accessibility Without Compromising Safety

To enrich compiler messages for beginners without weakening safety guarantees, Vyper can implement a compile-time only type metadata layer. This approach separates the information used for developer diagnostics from the logic used for bytecode generation, ensuring that the security-first runtime remains unchanged.

The Proposed Design Approach

The most viable method to incorporate user-defined types while limiting attack surfaces is to introduce shadow types. These are structural definitions that exist only within the compiler's Abstract Syntax Tree (AST) and are stripped entirely before the code is lowered to Yul or EVM bytecode.

• Metadata-Only Structs: Allow developers to define structs that serve as "labels" for groups of variables. The compiler uses these labels to provide context in error messages (e.g., "Type mismatch in UserProfile.age (expected uint256, got address)" instead of "Type mismatch at line 42").
• Zero Runtime Footprint: Because these types are not mapped to storage slots or memory offsets in the final bytecode, they introduce no new opcodes and no new attack vectors for malformed data.
• Gated Implementation: To maintain backward compatibility, this feature should be introduced via a compiler version flag or a specific language pragma, ensuring existing tooling continues to operate on the simplified type system.

Likely Technical Explanation

Currently, Vyper's concise errors stem from a type checker that operates on a simplified AST. By expanding the AST to retain user-defined type associations during the semantic analysis phase, the compiler can map a verification failure back to a named structure. Since the lowering process (Vyper → Yul → EVM) ignores these metadata labels, the safety guarantees and the resulting ABI remain identical to the current implementation.

Verification Steps

To verify that this implementation does not introduce vulnerabilities or regressions, the following scoped tests are recommended:

1. Bytecode Diffing: Compile a contract with and without shadow type definitions. Use a tool like evm disasm to confirm the resulting bytecode is identical.
2. Diagnostic Comparison: Trigger a type mismatch error in a contract using shadow types and verify that the error message references the user-defined type name rather than just the line number.
3. Regression Suite: Run the existing Vyper test suite to ensure that the introduction of the metadata layer does not impact compilation time or memory usage beyond acceptable limits.

Missing Detail: To refine this recommendation, it is necessary to know if the target environment requires support for these types in external IDE plugins (LSP), as this would necessitate exporting the metadata layer beyond the compiler itself.