Files

Chris Krycho c4d628cc4c red-knot: infer string literal types (#13113 )

## Summary

Introduce a `StringLiteralType` with corresponding `Display` type and a
relatively basic test that the resulting representation is as expected.

Note: we currently always allocate for `StringLiteral` types. This may
end up being a perf issue later, at which point we may want to look at
other ways of representing `value` here, i.e. with some kind of smarter
string structure which can reuse types. That is most likely to show up
with e.g. concatenation.

Contributes to #12701.

## Test Plan

Added a test for individual strings with both single and double quotes
as well as concatenated strings with both forms.

2024-08-26 11:42:34 -07:00

src

red-knot: infer string literal types (#13113 )

2024-08-26 11:42:34 -07:00

vendor/typeshed

Sync vendored typeshed stubs (#12899 )

2024-08-14 18:11:23 -07:00

build.rs

[red-knot] Merge the semantic and module-resolver crates (#12751 )

2024-08-08 15:34:11 +01:00

Cargo.toml

Added bytes type and some inference (#13061 )

2024-08-22 13:27:15 -07:00

README.md

[red-knot] Merge the semantic and module-resolver crates (#12751 )

2024-08-08 15:34:11 +01:00

README.md

Red Knot

Semantic analysis for the red-knot project.

Vendored types for the stdlib

This crate vendors typeshed's stubs for the standard library. The vendored stubs can be found in crates/red_knot_python_semantic/vendor/typeshed. The file crates/red_knot_python_semantic/vendor/typeshed/source_commit.txt tells you the typeshed commit that our vendored stdlib stubs currently correspond to.

The typeshed stubs are updated every two weeks via an automated PR using the sync_typeshed.yaml workflow in the .github/workflows directory. This workflow can also be triggered at any time via workflow dispatch.