5 Commits

Author	SHA1	Message	Date
Alex Waygood	0cc3a775cd	Tell Claude to prefer using #[expect()] over #[allow()] where possible (#22617)	2026-01-16 12:36:32 +00:00
Charlie Marsh	7bacca9b62	Use prek in documentation and CI (#22505) ... ## Summary AFAIK, many of us on the team are using prek now. It seems appropriate to modify the docs to formalize it.	2026-01-11 14:17:10 -05:00
Charlie Marsh	8e29be9c1c	Add let chains preference to development guidelines (#22497)	2026-01-10 12:29:07 -05:00
Charlie Marsh	60f7ec90ef	Add a fast-test profile (#22382) ... ## Summary We use this profile in uv to create success, as an optimization for the iterative test loop. We include `opt-level=1` because it ends up being "worth it" for testing (empirically), even though it means the build is actually a big slower than `dev` (if you remove `opt-level=1`, clean compile is about 22% faster than `dev`). Here are some benchmarks I generated with Claude -- the main motivator here is the incremental testing for `ty_python_semantic` which is 2.4x faster: ### `ty_python_semantic` Full test suite (471 tests): | Scenario | dev | fast-test | Improvement | |-------------|-------|------------|-------------| | Clean | 53s | 49s | 8% faster | | Incremental | 17.8s | 6.8s | 2.4x faster | Single test: | Scenario | dev | fast-test | Improvement | |-------------|-------|------------|-------------| | Clean | 42.5s | 55.3s | 30% slower | | Incremental | 6.5s | 6.1s | ~same | ### `ruff_linter` Full test suite (2622 tests): | Scenario | dev | fast-test | Improvement | |-------------|-------|------------|-------------| | Clean | 31s | 41s | 32% slower | | Incremental | 11.9s | 10.5s | 12% faster | Single test: | Scenario | dev | fast-test | Improvement | |-------------|------|------------|-------------| | Clean | 26s | 36.5s | 40% slower | | Incremental | 4.5s | 5.5s | 22% slower |	2026-01-05 19:35:43 +00:00
Charlie Marsh	11b551c2be	Add a CLAUDE.md (#22370) ... ## Summary This is a starting point based on my own experiments. Feedback and changes welcome -- I think we should iterate on this a lot as we go.	2026-01-04 15:00:31 -05:00