Decline the compiled-invoker fast lane for custom type converters and foreign receivers#2737
Merged
Merged
Conversation
… foreign receivers Two behavior-parity gaps in the sebastienros#2733 exact-type fast lane found in pre-release review: - The lane's gate checked custom IObjectConverters but not the engine's user-replaceable ITypeConverter. The reflection path consults the converter for some exact-type argument conversions (e.g. bool under default value coercion), so a custom converter installed via SetTypeConverter was silently bypassed. The lane now requires the exact DefaultTypeConverter. - An extracted instance method invoked with a wrong-typed this (f.call(foreignObject)) surfaced InvalidCastException from the compiled receiver cast instead of the reflection path's TargetException, which host code and Interop.ExceptionHandler predicates key on. The lane now declines when the receiver is not an instance of the declaring type so the slow path surfaces the original exception shape. Both new tests fail without the gate changes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0115tQFNyyQqc1HQGPLUgZND
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pre-release review follow-up to #2733. Two behavior-parity gaps in the exact-type compiled fast lane, both verified with repros against 4.13 behavior:
ITypeConverterbypass. The gate checked_objectConvertersbut not the engine's user-replaceableTypeConverter. The reflection path consults it for some exact-type argument conversions (aboolargument under default value coercion flows throughconverter.TryConvert), so a converter installed viaSetTypeConverterthat vetoes/transforms those conversions was silently skipped and calls succeeded that previously failed (or were transformed). The lane now requires the exactDefaultTypeConvertertype —TryConvertis virtual, so anischeck would not do.var f = host.method; f.call(other)surfacedInvalidCastExceptionfrom the compiled receiver cast instead of the reflection path'sTargetException. Hostcatchclauses andInterop.ExceptionHandlerpredicates key on the exception type. The lane now declines when the receiver is not an instance of the declaring type (oneisinstper call), letting the slow path surface the original exception shape.Both new tests fail without the gate changes (verified by reverting). Full suite green on net10.0 + net472.
🤖 Generated with Claude Code
https://claude.ai/code/session_0115tQFNyyQqc1HQGPLUgZND