Move field_name from runtime to schema generation time

[adriangb]

Pydantic should have this information when it is building the schema so this removes a bit of branching that happens at runtime, including a runtime error if the schema is misconfigured and a field from the poor catch-all Extra struct.

If we take this one step further we could replace field_name with field_info which could be an arbitrary generic type, giving us more flexibility on the Pydantic side to e.g. make it a FieldInfo instead of a string which you then need to look up in the model class. This change in particular would allow us to pass FieldInfo into Annotated validators if we wanted to.

Selected Reviewer: @dmontagu

[codspeed-hq]

CodSpeed Performance Report

Merging #715 will improve performances by 13.51%

_{Comparing test-field-info (13d2a7a) with main (d285975)}

Summary

🔥 3 improvements
✅ 123 untouched benchmarks

Benchmarks breakdown

	Benchmark	main	test-field-info	Change
🔥	test_list_of_ints_core_json	6.3 ms	5.7 ms	+10.12%
🔥	test_set_of_ints_core_json_duplicates	5.4 ms	4.8 ms	+11.66%
🔥	test_field_function_validator	939.4 µs	827.6 µs	+13.51%

[adriangb]

Just an idea I got from discussion in #714 . We could move the whole FieldInfo here or at least the field_name. I don't see any reason why we can't supply that to the schema in pydantic, and it would save us the runtime work of copying field_name around in `Extra, some branching, etc.

[codecov]

Codecov Report

Merging #715 (13d2a7a) into main (d285975) will decrease coverage by 0.01%.
The diff coverage is 100.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #715      +/-   ##
==========================================
- Coverage   93.63%   93.63%   -0.01%     
==========================================
  Files          99       99              
  Lines       13913    13895      -18     
  Branches       25       25              
==========================================
- Hits        13028    13010      -18     
  Misses        879      879              
  Partials        6        6              

Impacted Files	Coverage Δ
src/validators/dataclass.rs	98.31% <ø> (-0.02%)	⬇️
src/validators/generator.rs	91.39% <ø> (-0.07%)	⬇️
src/validators/mod.rs	97.77% <ø> (-0.03%)	⬇️
src/validators/model_fields.rs	98.30% <ø> (-0.01%)	⬇️
src/validators/typed_dict.rs	97.39% <ø> (ø)
python/pydantic_core/core_schema.py	96.64% <100.00%> (+<0.01%)	⬆️
src/validators/function.rs	91.36% <100.00%> (-0.05%)	⬇️
src/validators/model.rs	98.37% <100.00%> (-0.04%)	⬇️

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d285975...13d2a7a. Read the comment docs.

[adriangb]

please review

[adriangb]

I measured #726 locally and am getting 22.09±0.5us on this branch vs. 26.17±0.362 on main.

[adriangb]

Benchmarks are now reflecting a 13.5% speedup :)

[dmontagu]

@samuelcolvin Adrian and I discussed, and I think Adrian was going to try to implement the pydantic side before merging this to make sure there were no surprises, but we also want to make sure you don't have objections before merging.

(As far as I'm concerned this is good, at least assuming it can be made to work with pydantic, but figure there's a chance I'm not considering something important.)

[adriangb]

I created pydantic/pydantic#6392, it looks pretty good I think. If that looks good to you David lets merge this and I can update that PR once we have a new core release