Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Combine HasAttrs and HasTokens into AstLike #82448

Merged
merged 1 commit into from
Feb 27, 2021
Merged

Combine HasAttrs and HasTokens into AstLike #82448

merged 1 commit into from
Feb 27, 2021

Conversation

Aaron1011
Copy link
Member

When token-based attribute handling is implemeneted in #80689,
we will need to access tokens from HasAttrs (to perform
cfg-stripping), and we will to access attributes from HasTokens (to
construct a PreexpTokenStream).

This PR merges the HasAttrs and HasTokens traits into a new
AstLike trait. The previous HasAttrs impls from Vec<Attribute> and AttrVec
are removed - they aren't attribute targets, so the impls never really
made sense.

@rust-highfive
Copy link
Collaborator

r? @estebank

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 23, 2021
@Aaron1011
Copy link
Member Author

cc @rust-lang/wg-rustfmt : This PR will break rustfmt. Fixing the build should just require switching all uses of rustc_ast::attr::HasAttrs to rustc_ast::AstLike

@rust-log-analyzer

This comment has been minimized.

Sign in to view
@Aaron1011 Aaron1011 force-pushed the merge-hastokens-hasattrs branch from 57cf192 to f221432 Compare February 23, 2021 17:37
@petrochenkov
Copy link
Contributor

r? @petrochenkov

@Aaron1011 Aaron1011 mentioned this pull request Feb 23, 2021
Closed
@petrochenkov
Copy link
Contributor

AstLike and its impls look like enough code to move it from ast.rs to a separate module.

@petrochenkov
Copy link
Contributor

I don't like the name, but I'm not sure how to name this better.
We already have three enums that are all slightly different from each other, but all similar to static versions of AstLike - AstFragment, Annotatable and Nonterminal, all highlight different aspects of "AST-node"ness.

@Aaron1011
Copy link
Member Author

I don't like the name, but I'm not sure how to name this better.

Yeah, I wish I could come up with a better name. The fact that it's implemented on Option<T> and P<T> dissuaded me from calling it AstNode.

@Aaron1011
Copy link
Member Author

We already have three enums that are all slightly different from each other, but all similar to static versions of AstLike - AstFragment, Annotatable and Nonterminal, all highlight different aspects of "AST-node"ness.

That's true. However, this PR combines two traits into one, so I would say that it's moving us closer towards an eventual 'AST unification'.

@petrochenkov
Copy link
Contributor

From these three Nonterminal is the closest to AstLike, so "having tokens" is the primary property of AstLike after all.
So perhaps trait inheritance trait HasAttrs: HasTokens { ... } would make more sense than merging these traits into one?

@Aaron1011
Copy link
Member Author

So perhaps trait inheritance trait HasAttrs: HasTokens { ... } would make more sense than merging these traits into one?

I considered doing this. However, this would require us to implement HasAttrs for things that don't really have attributes at all (Ty, Pat, Path, Visibility) in order to allow bounding collect_tokens_trailing_token with R: HasAttrs.

@Aaron1011 Aaron1011 force-pushed the merge-hastokens-hasattrs branch from f221432 to f52ea52 Compare February 25, 2021 22:00
@Aaron1011
Copy link
Member Author

I've moved AstLike and all of the impls to a separate module.

@petrochenkov
Copy link
Contributor

One more question - why is it necessary to implement AstLike on things like P<T> or Spanned if its methods can always be called through deref (in the first case) or through spanned.node (in the second).

I don't think these extra impls add much convenience, but they indeed move the trait further from representing an "AST node".

@Aaron1011
Copy link
Member Author

We need the impl for P<T> because many of the various parse methods (e.g. parse_expr) wrap their result in a P. Without the impl, we would either need to modify all of those methods, or change the collect_tokens_trailing_token calls to unwrap and re-add the P necessarily.

The impl for Spanned was unnecessary, so I removed it.

@Aaron1011 Aaron1011 force-pushed the merge-hastokens-hasattrs branch from f52ea52 to de0a26e Compare February 25, 2021 22:32
@petrochenkov
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Feb 26, 2021

📌 Commit de0a26e378a980633481b72dd25e2fc307ac1e73 has been approved by petrochenkov

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 26, 2021
@Dylan-DPC-zz Dylan-DPC-zz mentioned this pull request Feb 27, 2021
Closed
@Dylan-DPC-zz Dylan-DPC-zz mentioned this pull request Feb 27, 2021
Merged
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 27, 2021
@bors
Auto merge of rust-lang#82577 - Dylan-DPC:rollup-c3si8ju, r=Dylan-DPC
9fa580b 
Rollup of 14 pull requests

