dependabot[bot] 64398cee20 Bump urllib3 from 2.1.0 to 2.2.2 in /github_tools in the pip group across 1 directory (#4057)
Bumps the pip group with 1 update in the /github_tools directory:
[urllib3](https://github.com/urllib3/urllib3).

Updates `urllib3` from 2.1.0 to 2.2.2
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/urllib3/urllib3/releases">urllib3's
releases</a>.</em></p>
<blockquote>
<h2>2.2.2</h2>
<h2>🚀 urllib3 is fundraising for HTTP/2 support</h2>
<p><a
href="https://sethmlarson.dev/urllib3-is-fundraising-for-http2-support">urllib3
is raising ~$40,000 USD</a> to release HTTP/2 support and ensure
long-term sustainable maintenance of the project after a sharp decline
in financial support for 2023. If your company or organization uses
Python and would benefit from HTTP/2 support in Requests, pip, cloud
SDKs, and thousands of other projects <a
href="https://opencollective.com/urllib3">please consider contributing
financially</a> to ensure HTTP/2 support is developed sustainably and
maintained for the long-haul.</p>
<p>Thank you for your support.</p>
<h2>Changes</h2>
<ul>
<li>Added the <code>Proxy-Authorization</code> header to the list of
headers to strip from requests when redirecting to a different host. As
before, different headers can be set via
<code>Retry.remove_headers_on_redirect</code>.</li>
<li>Allowed passing negative integers as <code>amt</code> to read
methods of <code>http.client.HTTPResponse</code> as an alternative to
<code>None</code>. (<a
href="https://redirect.github.com/urllib3/urllib3/issues/3122">#3122</a>)</li>
<li>Fixed return types representing copying actions to use
<code>typing.Self</code>. (<a
href="https://redirect.github.com/urllib3/urllib3/issues/3363">#3363</a>)</li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/urllib3/urllib3/compare/2.2.1...2.2.2">https://github.com/urllib3/urllib3/compare/2.2.1...2.2.2</a></p>
<h2>2.2.1</h2>
<h2>🚀 urllib3 is fundraising for HTTP/2 support</h2>
<p><a
href="https://sethmlarson.dev/urllib3-is-fundraising-for-http2-support">urllib3
is raising ~$40,000 USD</a> to release HTTP/2 support and ensure
long-term sustainable maintenance of the project after a sharp decline
in financial support for 2023. If your company or organization uses
Python and would benefit from HTTP/2 support in Requests, pip, cloud
SDKs, and thousands of other projects <a
href="https://opencollective.com/urllib3">please consider contributing
financially</a> to ensure HTTP/2 support is developed sustainably and
maintained for the long-haul.</p>
<p>Thank you for your support.</p>
<h2>Changes</h2>
<ul>
<li>Fixed issue where <code>InsecureRequestWarning</code> was emitted
for HTTPS connections when using Emscripten. (<a
href="https://redirect.github.com/urllib3/urllib3/issues/3331">#3331</a>)</li>
<li>Fixed <code>HTTPConnectionPool.urlopen</code> to stop automatically
casting non-proxy headers to <code>HTTPHeaderDict</code>. This change
was premature as it did not apply to proxy headers and
<code>HTTPHeaderDict</code> does not handle byte header values correctly
yet. (<a
href="https://redirect.github.com/urllib3/urllib3/issues/3343">#3343</a>)</li>
<li>Changed <code>ProtocolError</code> to
<code>InvalidChunkLength</code> when response terminates before the
chunk length is sent. (<a
href="https://redirect.github.com/urllib3/urllib3/issues/2860">#2860</a>)</li>
<li>Changed <code>ProtocolError</code> to be more verbose on incomplete
reads with excess content. (<a
href="https://redirect.github.com/urllib3/urllib3/issues/3261">#3261</a>)</li>
</ul>
<h2>2.2.0</h2>
<h2>🖥️ urllib3 now works in the browser</h2>
<p>🎉 <strong>This release adds experimental support for <a
href="https://urllib3.readthedocs.io/en/stable/reference/contrib/emscripten.html">using
urllib3 in the browser with Pyodide</a>!</strong> 🎉</p>
<p>Thanks to Joe Marshall (<a
href="https://github.com/joemarshall"><code>@​joemarshall</code></a>)
for contributing this feature. This change was possible thanks to work
done in urllib3 v2.0 to detach our API from <code>http.client</code>.
Please report all bugs to the <a
href="https://github.com/urllib3/urllib3/issues">urllib3 issue
tracker</a>.</p>
<h2>🚀 urllib3 is fundraising for HTTP/2 support</h2>
<p><a
href="https://sethmlarson.dev/urllib3-is-fundraising-for-http2-support">urllib3
is raising ~$40,000 USD</a> to release HTTP/2 support and ensure
long-term sustainable maintenance of the project after a sharp decline
in financial support for 2023. If your company or organization uses
Python and would benefit from HTTP/2 support in Requests, pip, cloud
SDKs, and thousands of other projects <a
href="https://opencollective.com/urllib3">please consider contributing
financially</a> to ensure HTTP/2 support is developed sustainably and
maintained for the long-haul.</p>
<p>Thank you for your support.</p>
<h2>Changes</h2>
<ul>
<li>Added support for <a
href="https://urllib3.readthedocs.io/en/latest/reference/contrib/emscripten.html">Emscripten
and Pyodide</a>, including streaming support in cross-origin isolated
browser environments where threading is enabled. (<a
href="https://redirect.github.com/urllib3/urllib3/issues/2951">#2951</a>)</li>
<li>Added support for <code>HTTPResponse.read1()</code> method. (<a
href="https://redirect.github.com/urllib3/urllib3/issues/3186">#3186</a>)</li>
<li>Added rudimentary support for HTTP/2. (<a
href="https://redirect.github.com/urllib3/urllib3/issues/3284">#3284</a>)</li>
<li>Fixed issue where requests against urls with trailing dots were
failing due to SSL errors
when using proxy. (<a
href="https://redirect.github.com/urllib3/urllib3/issues/2244">#2244</a>)</li>
<li>Fixed <code>HTTPConnection.proxy_is_verified</code> and
<code>HTTPSConnection.proxy_is_verified</code> to be always set to a
boolean after connecting to a proxy. It could be <code>None</code> in
some cases previously. (<a
href="https://redirect.github.com/urllib3/urllib3/issues/3130">#3130</a>)</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/urllib3/urllib3/blob/main/CHANGES.rst">urllib3's
changelog</a>.</em></p>
<blockquote>
<h1>2.2.2 (2024-06-17)</h1>
<ul>
<li>Added the <code>Proxy-Authorization</code> header to the list of
headers to strip from requests when redirecting to a different host. As
before, different headers can be set via
<code>Retry.remove_headers_on_redirect</code>.</li>
<li>Allowed passing negative integers as <code>amt</code> to read
methods of <code>http.client.HTTPResponse</code> as an alternative to
<code>None</code>.
(<code>[#3122](https://github.com/urllib3/urllib3/issues/3122)
&lt;https://github.com/urllib3/urllib3/issues/3122&gt;</code>__)</li>
<li>Fixed return types representing copying actions to use
<code>typing.Self</code>.
(<code>[#3363](https://github.com/urllib3/urllib3/issues/3363)
&lt;https://github.com/urllib3/urllib3/issues/3363&gt;</code>__)</li>
</ul>
<h1>2.2.1 (2024-02-16)</h1>
<ul>
<li>Fixed issue where <code>InsecureRequestWarning</code> was emitted
for HTTPS connections when using Emscripten.
(<code>[#3331](https://github.com/urllib3/urllib3/issues/3331)
&lt;https://github.com/urllib3/urllib3/issues/3331&gt;</code>__)</li>
<li>Fixed <code>HTTPConnectionPool.urlopen</code> to stop automatically
casting non-proxy headers to <code>HTTPHeaderDict</code>. This change
was premature as it did not apply to proxy headers and
<code>HTTPHeaderDict</code> does not handle byte header values correctly
yet. (<code>[#3343](https://github.com/urllib3/urllib3/issues/3343)
&lt;https://github.com/urllib3/urllib3/issues/3343&gt;</code>__)</li>
<li>Changed <code>InvalidChunkLength</code> to
<code>ProtocolError</code> when response terminates before the chunk
length is sent.
(<code>[#2860](https://github.com/urllib3/urllib3/issues/2860)
&lt;https://github.com/urllib3/urllib3/issues/2860&gt;</code>__)</li>
<li>Changed <code>ProtocolError</code> to be more verbose on incomplete
reads with excess content.
(<code>[#3261](https://github.com/urllib3/urllib3/issues/3261)
&lt;https://github.com/urllib3/urllib3/issues/3261&gt;</code>__)</li>
</ul>
<h1>2.2.0 (2024-01-30)</h1>
<ul>
<li>Added support for <code>Emscripten and Pyodide
&lt;https://urllib3.readthedocs.io/en/latest/reference/contrib/emscripten.html&gt;</code><strong>,
including streaming support in cross-origin isolated browser
environments where threading is enabled.
(<code>[#2951](https://github.com/urllib3/urllib3/issues/2951)
&lt;https://github.com/urllib3/urllib3/issues/2951&gt;</code></strong>)</li>
<li>Added support for <code>HTTPResponse.read1()</code> method.
(<code>[#3186](https://github.com/urllib3/urllib3/issues/3186)
&lt;https://github.com/urllib3/urllib3/issues/3186&gt;</code>__)</li>
<li>Added rudimentary support for HTTP/2.
(<code>[#3284](https://github.com/urllib3/urllib3/issues/3284)
&lt;https://github.com/urllib3/urllib3/issues/3284&gt;</code>__)</li>
<li>Fixed issue where requests against urls with trailing dots were
failing due to SSL errors
when using proxy.
(<code>[#2244](https://github.com/urllib3/urllib3/issues/2244)
&lt;https://github.com/urllib3/urllib3/issues/2244&gt;</code>__)</li>
<li>Fixed <code>HTTPConnection.proxy_is_verified</code> and
<code>HTTPSConnection.proxy_is_verified</code>
to be always set to a boolean after connecting to a proxy. It could be
<code>None</code> in some cases previously.
(<code>[#3130](https://github.com/urllib3/urllib3/issues/3130)
&lt;https://github.com/urllib3/urllib3/issues/3130&gt;</code>__)</li>
<li>Fixed an issue where <code>headers</code> passed in a request with
<code>json=</code> would be mutated
(<code>[#3203](https://github.com/urllib3/urllib3/issues/3203)
&lt;https://github.com/urllib3/urllib3/issues/3203&gt;</code>__)</li>
<li>Fixed <code>HTTPSConnection.is_verified</code> to be set to
<code>False</code> when connecting
from a HTTPS proxy to an HTTP target. It was set to <code>True</code>
previously.
(<code>[#3267](https://github.com/urllib3/urllib3/issues/3267)
&lt;https://github.com/urllib3/urllib3/issues/3267&gt;</code>__)</li>
<li>Fixed handling of new error message from OpenSSL 3.2.0 when
configuring an HTTP proxy as HTTPS
(<code>[#3268](https://github.com/urllib3/urllib3/issues/3268)
&lt;https://github.com/urllib3/urllib3/issues/3268&gt;</code>__)</li>
<li>Fixed TLS 1.3 post-handshake auth when the server certificate
validation is disabled
(<code>[#3325](https://github.com/urllib3/urllib3/issues/3325)
&lt;https://github.com/urllib3/urllib3/issues/3325&gt;</code>__)</li>
<li>Note for downstream distributors: To run integration tests, you now
need to run the tests a second
time with the <code>--integration</code> pytest flag.
(<code>[#3181](https://github.com/urllib3/urllib3/issues/3181)
&lt;https://github.com/urllib3/urllib3/issues/3181&gt;</code>__)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/urllib3/urllib3/commit/27e2a5c5a7ab6a517252cc8dcef3ffa6ffb8f61a"><code>27e2a5c</code></a>
Release 2.2.2 (<a
href="https://redirect.github.com/urllib3/urllib3/issues/3406">#3406</a>)</li>
<li><a
href="https://github.com/urllib3/urllib3/commit/accff72ecc2f6cf5a76d9570198a93ac7c90270e"><code>accff72</code></a>
Merge pull request from GHSA-34jh-p97f-mpxf</li>
<li><a
href="https://github.com/urllib3/urllib3/commit/34be4a57e59eb7365bcc37d52e9f8271b5b8d0d3"><code>34be4a5</code></a>
Pin CFFI to a new release candidate instead of a Git commit (<a
href="https://redirect.github.com/urllib3/urllib3/issues/3398">#3398</a>)</li>
<li><a
href="https://github.com/urllib3/urllib3/commit/da410581b6b3df73da976b5ce5eb20a4bd030437"><code>da41058</code></a>
Bump browser-actions/setup-chrome from 1.6.0 to 1.7.1 (<a
href="https://redirect.github.com/urllib3/urllib3/issues/3399">#3399</a>)</li>
<li><a
href="https://github.com/urllib3/urllib3/commit/b07a669bd970d69847801148286b726f0570b625"><code>b07a669</code></a>
Bump github/codeql-action from 2.13.4 to 3.25.6 (<a
href="https://redirect.github.com/urllib3/urllib3/issues/3396">#3396</a>)</li>
<li><a
href="https://github.com/urllib3/urllib3/commit/b8589ec9f8c4da91511e601b632ac06af7e7c10e"><code>b8589ec</code></a>
Measure coverage with v4 of artifact actions (<a
href="https://redirect.github.com/urllib3/urllib3/issues/3394">#3394</a>)</li>
<li><a
href="https://github.com/urllib3/urllib3/commit/f3bdc5585111429e22c81b5fb26c3ec164d98b81"><code>f3bdc55</code></a>
Allow triggering CI manually (<a
href="https://redirect.github.com/urllib3/urllib3/issues/3391">#3391</a>)</li>
<li><a
href="https://github.com/urllib3/urllib3/commit/52392654b30183129cf3ec06010306f517d9c146"><code>5239265</code></a>
Fix HTTP version in debug log (<a
href="https://redirect.github.com/urllib3/urllib3/issues/3316">#3316</a>)</li>
<li><a
href="https://github.com/urllib3/urllib3/commit/b34619f94ece0c40e691a5aaf1304953d88089de"><code>b34619f</code></a>
Bump actions/checkout to 4.1.4 (<a
href="https://redirect.github.com/urllib3/urllib3/issues/3387">#3387</a>)</li>
<li><a
href="https://github.com/urllib3/urllib3/commit/9961d14de7c920091d42d42ed76d5d479b80064d"><code>9961d14</code></a>
Bump browser-actions/setup-chrome from 1.5.0 to 1.6.0 (<a
href="https://redirect.github.com/urllib3/urllib3/issues/3386">#3386</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/urllib3/urllib3/compare/2.1.0...2.2.2">compare
view</a></li>
</ul>
</details>
<br />


[![Dependabot compatibility
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=urllib3&package-manager=pip&previous-version=2.1.0&new-version=2.2.2)](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>
2024-06-17 23:03:45 +00:00
2024-06-07 18:45:41 +00:00
2020-06-16 17:58:17 -07:00
2024-04-24 23:15:56 +00:00

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.

Quicksort code in Carbon. Follow the link to read more.

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:

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. There is no working compiler or toolchain. You can see the demo interpreter for Carbon on compiler-explorer.com.

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:

A snippet of C++ code. Follow the link to read it.

corresponds to this Carbon code:

A snippet of converted Carbon code. Follow the link to read it.

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:

A snippet of mixed Carbon and C++ code. Follow the link to read it.

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, you can use the Carbon explorer to interpret Carbon code and print its output. You can try it out immediately at compiler-explorer.com.

Because Carbon is an early, experimental project we don't yet have releases you can download and try out locally, you'll instead need to build any tools yourself from source. We expect to have packaged releases you can try out when we reach our 0.1 milestone.

If you do want to try out Carbon locally, you'll need to install our build dependencies (Bazel, 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 \
  bazel \
  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 build and run the explorer:

# Build and run the explorer.
$ bazel run //explorer -- ./explorer/testdata/print/format_only.carbon

And 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.
$ bazel run //toolchain/driver:carbon -- help

For complete instructions, including installing dependencies on various different platforms, see our contribution tools documentation.

Learn more about the Carbon project:

Conference talks

Past Carbon focused talks from the community:

2022

2023

2024

Upcoming

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.

Contributing

You can also directly:

You can check out some "good first issues", or join the #contributing-help channel on Discord. See our full CONTRIBUTING documentation for more details.

S
Description
Carbon Language's main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)
Readme Apache-2.0
2.7 GiB
Languages
C++ 89.5%
Starlark 4.4%
Python 3.6%
Carbon 1.5%
JavaScript 0.4%
Other 0.3%