mProjectsCode / mProjectsCode/glass-lint
Differnciate between static and unresolved dynamic code
Open
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 1
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
Currently, we have one broad rule for dynamic code, but certain patterns use static strings for e.g. delayed module loading. We can use our static analyzer to identify such cases and report a different diagnostic.
eval("loadModule('x')") -> known source
eval(42) -> no dynamic-code finding
eval(userInput) -> unresolved source, higher concern
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the existing broad dynamic-code rule and its static-analyzer diagnostic. Compare the three eval examples in the issue: static source should receive a distinct diagnostic, a non-code literal should produce no dynamic-code finding, and unresolved input should receive the higher-concern result; add tests covering these outcomes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- devtools, security
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100