ndmitchell
Better output locations in preprocessor
Currently multi-line updates cause problems with line numbering in the following code, so that hints and navigation in ghcide no longer work. Is it possible to respect source line numbers in the multi-line updates?
@pkapustin probably, I guess I don't increment something at some point? If you want to experiment and send a patch I'd happily accept,
I think what happens is that record-dot-preprocessor always expands record update to one line even if it takes multiple lines in a source file (for example, because several fields are updated and each is placed on a separate line). I am not sure how to fix it, but I think it would be very nice if the output generated by record-dot-preprocessor followed the source in case of multi-line updates.
@pkapustin I found two issues which I've pushed fixes for. I'd appreciate you trying it to confirm it really does help. We can only emit LINE declarations at the start of a line.
- Previously, if we wanted to emit a LINE declaration and we couldn't, because it wasn't the start of a line, we just didn't but imagined we had. Now, we imagine we haven't, and wait to see if we can later on.
- Previously whitespace was joined together, and we could only emit if a piece of whitespace ended with a newline. Now we split up newlines to make even indented code get LINE.
I imagine those two things will be a massive improvement, but it's somewhat subtle invariants, so keen to see in practice. If it works, will make a release (or if you're unable to test I'll make a release too).
@ndmitchell This works great now! LINE declarations are emitted after all multi-line updates, and the problem is gone.