Skip to content
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

initialisation of stateless modules #3934

Open
pcaversaccio opened this issue Apr 10, 2024 · 3 comments
Open

initialisation of stateless modules #3934

pcaversaccio opened this issue Apr 10, 2024 · 3 comments

Comments

@pcaversaccio
Copy link
Collaborator

Not sure whether this is a bug or feature, but the initialisation of stateless modules compiles:

# lib.vy
@deploy
@payable
def __init__():
    pass

@internal
@pure
def _uint256_average(x: uint256, y: uint256) -> uint256:
    return unsafe_add(x & y, (x ^ y) >> 1)


# main.vy
import lib
initializes: lib

@deploy
def __init__():
    lib.__init__()

@external
@pure
def uint256_average(x: uint256, y: uint256) -> uint256:
    return lib._uint256_average(x, y)
pcaversaccio added a commit to pcaversaccio/snekmate that referenced this issue Apr 10, 2024
### 🕓 Changelog

This PR refactors the `Math` contract to make it module-friendly and
ready for the breaking `0.4.0` release. Furthermore, I remove the
initialisation for stateless modules (see
[here](vyperlang/vyper#3934) for the issue).
It's important to note that if a contract is stateless in the sense that
it does not access storage or `immutable`s but still uses `nonreentrant`
decorators, it implicitly uses/accesses state via the `SLOAD` of the
`$.nonreentrant_key` key at (default) slot `0`, and thus requires the
`uses` or `initializes` syntax.

---------

Signed-off-by: Pascal Marco Caversaccio <pascal.caversaccio@hotmail.ch>
@fubuloubu
Copy link
Member

seems like it should just emit a warning about it not really being neccessary to do

@charles-cooper
Copy link
Member

i'd say if we're going to issue a warning, we might as well issue an error. initializing a stateless module seems like an error tbh. (i think in most languages it would be considered a linter issue, but in vyper we have always been a bit more aggressive about promoting "lint-level" issues into compiler errors).

@pcaversaccio
Copy link
Collaborator Author

I think disallowing this behaviour makes most sense, i.e. throw a compiler error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants