> 2. In order to detect whether a resource leaks if something throws, you need > to know what conditions are considered as a "leak". It's trivial to know > that for object allocations, but not for logical resources (for example an > OS handle that you received from a C API, which is an integer as far as the > compiler is concerned. [...] > For this kind of analysis, we need two things. One is the callgraph, > similar to the current checker. The other is knowing whether a function > actually throws, or whether it's only declared as non-noexcept because for > example it calls a non-noexcept API that actually never throws.
I'm not super-familiar with the details, bhackett or the GC team can fill in more, but I think this is all stuff we're doing now with the GC rooting analysis. IIUC, it's based on a pretty awesome C++ static analysis framework bhackett wrote in grad school called sixgill that's able to reason about dataflow, the global control flow graph and all the complicated C++ features. The basis of reasoning is annotations on various C++ types that indicate they should not be held live across calls that could GC and a bunch of other annotations for tweaking the analysis when we don't want to pay a dynamic cost. Of course, as you pointed out, we'd need new annotations on all the resource-y things; that's the "lots of careful work" that we all agree would be necessary. But even before we turned on EH, this could help tighten the code by instituting a regular, idiomatic scheme for managing resource-y things in a way that avoids accidental leaks when someone refactors the code and adds a new return path. _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
