New contributor looking for a good first V8 issue

[Temiloluwa]

My name is Temiloluwa, and I am a software engineer interested in getting started with V8 development.

I have set up the V8 development environment on macOS(M1), built V8 from source successfully, run d8, and run the test suite. I am currently learning C++ more deeply, particularly systems programming, low latency, memory management, and low-level optimization, and I would like to develop these skills by contributing to V8.

I have started looking through the Chromium issue tracker, but since this is my first contribution to V8, I would appreciate some guidance on a suitable issue to start with. I am happy to begin with a small bug, test improvement, cleanup, or other well-scoped task and learn the relevant part of the codebase as I work through it.

If there are any beginner-friendly or currently unowned issues that would be appropriate for a new contributor, I would be grateful for recommendations.

Thanks,
Temiloluwa

[ASTRA DEV]

Hi! As for how to contribute, it really depends on your goal. You could start by removing dead code (which is fairly straightforward, though cross-validation is recommended) or by addressing FIXME comments. However, you need to be careful with FIXMEs: a naive fix might introduce security vulnerabilities or break things, and a FIXME that looks simple might actually require a complex implementation. I described two such cases in this CL: https://chromium-review.googlesource.com/c/v8/v8/+/8135542

понедельник, 31 августа 2026 г. в 20:52:29 UTC+3, ytemi...@gmail.com:

[ASTRA DEV]

I also apologize for not providing a link to a specific issue; I’m currently busy with a personal project and not actively following the V8 codebase, so I can only offer a couple of general suggestions.
You might also want to check for behavioral consistency across architectures—especially RISC-V; it’s a relatively new area, and in my experience, there are more gaps there.

понедельник, 31 августа 2026 г. в 21:47:26 UTC+3, ASTRA DEV:

[Marja Hölttä]

If you're interested in the JavaScript language, there are a bunch of language corner cases we never bothered to implement: https://source.chromium.org/chromium/chromium/src/+/main:v8/test/test262/test262.status;l=694?q=test262.status&ss=chromium (caveat: some of the tests might be failing for a good reason, and we might not even want to fix all corner cases if the fix would add significant complexity). Or look at the spec https://tc39.es/ecma262/ and try to find bugs that way.

If you're interested in improving benchmarks, investigating Jetstream3 / Speedometer3 performance is a good way to start. You can get the Jetstream3 benchmark as part of your V8 checkout if you set the "checkout_benchmarks": True in your custom_vars in your .gclient file. Caveat: not so easy to find new improvements, but at least looking at things there will increase your understanding.

You can also try to find bugs or vulnerabilities with whatever method you'd like (fuzzing, auditing the code...) and you can submit vulns in the Chrome vulnerability reward program  https://bughunters.google.com/about/rules/chrome-friends/chrome-vulnerability-reward-program-rules .

And just my personal opinion about AI usage: If you use AI, please use it in a way that speeds up your learning of V8, not in a way that bypasses learning. And in a way that saves us work instead of adding work for us. So, e.g., have AI review your code before you send it over (saves work), do not send us AI slop (generates more work for us).

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/v8-dev/e9150a3f-57b7-4f16-a01c-2d7bb0c8428bn%40googlegroups.com.

--

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian.

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

[Temiloluwa]

Thank you, this is very helpful. I am particularly interested in the JavaScript language side of V8, so the test262 direction sounds like a good place for me to start.

I have located test/test262/test262.status in my local checkout and I am going to start by understanding some of the skipped/failing tests there, read the corresponding ECMAScript specification sections and reproduce the behavior locally before attempting any changes.

I will keep your caveat in mind that some of the tests might be failing for a good reason, and we might not even want to fix all corner cases if the fix would add significant complexity. 

Thank you for pointing me in this direction.

[Temiloluwa]

Hi V8 team,

I started by investigating one of the skipped Test262 language corner case entries in test/test262/test262.status. Before preparing a patch, I wanted to ask whether this looks like a welcome cleanup, since the entries are in a Roll-watcher patch block.

I investigated these skipped Test262 entries:

• annexB/language/comments/single-line-html-close-first-line-1
  
• annexB/language/comments/single-line-html-close-first-line-2
  
• annexB/language/comments/single-line-html-close-first-line-3
  

They were added to test/test262/test262.status by commit 79fd9fd996f21fbf29788f89bbc07d86db830b63 during a Test262 roll. The git blame points to a Roll-watcher patch added by v8-ci-autoroll-builder.

From the upstream Test262 history, these tests were originally added for Annex B first-line --> HTMLCloseComment behavior. They were later fixed in Test262 commit 42d83277b7 because the raw tests previously used harness-provided Test262Error, the fix changed them to use EvalError instead.

On my current V8 checkout at 3e6373bb9f9, the tests pass when forced with:

tools/run-tests.py --outdir=out.gn/x64.debug --run-skipped \

  test262/annexB/language/comments/single-line-html-close-first-line-1 \

  test262/annexB/language/comments/single-line-html-close-first-line-2 \

  test262/annexB/language/comments/single-line-html-close-first-line-3

This ran 6 variants and all passed. 

The relevant scanner behavior also appears to already support this case.  Scanner::Initialize() sets the initial token as after_line_terminator, and Scanner::ScanSingleToken() treats --> as SkipSingleHTMLComment() when next().after_line_terminator is true. Modules are still rejected through SkipSingleHTMLComment() as expected for Annex B HTML comments.

Would a small CL removing these three stale SKIP entries from test/test262/test262.status be welcome, or should this be left to Test262 roll-watcher cleanup?

[Marja Hölttä]

I'd accept a patch just un-skipping tests. Before you do that, can you take a look why the tests are passing now - were they wrongfully skipped to start with, or did some commit afterwards make them pass (but forgot to un-skip them?

This particular case is a bit surprising, I wouldn't expect our comment parsing behavior to have changed so recently.

To view this discussion visit https://groups.google.com/d/msgid/v8-dev/4c0532f8-ef0c-40b1-a0ab-ac8b9053d8a2n%40googlegroups.com.

[Temiloluwa]

The tests now pass because the upstream Test262 tests were fixed later, not because V8’s comment parsing behavior recently changed.

The three tests had flags: [raw] but used Test262Error as the expected runtime error. Since raw tests do not get the normal harness, that caused the known upstream issue where Test262Error was not defined. Upstream Test262 later fixed this in 42d83277b7 by changing the runtime error from Test262Error to EvalError. The fix came in through the later Test262 roll 8834b4744aed04658e0b0137c96840cfb6bc2b63, which updated Test262 to dad2774b2eab2119cc8390ae65db4a5016de2dfe. I checked that 42d83277b7 is an ancestor of that rolled revision.

I did not see evidence that V8’s relevant HTML close comment parsing changed after the skips were added. V8 has had an old regression test for first-line `-->` parsing since 5628d3c482fb8c8fc989b84364ab2a31ea3cf0de, titled “Fix parsing of /**/--> on first line of input.”

So my current understanding is that the skips were added because the newly rolled Test262 tests failed due to an upstream Test262 harness/metadata issue, and they became stale after V8 later rolled in the upstream Test262 fix.

[Marja Hölttä]

That makes sense. Thanks for looking into it!

To view this discussion visit https://groups.google.com/d/msgid/v8-dev/69eef6b3-807a-4c24-a896-b78f4963e4cfn%40googlegroups.com.