googleprojectzero / googleprojectzero/fuzzilli

Mapping identifier names based on variable declaration kind

Open
#494 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Swift
Stars
2.3k
Forks
367
Avg merge
23h 53m
Merged PRs (30d)
1

Description

Here is a problem
sample.js

{
    var a = 1
}
console.log(a)

is identical to liftToJS(compile(sample.js))

Yet, if we look at the FuzzIL representation, we see that the Compiler didn't use v1 for console.log but v2 instead, which is unnecessary.
The problem is that the map function maps the identifier a to a FuzzIL variable in the most recently opened scope, i.e. the BlockStatement. Outside of the BlockStatement lookupIdentifier doesn't find the FuzzIL variable anymore and therefore creates a new one.

BeginBlockStatement
    v0 <- LoadInteger '1'
    v1 <- CreateNamedVariable 'a', 'var', v0
EndBlockStatement
v2 <- CreateNamedVariable 'a', 'none'
v3 <- CreateNamedVariable 'console', 'none'
v4 <- CallMethod v3, 'log', [v2]

I assume that the map function works correctly for variable declarations of the let and const type but not for globals or var. I would propose giving the map function a parameter that controls in which scope on the stack the identifier should be saved instead of just using scopes.top.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the compiler's map function and lookupIdentifier behavior, using the sample.js snippet to reproduce the FuzzIL output shown in the issue. Trace how scopes.top handles var and global identifiers versus let and const. Done means the outer console.log lookup reuses the declared variable rather than creating an unnecessary new one, without breaking block-scoped declarations.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, swift
Domain
compilers
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.