| 04:07 | <jridgewell> | Seems like `WeakRef`s need some basic sanity tests in test262 |
| 04:08 | <leobalter> | jridgewell do you mean the recent changes? |
| 04:08 | <jridgewell> | shu's https://gist.github.com/syg/13d44f2b1a36095a90f722a1b84e6da2 example |
| 04:08 | <jridgewell> | An engine optimization prevents GC |
| 04:09 | <jridgewell> | Because the two arrows share a function context, and one uses `this`, so both strongly hold the `this`. |
| 14:08 | <littledan> | jridgewell: The WeakRef spec allows JS engines to leak as much as they want, formally speaking |
| 14:09 | <littledan> | we *expect* that there will be engine-specific leaks as well as leaks that are in common between engines |
| 14:09 | <littledan> | engines may also arbitrarily delay collection and then do it some time later |
| 15:08 | <shu> | jridgewell: yeah i agree with dan |
| 15:08 | <shu> | my example is the faustian bargain for weakrefs |
| 15:12 | <shu> | should not test reachability of implementation choices |
| 15:58 | <devsnek> | this came up a while ago when i was trying to verify the weakref spec in engine262 |
| 15:59 | <devsnek> | the implementation-contributed directory in test262 could include more aggressive tests that match real-world expectations |
| 16:04 | <leobalter> | devsnek I’ve discussed this from time to time, Test262 can’t enforce behavior not demanded by the specs. Implementation defined/dependent are blockers for full comprehensive tests. |
| 16:05 | <devsnek> | leobalter: isn't the the "implementation-contributed" directory for that purpose? |
| 16:05 | <devsnek> | like it has tco tests and stuff |
| 16:05 | <devsnek> | well lackthereof tco tests |
| 16:05 | <leobalter> | Nope. That directory is a simply upstream to be then converted to Test262 |
| 16:06 | <devsnek> | interesting |
| 16:06 | <leobalter> | There was no time available to convert all of these tests. |
| 16:07 | <devsnek> | would be interesting to have some shared "real world" tests |
| 16:07 | <leobalter> | Not on Test262 |
| 16:08 | <devsnek> | how come |
| 16:08 | <leobalter> | As I said, I’ve discussed this from time to time. Test262 goal is to provide tests for the specs. I’d be up for a different repo with other tests meant to be shared among implementations |
| 16:09 | <leobalter> | If we cannot specify, why should we enforce tests? The project is also big enough and very hard to maintain. |
| 16:11 | <leobalter> | We have specific requirements in order to have the tests available/compatible for those using it. The other general tests follow a lot of implementation specific testing api |
| 16:13 | <leobalter> | It’s Saturday. I’d be happy to have a call and discuss more shared collaboration. |
| 16:14 | <leobalter> | During the week, ofc |