Commit Graph
5 Commits
Author SHA1 Message Date
Chandler Carruth b344f3af12 Switch a few stragglers to uv and update python to 3.12 (#7296)
Not sure how these got missed when moving other things to `uv`, but this
should clean them up.

The bump to Python 3.12 is so that we can use `@override` with the
simple import from `typing`. This is needed by the newest versions of
`ty` to do type checking. Added the relevant `@override` annotations.

Assisted-by: Antigravity with Gemini
2026-06-03 05:34:44 +00:00
Chandler Carruth 3ef128ac91 Switch to Astral Python tools: ruff and ty (#7243)
This replaces black, flake8, and mypy with the more modern and efficient
tools `ruff` and `ty` from Astral.

Assisted-by: Antigravity with Gemini
2026-05-29 22:56:27 +00:00
Jon Ross-Perkins 4b076291c9 pre-commit autoupdate (#6845)
Assisted-by: Google Antigravity with Gemini
2026-03-09 15:49:11 +00:00
Chandler Carruth 529dcfcfec Test that the built toolchain works with the example Bazel project (#6653)
I wasn't sure I'd be able to really test this code path, but then
I remembered that Bazel has a whole platform for running Bazel from
within an integration test, and it turns out to work brilliantly. It
even lets us point the child Bazel invocations to the just-built
toolchain.

This should both give us confidence that we don't accidentally hit
a Bazel incompatibility with the example project, and it should ensure
that if something about the installed toolchain would stop being
compatible with building via Bazel we'll catch it early.

The tests are integration tests and so a bit slow: 15s or so. But
`//examples/...` is already pretty expensive and no other testing
patterns are impacted.
2026-01-29 02:14:17 +00:00
b0ffed7c3e Make the Carbon toolchain a viable Bazel module exposing cc_toolchains (#6652)
This let's you point Bazel at an installed toolchain or download one of
our release archives. When you do, it will configure itself as a C++
Bazel toolchain. This toolchain works reasonably well, but doesn't cache
the C++ runtimes, and so linking is inefficient. The next step will be
to pivot the runtimes from the implicitly on-demand (which can't cache
when using a sandboxed build system like Bazel) to _explicit_ on-demand
runtimes directly with Bazel support.

I've included an example Bazel project that uses this and provides a
bunch of documentation and an example script that should let folks try
this out easily.

---------

Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: David Blaikie <dblaikie@gmail.com>
2026-01-28 02:45:19 +00:00