carbon-language/carbon-lang

Description of the bug: Testcase let {b}; builds a malformed parse tree, resulting in a crash. It also doesn't produce any diagnostic message, despite being syntactically invalid. What did you do, or what's a simple way to reproduce the bug? let {b}; What did you expect to happen? A diagnostic should be produced for the invalid pattern. A well-formed parse tree (including nodes marked as invalid or InvalidParse nodes as appropriate) should be produced. What actually happened? An IdentifierNameExpr parse node was produced for the b token, which doesn't match the expected shape for a StructPattern node. This leads to a CHECK-failure since the parse tree is malformed: 3. Filename: - 4. Parser stack: cursor position_ @ 1:12: token token8 : FileEnd #0 0x0000556bab27561b llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) external/+llvm_project+llvm-project/llvm/lib/Support/Unix/Signals.inc:935:8 #1 0x0000556bab275ba8 PrintStackTraceSignalHandler(void*) external/+llvm_pr

Proposal: community-facing landing page for Carbon Language Summary This issue proposes the creation of a dedicated landing page for the Carbon Language project, aimed at making the repository more accessible and welcoming to new and existing contributors. The current GitHub repository is the primary entry point for the community, but it assumes significant prior knowledge and does not surface community norms, onboarding steps, or contributor resources in a visible or inviting way. A standalone landing page would lower the barrier to entry and reflect the inclusive, open culture we are working to build. Timing With a first release potentially happening later this year, having a welcoming landing page in place beforehand is important. A first release is likely to bring a significant influx of new visitors and potential contributors — many of whom will have no prior context about the project's community norms or how to get involved. First impressions matter, and the current repository

The Carbon toolchain is missing support for struct patterns, as documented here. As "first issues" go, this is probably fairly complex, but there are a couple ways of breaking it down to make it more manageable: You can split it up by compilation phase, implementing parsing, then checking, then lowering in separate PRs (I don't think this will need changes to lexing). You can split it up into sub-features: the core {.foo = foo: Foo, .bar = bar: Bar} syntax, and then the {foo: Foo, bar: Bar} shorthand and the trailing , _ syntax. I'd recommend doing both: have each PR focus on a single phase of a single feature, and probably do all three phases of the core feature before starting on the shorthand or trailing , _ syntaxes. Be sure to take a look at the toolchain docs, especially the one about pattern matching, if you're not already familiar with them. The existing support for tuple patterns should also be a useful point of reference, because the two features have a lot in common.