Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[red-knot] Literal[True,False] normalized to builtins.bool #13178

Merged
merged 7 commits into from
Sep 1, 2024

Conversation

dylwil3
Copy link
Collaborator

@dylwil3 dylwil3 commented Aug 31, 2024

The UnionBuilder builds builtins.bool when handed Literal[True] and Literal[False].

Caveat: If the builtins module is unfindable somehow, the builder falls back to the union type of these two literals.

First task from #12694

@dylwil3
Copy link
Collaborator Author

dylwil3 commented Aug 31, 2024

Note: Attempting to call builtins_symbol_ty_by_name on a the default TestDb (without making a src directory and initializing a Program) causes a panic. Is this expected behavior? From the docstring I would've expected to just get Type::Unbound. The panic originates from Program::get(db) here:

/// Given a module name and a list of search paths in which to lookup modules,
/// attempt to resolve the module name
fn resolve_name(db: &dyn Db, name: &ModuleName) -> Option<(SearchPath, File, ModuleKind)> {
let program = Program::get(db);
let target_version = program.target_version(db);
let resolver_state = ResolverContext::new(db, target_version);

If that's unexpected I can open an issue.

Copy link
Contributor

github-actions bot commented Aug 31, 2024

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

Copy link
Contributor

@carljm carljm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!!

It's not great that we can create a TestDb without a Program which will then panic in some cases; it'd be ideal if creating a TestDb always created a fully functional db, or if the lack of a Program were handled more gracefully than a panic. Thanks for catching that! I can create an issue for it later; should be addressed separately.

crates/red_knot_python_semantic/src/types/builder.rs Outdated Show resolved Hide resolved
crates/red_knot_python_semantic/src/types/builder.rs Outdated Show resolved Hide resolved
@AlexWaygood AlexWaygood added the red-knot Multi-file analysis & type inference label Aug 31, 2024
Copy link
Contributor

@carljm carljm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great!

fn simplify(&mut self) {
if self
.elements
.is_superset(&[Type::BooleanLiteral(true), Type::BooleanLiteral(false)].into())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice approach!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be interesting to look at the generated code. into creates an OrderSet which in turn allocates.

I prefer using self.elements.contains(Type::BooleanLiteral(true) && self.elements.contains(Type::BooleanLiteral(false)), which does not depend on the compiler being able to see through that the allocation isn't necessary (which requires rather involved analysis)

crates/red_knot_python_semantic/src/types/builder.rs Outdated Show resolved Hide resolved
@carljm carljm merged commit 52d8847 into astral-sh:main Sep 1, 2024
20 checks passed
Slyces added a commit to Slyces/ruff that referenced this pull request Sep 1, 2024
@dylwil3 dylwil3 deleted the bool-true-false branch September 1, 2024 12:23
Slyces added a commit to Slyces/ruff that referenced this pull request Sep 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
red-knot Multi-file analysis & type inference
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants