[refurb] Add coverage for using set(...) in single-item-membership-test (FURB171)

[naslundx]

Summary

Adds coverage of using set(...) in addition to `{...} in SingleItemMembershipTest.

Fixes #15792

Test Plan

Updated unit test and snapshot.
Steps to reproduce are in the issue linked above.

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[naslundx]

Ah, I see, it doesn't work if the single argument to set() is an enum, for example. :(

[AlexWaygood]

Thanks! However, I think it would be incorrect for this rule to trigger on set(1), since that doesn't create a set with a single member at runtime. It raises an exception.

[AlexWaygood]

hmm, this fails at runtime:

>>> set(1)
Traceback (most recent call last):
  File "<python-input-0>", line 1, in <module>
    set(1)
    ~~~^^^
TypeError: 'int' object is not iterable

[AlexWaygood]

this also fails at runtime:

>>> set(1, 2)
Traceback (most recent call last):
  File "<python-input-1>", line 1, in <module>
    set(1, 2)
    ~~~^^^^^^
TypeError: set expected at most 1 argument, got 2

[AlexWaygood]

To clarify, @naslundx, all of these succeed at runtime, and I'd be okay with adding support for these to FURB171!

set([1])
set((1,))
set({1})

You'd need to check that the object being passed to the set() call is an Expr::List, Expr::Tuple or Expr::Set that has exactly one member in its elts field.

[InSyncWithFoo]

You'd need to check that the object [...] has exactly one member in its elts field.

Additionally, that element should be literal/hashable, so that errors like this one are not masked:

if a in set([{}]): ...  # TypeError: unhashable type: 'dict'
if a == {}: ...         # No errors

[dylwil3]

You'd need to check that the object [...] has exactly one member in its elts field.

Additionally, that element should be literal/hashable, so that errors like this one are not masked:

if a in set([{}]): ...  # TypeError: unhashable type: 'dict'
if a == {}: ...         # No errors

I think we should open a separate issue about this because that behavior is already present in the current scope of the rule:

1 in {set()} # TypeError: unhashable type: 'set'
1 == set() # No errors

[tdulcet]

Maybe check for frozenset as well:

frozenset([1])
frozenset((1,))
frozenset({1})

[naslundx]

I did not see the updated comments on this PR - I will bring it back up to speed. Thanks for comments!

[dylwil3]

Looking good, thank you! Let's add a little more test coverage, and handle the case where someone is shadowing or explicitly importing the builtin.

[dylwil3]

You should use this method to make sure the function matches the builtin that you expect:

ruff/crates/ruff_python_semantic/src/model.rs

Lines 316 to 319 in d94a78a

	/// Return `true` if `expr` is a reference to `builtins.$target`,
	/// i.e. either `object` (where `object` is not overridden in the global scope),
	/// or `builtins.object` (where `builtins` is imported as a module at the top level)
	pub fn match_builtin_expr(&self, expr: &Expr, symbol: &str) -> bool {

[naslundx]

Did not know about this, that's great!

[dylwil3]

Could you add some examples with nested calls to set/frozenset since your implementation is recursive? Like

set(set([1]))

Also a few non-examples, like:

set(1,) # this is a TypeError so we shouldn't do anything with it
set(1,2) # this is also a TypeError
set((x for x in range(2))) # this is legal but not one element

[MichaReiser]

Thanks @naslundx for working on this. I'll close this PR because it has become stale. For anyone interested, feel free to open a new PR implementing this change, incorporating the feedback from this review.

[naslundx]

A little late to the party but I made the fixes, and will put up an updated PR