-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make fields of Span
private
#43968
Make fields of Span
private
#43968
Conversation
src/libsyntax_pos/lib.rs
Outdated
} | ||
#[inline] | ||
#[must_use] | ||
pub fn set_lo(self, lo: BytePos) -> Span { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure set_x
are the best possible names since the functions are not mutating, but at least I guarded them from mistakes with #[must_use]
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the fields be named with_x
? In my mind that conjures the fact that the method returns a copy of the same type with the field having the new value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, seems better, I'll rename.
src/librustc/hir/lowering.rs
Outdated
@@ -425,7 +425,7 @@ impl<'a> LoweringContext<'a> { | |||
allow_internal_unsafe: false, | |||
}, | |||
}); | |||
span.ctxt = SyntaxContext::empty().apply_mark(mark); | |||
span = span.set_ctxt(SyntaxContext::empty().apply_mark(mark)); | |||
span |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh? Just return span.set_ctxt(SyntaxContext::empty().apply_mark(mark))
directly.
src/libsyntax_pos/lib.rs
Outdated
#[inline] | ||
#[must_use] | ||
pub fn set_lo(self, lo: BytePos) -> Span { | ||
Span::new(lo, self.hi(), self.ctxt()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't it make more sense to do the following in all the set_x
methods?
Span {lo, ..self}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was necessary with interning (the same is true for #43968 (comment)). It will be necessary with any non-trivial Span::new
/Span::lo
/etc, so I left it.
src/libsyntax_pos/lib.rs
Outdated
} | ||
#[inline] | ||
#[must_use] | ||
pub fn set_lo(self, lo: BytePos) -> Span { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the fields be named with_x
? In my mind that conjures the fact that the method returns a copy of the same type with the field having the new value.
src/libsyntax_pos/lib.rs
Outdated
let lo = cmp::max(self.hi.0 - 1, self.lo.0); | ||
Span { lo: BytePos(lo), ..self } | ||
let lo = cmp::max(self.hi().0 - 1, self.lo().0); | ||
self.set_lo(BytePos(lo)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it really necessary to use the public getters in the impl
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it would be if spans were really interned. For now I'd also opt for just accessing the fields directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. Thanks, @petrochenkov! I'm also for renaming the set_x
methods to with_x
. Other than that (and maybe not using the getters in impl Span
) this is good to go.
You might be interested in this: A couple of years ago I did some experiments with span interning plus storing the span information directly in the interning key, if it fit in there (like a tagged pointer). The results were actually quite promising, if I remember correctly: https://internals.rust-lang.org/t/rfc-compiler-refactoring-spans/1357/23. Maybe you want to revisit interning with this additional optimization?
src/libsyntax_pos/lib.rs
Outdated
let lo = cmp::max(self.hi.0 - 1, self.lo.0); | ||
Span { lo: BytePos(lo), ..self } | ||
let lo = cmp::max(self.hi().0 - 1, self.lo().0); | ||
self.set_lo(BytePos(lo)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it would be if spans were really interned. For now I'd also opt for just accessing the fields directly.
I remembered there was a thread about this somewhere! Thanks for the link. |
Updated. |
src/libsyntax/codemap.rs
Outdated
Some(Span::new( | ||
cmp::min(sp_lhs.lo(), sp_rhs.lo()), | ||
cmp::max(sp_lhs.hi(), sp_rhs.hi()), | ||
sp_lhs.ctxt() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this can be replaced with Some(sp_lhs.to(sp_rhs))
.
☔ The latest upstream changes (presumably #43933) made this pull request unmergeable. Please resolve the merge conflicts. |
Thanks! r=me after rebasing. |
@bors r=michaelwoerister |
📌 Commit cdae234 has been approved by |
⌛ Testing commit cdae2343dba5a47c3e9846b6e7c8521ac1102c2c with merge 17e924eb9a0484958fe948c38b20c93644eb3137... |
💔 Test failed - status-travis |
Sigh, need to send a PR to |
We've hit a deadlock situation where the I think this PR should be split into two stages,
|
@kennytm |
I gathered some span statistics from rustc/libstd and found a significant number of "reverse" spans with I'm going to add "normalization" to |
@bors r=michaelwoerister |
📌 Commit 3da163f has been approved by |
⌛ Testing commit 3da163f55b1dd62f247f63edee30f64e3e7da2f5 with merge 4ad2c420bbe6368916158ddb4b354a7652a02d72... |
💔 Test failed - status-travis |
@bors r=michaelwoerister |
📌 Commit c4125e2 has been approved by |
⌛ Testing commit c4125e26389fbe5beceed0c562a47dfb3e45df07 with merge c1ad7551a567319ae597b9643a3dcf627d9bf8e2... |
💔 Test failed - status-travis |
|
Possibly a bad span produced in save-analysis? |
The errors are caused by RLS update, not by span patches, i.e. 9061581 alone (without rust-lang/rls@f4e6f16) is enough to reproduce them. |
Could you provide a dump of the reversed spans? I've seen them every now and then but have put off investigating the root cause(s). There are a few possible very unseemly results that could happen, for example when doing |
Waiting on #44028 |
I have only numbers unfortunately. Looks like the only way to obtain the source of inverted spans from |
Sounds reasonable. Will do. Are asserts only enabled on nightly? Would rather not cause ICEs for a rather benign bug just because it isn't caught in the test, but would like to see he effects of it on cargo bomb. |
☔ The latest upstream changes (presumably #44028) made this pull request unmergeable. Please resolve the merge conflicts. |
Not sure about |
This helps to avoid landing changes to rustc and rustfmt in one step
I'll try to land changes to rustc and rustfmt in two steps (rustfmt is moving forward too fast), so I made fields of |
📌 Commit a0c3264 has been approved by |
Make fields of `Span` private I actually tried to intern spans and benchmark the result<sup>*</sup>, and this was a prerequisite. This kind of encapsulation will be a prerequisite for any other attempt to compress span's representation, so I decided to submit this change alone. The issue #43088 seems relevant, but it looks like `SpanId` won't be able to reuse this interface, unless the tables are global (like interner that I tried) and are not a part of HIR. r? @michaelwoerister anyway <sup>*</sup> Interning means 2-3 times more space is required for a single span, but duplicates are free. In practice it turned out that duplicates are not *that* common, so more memory was wasted by interning rather than saved.
☀️ Test successful - status-appveyor, status-travis |
I actually tried to intern spans and benchmark the result*, and this was a prerequisite.
This kind of encapsulation will be a prerequisite for any other attempt to compress span's representation, so I decided to submit this change alone.
The issue #43088 seems relevant, but it looks like
SpanId
won't be able to reuse this interface, unless the tables are global (like interner that I tried) and are not a part of HIR.r? @michaelwoerister anyway
* Interning means 2-3 times more space is required for a single span, but duplicates are free. In practice it turned out that duplicates are not that common, so more memory was wasted by interning rather than saved.