Bumps the npm_and_yarn group with 1 update in the /utils/vscode directory: [esbuild](https://github.com/evanw/esbuild). Updates `esbuild` from 0.24.0 to 0.25.0 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/evanw/esbuild/releases">esbuild's releases</a>.</em></p> <blockquote> <h2>v0.25.0</h2> <p><strong>This release deliberately contains backwards-incompatible changes.</strong> To avoid automatically picking up releases like this, you should either be pinning the exact version of <code>esbuild</code> in your <code>package.json</code> file (recommended) or be using a version range syntax that only accepts patch upgrades such as <code>^0.24.0</code> or <code>~0.24.0</code>. See npm's documentation about <a href="https://docs.npmjs.com/cli/v6/using-npm/semver/">semver</a> for more information.</p> <ul> <li> <p>Restrict access to esbuild's development server (<a href="https://github.com/evanw/esbuild/security/advisories/GHSA-67mh-4wv8-2f99">GHSA-67mh-4wv8-2f99</a>)</p> <p>This change addresses esbuild's first security vulnerability report. Previously esbuild set the <code>Access-Control-Allow-Origin</code> header to <code>*</code> to allow esbuild's development server to be flexible in how it's used for development. However, this allows the websites you visit to make HTTP requests to esbuild's local development server, which gives read-only access to your source code if the website were to fetch your source code's specific URL. You can read more information in <a href="https://github.com/evanw/esbuild/security/advisories/GHSA-67mh-4wv8-2f99">the report</a>.</p> <p>Starting with this release, <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS">CORS</a> will now be disabled, and requests will now be denied if the host does not match the one provided to <code>--serve=</code>. The default host is <code>0.0.0.0</code>, which refers to all of the IP addresses that represent the local machine (e.g. both <code>127.0.0.1</code> and <code>192.168.0.1</code>). If you want to customize anything about esbuild's development server, you can <a href="https://esbuild.github.io/api/#serve-proxy">put a proxy in front of esbuild</a> and modify the incoming and/or outgoing requests.</p> <p>In addition, the <code>serve()</code> API call has been changed to return an array of <code>hosts</code> instead of a single <code>host</code> string. This makes it possible to determine all of the hosts that esbuild's development server will accept.</p> <p>Thanks to <a href="https://github.com/sapphi-red"><code>@sapphi-red</code></a> for reporting this issue.</p> </li> <li> <p>Delete output files when a build fails in watch mode (<a href="https://redirect.github.com/evanw/esbuild/issues/3643">#3643</a>)</p> <p>It has been requested for esbuild to delete files when a build fails in watch mode. Previously esbuild left the old files in place, which could cause people to not immediately realize that the most recent build failed. With this release, esbuild will now delete all output files if a rebuild fails. Fixing the build error and triggering another rebuild will restore all output files again.</p> </li> <li> <p>Fix correctness issues with the CSS nesting transform (<a href="https://redirect.github.com/evanw/esbuild/issues/3620">#3620</a>, <a href="https://redirect.github.com/evanw/esbuild/issues/3877">#3877</a>, <a href="https://redirect.github.com/evanw/esbuild/issues/3933">#3933</a>, <a href="https://redirect.github.com/evanw/esbuild/issues/3997">#3997</a>, <a href="https://redirect.github.com/evanw/esbuild/issues/4005">#4005</a>, <a href="https://redirect.github.com/evanw/esbuild/pull/4037">#4037</a>, <a href="https://redirect.github.com/evanw/esbuild/pull/4038">#4038</a>)</p> <p>This release fixes the following problems:</p> <ul> <li> <p>Naive expansion of CSS nesting can result in an exponential blow-up of generated CSS if each nesting level has multiple selectors. Previously esbuild sometimes collapsed individual nesting levels using <code>:is()</code> to limit expansion. However, this collapsing wasn't correct in some cases, so it has been removed to fix correctness issues.</p> <pre lang="css"><code>/* Original code */ .parent { > .a, > .b1 > .b2 { color: red; } } <p>/* Old output (with --supported:nesting=false) */<br /> .parent > :is(.a, .b1 > .b2) {<br /> color: red;<br /> }</p> <p>/* New output (with --supported:nesting=false) */<br /> .parent > .a,<br /> .parent > .b1 > .b2 {<br /> color: red;<br /> }<br /> </code></pre></p> <p>Thanks to <a href="https://github.com/tim-we"><code>@tim-we</code></a> for working on a fix.</p> </li> <li> <p>The <code>&</code> CSS nesting selector can be repeated multiple times to increase CSS specificity. Previously esbuild ignored this possibility and incorrectly considered <code>&&</code> to have the same specificity as <code>&</code>. With this release, this should now work correctly:</p> <pre lang="css"><code>/* Original code (color should be red) */ </code></pre> </li> </ul> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/evanw/esbuild/blob/main/CHANGELOG-2024.md">esbuild's changelog</a>.</em></p> <blockquote> <h1>Changelog: 2024</h1> <p>This changelog documents all esbuild versions published in the year 2024 (versions 0.19.12 through 0.24.2).</p> <h2>0.24.2</h2> <ul> <li> <p>Fix regression with <code>--define</code> and <code>import.meta</code> (<a href="https://redirect.github.com/evanw/esbuild/issues/4010">#4010</a>, <a href="https://redirect.github.com/evanw/esbuild/issues/4012">#4012</a>, <a href="https://redirect.github.com/evanw/esbuild/pull/4013">#4013</a>)</p> <p>The previous change in version 0.24.1 to use a more expression-like parser for <code>define</code> values to allow quoted property names introduced a regression that removed the ability to use <code>--define:import.meta=...</code>. Even though <code>import</code> is normally a keyword that can't be used as an identifier, ES modules special-case the <code>import.meta</code> expression to behave like an identifier anyway. This change fixes the regression.</p> <p>This fix was contributed by <a href="https://github.com/sapphi-red"><code>@sapphi-red</code></a>.</p> </li> </ul> <h2>0.24.1</h2> <ul> <li> <p>Allow <code>es2024</code> as a target in <code>tsconfig.json</code> (<a href="https://redirect.github.com/evanw/esbuild/issues/4004">#4004</a>)</p> <p>TypeScript recently <a href="https://devblogs.microsoft.com/typescript/announcing-typescript-5-7/#support-for---target-es2024-and---lib-es2024">added <code>es2024</code></a> as a compilation target, so esbuild now supports this in the <code>target</code> field of <code>tsconfig.json</code> files, such as in the following configuration file:</p> <pre lang="json"><code>{ "compilerOptions": { "target": "ES2024" } } </code></pre> <p>As a reminder, the only thing that esbuild uses this field for is determining whether or not to use legacy TypeScript behavior for class fields. You can read more in <a href="https://esbuild.github.io/content-types/#tsconfig-json">the documentation</a>.</p> <p>This fix was contributed by <a href="https://github.com/billyjanitsch"><code>@billyjanitsch</code></a>.</p> </li> <li> <p>Allow automatic semicolon insertion after <code>get</code>/<code>set</code></p> <p>This change fixes a grammar bug in the parser that incorrectly treated the following code as a syntax error:</p> <pre lang="ts"><code>class Foo { get *x() {} set *y() {} } </code></pre> <p>The above code will be considered valid starting with this release. This change to esbuild follows a <a href="https://redirect.github.com/microsoft/TypeScript/pull/60225">similar change to TypeScript</a> which will allow this syntax starting with TypeScript 5.7.</p> </li> <li> <p>Allow quoted property names in <code>--define</code> and <code>--pure</code> (<a href="https://redirect.github.com/evanw/esbuild/issues/4008">#4008</a>)</p> <p>The <code>define</code> and <code>pure</code> API options now accept identifier expressions containing quoted property names. Previously all identifiers in the identifier expression had to be bare identifiers. This change now makes <code>--define</code> and <code>--pure</code> consistent with <code>--global-name</code>, which already supported quoted property names. For example, the following is now possible:</p> <pre lang="js"><code></code></pre> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/evanw/esbuild/commit/e9174d671b1882758cd32ac5e146200f5bee3e45"><code>e9174d6</code></a> publish 0.25.0 to npm</li> <li><a href="https://github.com/evanw/esbuild/commit/c27dbebb9e7a55dd9a084dd151dddd840787490e"><code>c27dbeb</code></a> fix <code>hosts</code> in <code>plugin-tests.js</code></li> <li><a href="https://github.com/evanw/esbuild/commit/6794f602a453cf0255bcae245871de120a89a559"><code>6794f60</code></a> fix <code>hosts</code> in <code>node-unref-tests.js</code></li> <li><a href="https://github.com/evanw/esbuild/commit/de85afd65edec9ebc44a11e245fd9e9a2e99760d"><code>de85afd</code></a> Merge commit from fork</li> <li><a href="https://github.com/evanw/esbuild/commit/da1de1bf77a65f06654b49878d9ec4747ddaa21f"><code>da1de1b</code></a> fix <a href="https://redirect.github.com/evanw/esbuild/issues/4065">#4065</a>: bitwise operators can return bigints</li> <li><a href="https://github.com/evanw/esbuild/commit/f4e9d19fb20095a98bf40634f0380f6a16be91e7"><code>f4e9d19</code></a> switch case liveness: <code>default</code> is always last</li> <li><a href="https://github.com/evanw/esbuild/commit/7aa47c3e778ea04849f97f18dd9959df88fa0886"><code>7aa47c3</code></a> fix <a href="https://redirect.github.com/evanw/esbuild/issues/4028">#4028</a>: minify live/dead <code>switch</code> cases better</li> <li><a href="https://github.com/evanw/esbuild/commit/22ecd306190b8971ec4474b5485266c20350e266"><code>22ecd30</code></a> minify: more constant folding for strict equality</li> <li><a href="https://github.com/evanw/esbuild/commit/4cdf03c03697128044fa8fb76e5c478e9765b353"><code>4cdf03c</code></a> fix <a href="https://redirect.github.com/evanw/esbuild/issues/4053">#4053</a>: reordering of <code>.tsx</code> in <code>node_modules</code></li> <li><a href="https://github.com/evanw/esbuild/commit/dc719775b7140120916bd9e6777ca1cb8a1cdc0e"><code>dc71977</code></a> fix <a href="https://redirect.github.com/evanw/esbuild/issues/3692">#3692</a>: <code>0</code> now picks a random ephemeral port</li> <li>Additional commits viewable in <a href="https://github.com/evanw/esbuild/compare/v0.24.0...v0.25.0">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself) - `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself) - `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself) - `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency - `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/carbon-language/carbon-lang/network/alerts). </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Carbon Language:
An experimental successor to C++
Why? | Goals | Status | Getting started | Join us
See our announcement video from CppNorth. Note that Carbon is not ready for use.
Fast and works with C++
- Performance matching C++ using LLVM, with low-level access to bits and addresses
- Interoperate with your existing C++ code, from inheritance to templates
- Fast and scalable builds that work with your existing C++ build systems
Modern and evolving
- Solid language foundations that are easy to learn, especially if you have used C++
- Easy, tool-based upgrades between Carbon versions
- Safer fundamentals, and an incremental path towards a memory-safe subset
Welcoming open-source community
- Clear goals and priorities with robust governance
- Community that works to be welcoming, inclusive, and friendly
- Batteries-included approach: compiler, libraries, docs, tools, package manager, and more
Why build Carbon?
C++ remains the dominant programming language for performance-critical software, with massive and growing codebases and investments. However, it is struggling to improve and meet developers' needs, as outlined above, in no small part due to accumulating decades of technical debt. Incrementally improving C++ is extremely difficult, both due to the technical debt itself and challenges with its evolution process. The best way to address these problems is to avoid inheriting the legacy of C or C++ directly, and instead start with solid language foundations like modern generics system, modular code organization, and consistent, simple syntax.
Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should. Unfortunately, the designs of these languages present significant barriers to adoption and migration from C++. These barriers range from changes in the idiomatic design of software to performance overhead.
Carbon is fundamentally a successor language approach, rather than an attempt to incrementally evolve C++. It is designed around interoperability with C++ as well as large-scale adoption and migration for existing C++ codebases and developers. A successor language for C++ requires:
- Performance matching C++, an essential property for our developers.
- Seamless, bidirectional interoperability with C++, such that a library anywhere in an existing C++ stack can adopt Carbon without porting the rest.
- A gentle learning curve with reasonable familiarity for C++ developers.
- Comparable expressivity and support for existing software's design and architecture.
- Scalable migration, with some level of source-to-source translation for idiomatic C++ code.
With this approach, we can build on top of C++'s existing ecosystem, and bring along existing investments, codebases, and developer populations. There are a few languages that have followed this model for other ecosystems, and Carbon aims to fill an analogous role for C++:
- JavaScript → TypeScript
- Java → Kotlin
- C++ → Carbon
Language Goals
We are designing Carbon to support:
- Performance-critical software
- Software and language evolution
- Code that is easy to read, understand, and write
- Practical safety and testing mechanisms
- Fast and scalable development
- Modern OS platforms, hardware architectures, and environments
- Interoperability with and migration from existing C++ code
While many languages share subsets of these goals, what distinguishes Carbon is their combination.
We also have explicit non-goals for Carbon, notably including:
- A stable application binary interface (ABI) for the entire language and library
- Perfect backwards or forwards compatibility
Our detailed goals document fleshes out these ideas and provides a deeper view into our goals for the Carbon project and language.
Project status
Carbon Language is currently an experimental project. You can see the demo interpreter for Carbon on compiler-explorer.com. We are also hard at work on a toolchain implementation with compiler and linker.
We want to better understand whether we can build a language that meets our successor language criteria, and whether the resulting language can gather a critical mass of interest within the larger C++ industry and community.
Currently, we have fleshed out several core aspects of both Carbon the project and the language:
- The strategy of the Carbon Language and project.
- An open-source project structure, governance model, and evolution process.
- Critical and foundational aspects of the language design informed by our
experience with C++ and the most difficult challenges we anticipate. This
includes designs for:
- Generics
- Class types
- Inheritance
- Operator overloading
- Lexical and syntactic structure
- Code organization and modular structure
- A prototype interpreter demo that can both run isolated examples and gives a detailed analysis of the specific semantic model and abstract machine of Carbon. We call this the Carbon Explorer.
- An under-development compiler and toolchain that will compile Carbon (and eventually C++ code as well) into standard executable code. This is where most of our current implementation efforts are directed.
If you're interested in contributing, we're currently focused on developing the Carbon toolchain until it can support Carbon ↔ C++ interop. Beyond that, we plan to continue developing the design and toolchain until we can ship the 0.1 language and support evaluating Carbon in more detail.
You can see our full roadmap for more details.
Carbon and C++
If you're already a C++ developer, Carbon should have a gentle learning curve. It is built out of a consistent set of language constructs that should feel familiar and be easy to read and understand.
C++ code like this:
corresponds to this Carbon code:
You can call Carbon from C++ without overhead and the other way around. This means you migrate a single C++ library to Carbon within an application, or write new Carbon on top of your existing C++ investment. For example:
Read more about C++ interop in Carbon.
Beyond interoperability between Carbon and C++, we're also planning to support migration tools that will mechanically translate idiomatic C++ code into Carbon code to help you switch an existing C++ codebase to Carbon.
Generics
Carbon provides a modern generics system with checked definitions, while still supporting opt-in templates for seamless C++ interop. Checked generics provide several advantages compared to C++ templates:
- Generic definitions are fully type-checked, removing the need to
instantiate to check for errors and giving greater confidence in code.
- Avoids the compile-time cost of re-checking the definition for every instantiation.
- When using a definition-checked generic, usage error messages are clearer, directly showing which requirements are not met.
- Enables automatic, opt-in type erasure and dynamic dispatch without a separate implementation. This can reduce the binary size and enables constructs like heterogeneous containers.
- Strong, checked interfaces mean fewer accidental dependencies on implementation details and a clearer contract for consumers.
Without sacrificing these advantages, Carbon generics support specialization, ensuring it can fully address performance-critical use cases of C++ templates. For more details about Carbon's generics, see their design.
In addition to easy and powerful interop with C++, Carbon templates can be constrained and incrementally migrated to checked generics at a fine granularity and with a smooth evolutionary path.
Memory safety
Safety, and especially memory safety, remains a key challenge for C++ and something a successor language needs to address. Our initial priority and focus is on immediately addressing important, low-hanging fruit in the safety space:
- Tracking uninitialized states better, increased enforcement of initialization, and systematically providing hardening against initialization bugs when desired.
- Designing fundamental APIs and idioms to support dynamic bounds checks in debug and hardened builds.
- Having a default debug build mode that is both cheaper and more comprehensive than existing C++ build modes even when combined with Address Sanitizer.
Once we can migrate code into Carbon, we will have a simplified language with room in the design space to add any necessary annotations or features, and infrastructure like generics to support safer design patterns. Longer term, we will build on this to introduce a safe Carbon subset. This will be a large and complex undertaking, and won't be in the 0.1 design. Meanwhile, we are closely watching and learning from efforts to add memory safe semantics onto C++ such as Rust-inspired lifetime annotations.
Getting started
To try out Carbon immediately in your browser, you can use the demo interpreter for Carbon on: carbon.compiler-explorer.com.
We are developing a traditional toolchain for Carbon that can compile and link
programs. However, Carbon is still an early, experimental project, and so we
only have very experimental nightly releases of the Carbon toolchain available
to download, and only on limited platforms. If you are using a recent Ubuntu
Linux or similar (Debian, WSL, etc.), you can try these out by going to our
releases page and
download the latest nightly toolchain tar file:
carbon_toolchain-0.0.0-0.nightly.YYYY.MM.DD.tar.gz. Then you can try it out:
# A variable with the nightly version from yesterday:
VERSION="$(date -d yesterday +0.0.0-0.nightly.%Y.%m.%d)"
# Get the release
wget https://github.com/carbon-language/carbon-lang/releases/download/v${VERSION}/carbon_toolchain-${VERSION}.tar.gz
# Unpack the toolchain:
tar -xvf carbon_toolchain-${VERSION}.tar.gz
# Create a simple Carbon source file:
echo "import Core library \"io\"; fn Run() { Core.Print(42); }" > forty_two.carbon
# Compile to an object file:
./carbon_toolchain-${VERSION}/bin/carbon compile \
--output=forty_two.o forty_two.carbon
# Install minimal system libraries used for linking. Note that installing `gcc`
# or `g++` for compiling C/C++ code with GCC will also be sufficient, these are
# just the specific system libraries Carbon linking still uses.
sudo apt install libgcc-11-dev
# Link to an executable:
./carbon_toolchain-${VERSION}/bin/carbon link \
--output=forty_two forty_two.o
# Run it:
./forty_two
As a reminder, the toolchain is still very early and many things don't yet work. Please hold off on filing lots of bugs: we know many parts of this don't work yet or may not work on all systems. We expect to have releases that are much more robust and reliable that you can try out when we reach our 0.1 milestone.
If you want to build Carbon's toolchain yourself or are thinking about contributing fixes or improvements to Carbon, you'll need to install our build dependencies (Clang, LLD, libc++) and check out the Carbon repository. For example, on Debian or Ubuntu:
# Update apt.
sudo apt update
# Install tools.
sudo apt install \
clang \
libc++-dev \
libc++abi-dev \
lld
# Download Carbon's code.
$ git clone https://github.com/carbon-language/carbon-lang
$ cd carbon-lang
Then you can try out our toolchain which has a very early-stage compiler for Carbon:
# Build and run the toolchain's help to get documentation on the command line.
$ ./scripts/run_bazelisk.py run //toolchain -- help
For complete instructions, including installing dependencies on various different platforms, see our contribution tools documentation.
Learn more about the Carbon project:
Conference talks
Carbon focused talks from the community:
2024
- Generic implementation strategies in Carbon and Clang, LLVM Developers' Meeting (video, slides)
- The Carbon Language: Road to 0.1, NDC {TechTown} (video, slides)
- How designing Carbon with C++ interop taught me about C++ variadics and overloads, CppNorth (video, slides)
- Generic Arity: Definition-Checked Variadics in Carbon, C++Now (video, slides)
- Carbon: An experiment in different tradeoffs, panel session, EuroLLVM (video, slides)
- Carbon's high-level semantic IR lightning talk, EuroLLVM (video)
2023
- Carbon’s Successor Strategy: From C++ interop to memory safety, C++Now (video, slides)
- Definition-Checked Generics, C++Now
- Modernizing Compiler Design for Carbon’s Toolchain, C++Now (video, slides)
2022
- Carbon Language: Syntax and trade-offs, Core C++ (video, slides)
- Carbon Language: An experimental successor to C++, CppNorth (video, slides)
Join us
We'd love to have folks join us and contribute to the project. Carbon is committed to a welcoming and inclusive environment where everyone can contribute.
- Most of Carbon's design discussions occur on Discord.
- To watch for major release announcements, subscribe to our Carbon release post on GitHub and star carbon-lang.
- See our code of conduct and contributing guidelines for information about the Carbon development community.
Contributing
You can also directly:
- Contribute to the language design: feedback on design, new design proposal
- Contribute to the language implementation
- Carbon Toolchain, and project infrastructure
You can check out some
"good first issues",
or join the #contributing-help channel on
Discord. See our full
CONTRIBUTING documentation for more details.