Successful merges:

 - rust-lang#81794 (update tracking issue for `relaxed_struct_unsize`)
 - rust-lang#82057 (Replace const_cstr with cstr crate)
 - rust-lang#82370 (Improve anonymous lifetime note to indicate the target span)
 - rust-lang#82394 (:arrow_up: rust-analyzer)
 - rust-lang#82396 (Add Future trait for doc_spotlight feature doc)
 - rust-lang#82404 (Test hexagon-enum only when llvm target is present)
 - rust-lang#82419 (expand: Preserve order of inert attributes during expansion)
 - rust-lang#82420 (Enable API documentation for `std::os::wasi`.)
 - rust-lang#82421 (Add a `size()` function to WASI's `MetadataExt`.)
 - rust-lang#82442 (Skip emitting closure diagnostic when closure_kind_origins has no entry)
 - rust-lang#82473 (Use libc::accept4 on Android instead of raw syscall.)
 - rust-lang#82482 (Use small hash set in `mir_inliner_callees`)
 - rust-lang#82490 (Update cargo)
 - rust-lang#82494 (Substitute erased lifetimes on bad placeholder type)

Failed merges:

 - rust-lang#82448 (Combine HasAttrs and HasTokens into AstLike)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors
Copy link
Contributor

bors commented Feb 27, 2021

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

  1. git checkout merge-hastokens-hasattrs (switch to your branch)
  2. git fetch upstream master (retrieve the latest master)
  3. git rebase upstream/master -p (rebase on top of it)
  4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
  5. git push self merge-hastokens-hasattrs --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message 
Auto-merging compiler/rustc_expand/src/expand.rs
CONFLICT (content): Merge conflict in compiler/rustc_expand/src/expand.rs
Automatic merge failed; fix conflicts and then commit the result.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Feb 27, 2021
@Aaron1011
Combine HasAttrs and HasTokens into AstLike
fb5fec0 
When token-based attribute handling is implemeneted in rust-lang#80689,
we will need to access tokens from `HasAttrs` (to perform
cfg-stripping), and we will to access attributes from `HasTokens` (to
construct a `PreexpTokenStream`).

This PR merges the `HasAttrs` and `HasTokens` traits into a new
`AstLike` trait. The previous `HasAttrs` impls from `Vec<Attribute>` and `AttrVec`
are removed - they aren't attribute targets, so the impls never really
made sense.
@Aaron1011 Aaron1011 force-pushed the merge-hastokens-hasattrs branch from de0a26e to fb5fec0 Compare February 27, 2021 05:14
@Aaron1011
Copy link
Member Author

@bors r=petrochenkov

@bors
Copy link
Contributor

bors commented Feb 27, 2021

📌 Commit fb5fec0 has been approved by petrochenkov

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 27, 2021
@bors
Copy link
Contributor

bors commented Feb 27, 2021

⌛ Testing commit fb5fec0 with merge 8e863eb...

@bors
Copy link
Contributor

bors commented Feb 27, 2021

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing 8e863eb to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Feb 27, 2021
@bors bors merged commit 8e863eb into rust-lang:master Feb 27, 2021
@rustbot rustbot added this to the 1.52.0 milestone Feb 27, 2021
This was referenced Feb 27, 2021
Merged
Closed
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 7, 2024
@bors
Auto merge of rust-lang#126733 - ZhuUx:llvm-19-adapt, r=Zalathar
0909ca8 
[Coverage][MCDC] Adapt mcdc to llvm 19

Related issue: rust-lang#126672

Also finish task 4 at rust-lang#124144

[llvm rust-lang#82448](llvm/llvm-project#82448) has introduced some break changes into mcdc, causing incompatibility between llvm 18 and 19. This draft adapts to that change and gives up supporting for llvm-18.
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 8, 2024
@bors
Auto merge of rust-lang#126733 - ZhuUx:llvm-19-adapt, r=Zalathar
cf24c73 
[Coverage][MCDC] Adapt mcdc to llvm 19

Related issue: rust-lang#126672

Also finish task 4 at rust-lang#124144

[llvm rust-lang#82448](llvm/llvm-project#82448) has introduced some break changes into mcdc, causing incompatibility between llvm 18 and 19. This draft adapts to that change and gives up supporting for llvm-18.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@petrochenkov petrochenkov petrochenkov left review comments

Assignees

@petrochenkov petrochenkov

Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Milestone
1.52.0
Development

Successfully merging this pull request may close these issues.
7 participants
@Aaron1011 @rust-highfive @rust-log-analyzer @petrochenkov @bors @estebank @rustbot