Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Make lambda symbols stable post a3abf11
Commit a3abf11 fixes some cases of lambdas having unstable symbol names between compilation units by using `generateIdWithLoc` to generate stable lambda names, however since LOC doesn't uniquely identify a lambda instance (because templates, mixins, static foreach and foreach unrolling), `generateIdWithLoc` adds a counter, so there is still some instability going on. `generateIdWithLoc` makes the name uniq per file+loc, by adding adding a numeric suffix. But the order of instantiations might be different across compilation units, so with this counting scheme we are back to unstable names, so one module might have `t!0.__lambda_LOC` and `t!1.__lambda_LOC_1` while another one has `t!1.__lambda_LOC` This is not a critical problem, but at very least the code gets duplicated for no reason. I also have an example where it leads to linking error, but since it's not a small one and fails to minimize further, I suspect it's a result of interaction with some other bug. The thing is we don't even need uniqueness for those lambdas inside templates/mixins: their final names will have the instantiation prefix anyway. But we can't also just disable this uniqueness check completely: `static foreach` as well as unrollings of the normal `foreach` with lambdas in the loop body will have several copies of a single lambda with the same file+loc. So here we do want to keep making them unique. Fortunately, I don't think a `foreach` could be iterated in different order in different compilation units, so hopefully if we limit the counting to this case only, it won't make symbols unstable. To implement this idea, I've added an extra `parent` argument to `generateIdWithLoc`: it works like using `parent ~ prefix` prefix, but without adding `parent` to the final output.
- Loading branch information