Uh oh!
There was an error while loading. Please reload this page.
Cleanup syntax::attr - #63146
Conversation
There was a problem hiding this comment.
This is due to the related change which implement Decodable/Encodable on AttrId via mk_attr_id and encode_nil. I'm not sure if they're actually equivalent, though. It feels like they should be.
There was a problem hiding this comment.
Is this the only place where attributes are decoded?
Perhaps incremental could decode them in the old way as an index, or something like that?
There was a problem hiding this comment.
AFAICT, this is the only place where attributes are decoded, but I'm not sure how to check (cc @eddyb?)
I'm not sure what you mean by "incremental could decode them in the old way" -- is that referring to a place where it'd be good to check whether we're doing the right decoding?
There was a problem hiding this comment.
AFAICT, this is the only place where attributes are decoded
Yeah, looks like that, at least from searching .decode( and ::decode(.
I thought about maybe commenting out the impl and trying to build, but looks like that's not feasible because everything including attributes derives RustcEncodable and RustcDecodable.
(By incremental I meant some place in incremental compilation that decodes things from cache.)
rust-highfive
commented
Jul 30, 2019
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Mark-Simulacrum
commented
Jul 30, 2019
Dropped ce34fd858a7a802a376f53789a34f9c844080a24 since I suspect it caused the test failure and is in any case sort of orthogonal to this PR's main thrust. |
rust-highfive
commented
Jul 30, 2019
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
There was a problem hiding this comment.
inner/outer are identical save for style -- consider a helper function that takes in the style.
Mark-Simulacrum
commented
Jul 30, 2019
Hm, okay, compilation failure looks to not be due to the attr id changes. I'll have to dig in to why that's happening... |
petrochenkov
commented
Jul 31, 2019
I didn't read the PR yet, but if the errors are about As I recently mentioned elsewhere, Some code using the builder relies, intentionally or not, on span contexts being lost or otherwise not preserved. |
There is no difference in the code/arguments, so go with the shorter name throughout the code.
MetaItem.span was always equivalent
Always the same as the passed MetaItem
Mark-Simulacrum
commented
Jul 31, 2019
d4227f6 fixes the previous error. |
petrochenkov
commented
Jul 31, 2019
r=me with the question about attribute ID decoding answered |
petrochenkov
commented
Jul 31, 2019
@bors r+ |
bors
commented
Jul 31, 2019
📌 Commit c146344 has been approved by |
…chenkov Cleanup syntax::attr Mostly removing needless arguments to constructors r? @petrochenkov
…chenkov Cleanup syntax::attr Mostly removing needless arguments to constructors r? @petrochenkov
…chenkov Cleanup syntax::attr Mostly removing needless arguments to constructors r? @petrochenkov
…chenkov Cleanup syntax::attr Mostly removing needless arguments to constructors r? @petrochenkov
Rollup of 5 pull requests Successful merges: - #62954 (Fix typo in Delimited::open_tt) - #63146 (Cleanup syntax::attr) - #63218 (rustbuild: RISC-V is no longer an experimental LLVM target) - #63227 (dead_code: Properly inspect fields in struct patterns with type relative paths) - #63229 (A bit of Miri error cleanup) Failed merges: r? @ghost
Remove unused AstBuilder This was removed in a recent rustc PR (rust-lang/rust#63146), replaced with inherent impls.
Mostly removing needless arguments to constructors
r? @petrochenkov