Removal of block spans from trans has ruined lexical block debug info

[jdm]

debuginfo was relying on block-level spans to generate proper location information. Now arbitrary non-block spans are being passed instead, causing a proliferation of fake blocks to be created and cached (slowing down debug compilation time by >10x), as well as incorrect debuginfo generation.

[marijnh]

I'll look into this first thing next week. It's probably just a matter of using better keys for the blocks.

[jdm]

I think it's a bit more complicated than that. The block debug info requires a starting line and column for each block, but many of the spans being passed into debuginfo are providing spans for individual ast items within blocks. Furthermore, block debug info refers to parent blocks, which themselves require correct spans. If we can prove that any time we refer to a block, every one of its parent blocks already exist in the metadata cache, we can avoid having to provide spans for all parents as well.

[marijnh]

I don't really know what a reasonable compile time is with -g. Could you get the patch at https://github.com/marijnh/rust/tree/debuginfo and see if it brings things back to normal?

The reason this worked at all before was purely by accident -- the spans were being tracked so poorly that a lot of insignificant block contexts ended up with the same span. I've now made it so that every context that corresponds to an actual {} in the source program gets a debuginfo block.

But I'm wondering what such blocks add, in terms of useful debuginfo, at all. Maybe we'd be better off simply not bothering with them?

[jdm]

I'm not certain what LLVM does if the lexical block debug information is not present when dealing only with line numbers, functions and files as -g currently does. For -xg, this information is very important for variable scoping information.

[jdm]

It looks like the lexical block cache is a huge perf drain in its current naive implementation, due to the number of entries. With the cache disabled (but block debug information generated every time), and reverting the path->id changes from create_function, I see -g taking about 1.6x as long as regular. That seems fine to me right now.

[jdm]

https://gist.github.com/1701436 is the diff of the changes I made to get the 1.6x build times.