Reuse stored hashes when building a set from a set/frozenset/dict - #8491

Closes #8489.

Changes

dict_inner.rs — each entry point computed the hash on its first line and passed only the hash variable downward, so the split is mechanical: the body moves to a *_known_hash variant and the original becomes a wrapper. No logic is duplicated.

• insert_known_hash, contains_known_hash, remove_if_known_hash, delete_if_exists_known_hash, delete_or_insert_known_hash
• keys_with_hashes() — yields (key, hash) from the entries, next to the existing keys()/values()/items()

The _known_hash suffix follows CPython's "KnownHash" variants (_PyDict_SetItem_KnownHash, _PyDict_Contains_KnownHash, _PyDict_DelItem_KnownHash), which mark the same split as set_add_key/set_add_entry on the set side. keys_with_hashes() keeps with because it really does return the hashes.

function/protocol.rs — ArgIterable::as_object(), a pub(crate) accessor for the object before any __iter__ call. The set operations take ArgIterable, which already held the original PyObjectRef in a private field; reaching it lets them dispatch on the source type without changing a single signature (they are passed around as fn(&PySetInner, ArgIterable, &VirtualMachine) -> ... function pointers, so changing them would have rippled widely).

builtins/set.rs

• PySetInner::cached_hashes() — Some(Vec<(key, hash)>) for a set/frozenset (subclasses included, via the existing extract_set) or an exact dict, None otherwise. Same predicates as CPython.
• add_known_hash / contains_known_hash
• merge_set / merge_dict now forward the stored hashes
• Fast path added to union, intersection, difference, symmetric_difference, difference_update, symmetric_difference_update, intersection_update — the existing generic loop stays as the fallback in each
• PyFrozenSet's Constructor::Args becomes OptionalArg<PyObjectRef> so py_new receives the source object and can hand its stored hashes over via PySetInner::from_object, instead of flattening to Vec<PyObjectRef> first; slot_new keeps only argument parsing and the empty-singleton check

Result

after dict.fromkeys(map):  10
after frozenset(d):        10
after set(d):              10
after s.difference(d):     10
after s.symmetric_difference_update(d): 10

Testing

• test_set — Ran 630 tests ... OK (expected failures=10), no new failures
• test_dict, test_dictviews, test_dictcomps, test_ordered_dict, test_defaultdict, test_userdict, test_setcomps, test_weakset, test_collections, test_copy — all pass
• test_types, test_builtin, test_iter, test_pickle, test_marshal, test_descr, test_class, test_functools, test_typing — all pass
• extra_tests/snippets/: builtin_set.py, builtin_dict.py, builtin_dict_union.py, frozen.py
• Ad-hoc: empty-frozenset singleton, frozenset(f) is f, distinct ids for empty subclass instances, dict subclasses correctly excluded from the exact-dict path, self-referential ops (s.update(s), s.symmetric_difference_update(s)), results not aliasing their operands, error messages unchanged vs CPython 3.14.6
• cargo fmt --check clean, cargo clippy -p rustpython-vm --all-targets no new warnings

Review note

insert_known_hash depends on a contract the callee cannot verify: pass a hash that isn't key.key_hash(vm) and the entry lands in a bucket no lookup will probe, so the key silently disappears. This is documented on the function, and every call site forwards a hash that came from keys_with_hashes() on a container holding that same key object. Worth a careful look.

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features

  • Frozensets can now be created directly from an optional iterable.
  • Exact frozenset inputs are preserved where applicable.
  • Empty frozenset creation continues to reuse the shared empty instance.

• Performance

  • Set operations and updates are more efficient by reusing cached element hashes.
  • Improved hashing efficiency for set, frozenset, and dictionary insertion, lookup, deletion, merging, and membership operations.