CFE fails to notice record field name differences when performing subtype matches #55802
Labels
area-front-end
Use area-front-end for front end / CFE / kernel format related issues.
cfe-dysfunctionalities
Issues for the CFE not behaving as intended
cfe-unreported-error
Issues for missing compile-time errors in CFE.
The following code is accepted by the CFE but rejected by the analyzer:
The analyzer's error message (at the line marked (1)) is:
The analyzer is correct to reject the code.
What's going wrong on the CFE side is that when performing type inference on the call
f(1..h())
, the context is({double bar})
, and the CFE is called upon to try to match that to the return type off
, which is({T foo})
. Due to a bug inTypeConstraintGatherer._isNullabilityAwareSubtypeMatch
, the CFE fails to notice that the namesfoo
andbar
disagree, so it infers a type ofdouble
forT
. As a result, the argument off
(1..h()
) gets type inferred with a context ofdouble
, so1
gets interpreted as1.0
, and so the CFE thinks the extension methodh
is available.I'll send out a fix for review shortly.
The text was updated successfully, but these errors were encountered: