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

Let 'unused variable' be a warning #187

Open
dagurval opened this issue Feb 1, 2024 · 2 comments
Open

Let 'unused variable' be a warning #187

dagurval opened this issue Feb 1, 2024 · 2 comments
Labels
cashc-compiler Relates to the cashc compiler

Comments

@dagurval
Copy link
Contributor

dagurval commented Feb 1, 2024

When debugging, it would be nice if errors like

Unused variable prefix at Line 71, Column 8

... could be a warnings instead of compilation error.

This allows for more easilly temporarily commenting out code.

@mr-zwets
Copy link
Member

yeah definitely need a way to still have the compiled output, maybe with a flag for testing.

This would allow for Test-Driven-Development where the smart contract code is written on the fly based on tests.

@kiok46
Copy link
Contributor

kiok46 commented Oct 27, 2024

I wanted to disable the ‘unused variable’ error or at least convert it into a warning. The error is triggered during the semantic analysis in the SymbolTableTraversal class so I added:

if (unusedSymbols.length !== 0) {
    unusedSymbols.forEach((symbol) => {
        console.warn(`[Warning] Unused variable: ${symbol.name} in block`);
    });
    // throw new UnusedVariableError(unusedSymbols[0]);
}

Removing the unused symbol using it's index from the tree (node.statements) resulted in the expected bytecode. (Only in block, not function/constructor params). One test failed as it expected a throw. I guess Jest’s spyOn can be used to expect a console.warn instead.

I’m curious if there’s been any further discussion on this. What’s the preferred approach here? Should unused variables be stripped from the bytecode, or should they remain? I noticed that Solidity keeps them in the bytecode unless the optimizer is enabled but cashscript's optimisations are enabled by default.

@mr-zwets mr-zwets added the cashc-compiler Relates to the cashc compiler label Nov 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cashc-compiler Relates to the cashc compiler
Projects
None yet
Development

No branches or pull requests

3 participants