sigmundch

I'm creating https://dart-review.googlesource.com/c/sdk/+/264601 to address the runtime error introduced above. This doesn't address the performance regressions and cost highlighted by @rakudrama above. To improve our tracking, I will close this...

The fix landed in 770c9d77c59fec5c538387901d9884f0fd45fda5

Yes, I believe you are correct @srujzs

> ... separate type graph from call graph representations. Correct! > ... store a SideEffect object on each member in the call graph ... ? Yes, but there is a...

@itsjustkevin - I know you are still circling back on the precise goals here, but some quick insights into the list you shared: * `num.parse` has a deprecated `onError` parameter,...

Thanks for sharing @eernstg - I like it :) - I see the parallel with the discussed in the other doc (what I had called "attached extensions"), and yes, I...

Does this issue relate to `supportsExplicitGetterCalls` (https://github.com/dart-lang/sdk/blob/94d797ebee87e7bd02521c465e52056fdc9b4d01/pkg/kernel/lib/target/targets.dart#L503)? Dart2js currently can't use the CFE lowering to encode getter calls as an explicit `.call` because of JS interop. For example, in code...

Agree that it is a good idea to restrict (2) further. I'm not as familiar with the linter, but if it cannot do checks based on type information, then I...

Our dependency is still there, but probably can easily be refactored by updating the dart2js patch files without changing the compiler directly /cc @rakudrama

@mit-mit https://github.com/dart-lang/sdk/commit/efb509c114dcaf54d0a011f717b48893d71ec9c3 should address the dependency from dart2js, I think the constructor is now ready to be removed.