You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Any time a binder is created/injected on-the-fly during binding, there is a risk that it could get dropped when it is used to bind an expression that involves getting more specific binders with GetBinder.
Using LocalInProgressBinder as an example (issue fixed in #75371):
This binder was injected when binding a local initializer to compute its constant value (new LocalInProgressBinder(...) in SourceLocalSymbol.MakeConstantTuple).
The binder keeps track of the const local being bound and helps avoid circularity issues.
But binding some expressions like checked(x) or x switch { ... } would involve a call to GetBinder and the LocalInProgressBinder would be lost, opening the compiler up to circularity issues.
Two possible solutions we discussed so far:
avoid injecting the binder on-the-fly (use a binder factory instead)
ensure that GetBinder maintains the injected binder
Any time a binder is created/injected on-the-fly during binding, there is a risk that it could get dropped when it is used to bind an expression that involves getting more specific binders with
GetBinder
.Using
LocalInProgressBinder
as an example (issue fixed in #75371):This binder was injected when binding a local initializer to compute its constant value (
new LocalInProgressBinder(...)
inSourceLocalSymbol.MakeConstantTuple
).The binder keeps track of the
const
local being bound and helps avoid circularity issues.But binding some expressions like
checked(x)
orx switch { ... }
would involve a call toGetBinder
and theLocalInProgressBinder
would be lost, opening the compiler up to circularity issues.Two possible solutions we discussed so far:
GetBinder
maintains the injected binderFYI @AlekseyTs
The text was updated successfully, but these errors were encountered: