about summary refs log tree commit diff
path: root/compiler/rustc_codegen_llvm/src
diff options
context:
space:
mode:
authorbors <bors@rust-lang.org>2020-11-12 15:34:09 +0000
committerbors <bors@rust-lang.org>2020-11-12 15:34:09 +0000
commit9722952f0bed5815cb22cb4878be09fb39f92804 (patch)
tree270b703ec4edbb5a4c94f9edaac23b714d7a0512 /compiler/rustc_codegen_llvm/src
parent7f5a42b073dc2bee2aa625052eb066ee07072048 (diff)
parentdac57e67d6116bcad81f905b8e92be3e9d8e4d23 (diff)
downloadrust-9722952f0bed5815cb22cb4878be09fb39f92804.tar.gz
rust-9722952f0bed5815cb22cb4878be09fb39f92804.zip
Auto merge of #76256 - tgnottingham:issue-74890, r=nikomatsakis
incr-comp: hash and serialize span end line/column

Hash both the length and the end location (line/column) of a span. If we
hash only the length, for example, then two otherwise equal spans with
different end locations will have the same hash. This can cause a
problem during incremental compilation wherein a previous result for a
query that depends on the end location of a span will be incorrectly
reused when the end location of the span it depends on has changed. A
similar analysis applies if some query depends specifically on the
length of the span, but we only hash the end location. So hash both.

Fix #46744, fix #59954, fix #63161, fix #73640, fix #73967, fix #74890, fix #75900

---

See #74890 for a more in-depth analysis.

I haven't thought about what other problems this root cause could be responsible for. Please let me know if anything springs to mind. I believe the issue has existed since the inception of incremental compilation.
Diffstat (limited to 'compiler/rustc_codegen_llvm/src')
0 files changed, 0 insertions, 0 deletions