jj-lib-proc-macros-0.22.0/Cargo.toml0000644000000021560000000000100125110ustar # THIS FILE IS AUTOMATICALLY GENERATED BY CARGO # # When uploading crates to the registry Cargo will automatically # "normalize" Cargo.toml files for maximal compatibility # with all versions of Cargo and also rewrite `path` dependencies # to registry (e.g., crates.io) dependencies. # # If you are reading this file be aware that the original Cargo.toml # will likely look very different (and much more reasonable). # See Cargo.toml.orig for the original contents. [package] edition = "2021" rust-version = "1.76" name = "jj-lib-proc-macros" version = "0.22.0" build = false include = [ "/LICENSE", "/src/", ] autobins = false autoexamples = false autotests = false autobenches = false description = "Proc macros for the jj-lib crate" homepage = "https://github.com/martinvonz/jj" documentation = "https://martinvonz.github.io/jj/" readme = "README.md" license = "Apache-2.0" repository = "https://github.com/martinvonz/jj" [lib] name = "jj_lib_proc_macros" path = "src/lib.rs" proc-macro = true [dependencies.proc-macro2] version = "1.0.86" [dependencies.quote] version = "1.0.36" [dependencies.syn] version = "2.0.79" jj-lib-proc-macros-0.22.0/Cargo.toml.orig000064400000000000000000000010031046102023000161600ustar 00000000000000[package] name = "jj-lib-proc-macros" description = "Proc macros for the jj-lib crate" version = { workspace = true } edition = { workspace = true } rust-version = { workspace = true } license = { workspace = true } homepage = { workspace = true } repository = { workspace = true } documentation = { workspace = true } readme = { workspace = true } include = ["/LICENSE", "/src/"] [lib] proc-macro = true [dependencies] proc-macro2 = { workspace = true } quote = { workspace = true } syn = { workspace = true } jj-lib-proc-macros-0.22.0/LICENSE000064400000000000000000000261361046102023000143140ustar 00000000000000 Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. Definitions. "License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. "Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. "Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. "You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License. "Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. "Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. "Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. "Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution." "Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. 2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and (b) You must cause any modified files to carry prominent notices stating that You changed the files; and (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and (d) If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. 6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. 8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages. 9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability. END OF TERMS AND CONDITIONS APPENDIX: How to apply the Apache License to your work. To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets "[]" replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same "printed page" as the copyright notice for easier identification within third-party archives. Copyright [yyyy] [name of copyright owner] Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. jj-lib-proc-macros-0.22.0/README.md000064400000000000000000000407621046102023000145670ustar 00000000000000
# Jujutsu—a version control system ![](https://img.shields.io/github/v/release/martinvonz/jj) ![](https://img.shields.io/github/release-date/martinvonz/jj)
![](https://img.shields.io/github/license/martinvonz/jj) ![](https://github.com/martinvonz/jj/workflows/build/badge.svg) [![Discord](https://img.shields.io/discord/968932220549103686.svg?label=&logo=discord&logoColor=ffffff&color=7389D8&labelColor=6A7EC2)](https://discord.gg/dkmfj3aGQN) **[Homepage]   •  ** **[Installation]   •  ** **[Getting Started]   •  ** **[Development Roadmap]** [Homepage]: https://martinvonz.github.io/jj [Installation]: https://martinvonz.github.io/jj/latest/install-and-setup [Getting Started]: https://martinvonz.github.io/jj/latest/tutorial [Development Roadmap]: https://martinvonz.github.io/jj/latest/roadmap
## Introduction Jujutsu is a powerful [version control system](https://en.wikipedia.org/wiki/Version_control) for software projects. You use it to get a copy of your code, track changes to the code, and finally publish those changes for others to see and use. It is designed from the ground up to be easy to use—whether you're new or experienced, working on brand new projects alone, or large scale software projects with large histories and teams. Jujutsu is unlike most other systems, because internally it abstracts the user interface and version control algorithms from the *storage systems* used to serve your content. This allows it to serve as a VCS with many possible physical backends, that may have their own data or networking models—like [Mercurial] or [Breezy], or hybrid systems like Google's cloud-based design, [Piper/CitC]. [Mercurial]: https://www.mercurial-scm.org/ [Breezy]: https://www.breezy-vcs.org/ [Piper/CitC]: https://youtu.be/W71BTkUbdqE?t=645 Today, we use Git repositories as a storage layer to serve and track content, making it **compatible with many of your favorite Git-based tools, right now!** All core developers use Jujutsu to develop Jujutsu, right here on GitHub. But it should hopefully work with your favorite Git forges, too. We combine many distinct design choices and concepts from other version control systems into a single tool. Some of those sources of inspiration include: - **Git**: We make an effort to [be fast][perf]—with a snappy UX, efficient algorithms, correct data structures, and good-old-fashioned attention to detail. The default storage backend uses Git repositories for "physical storage", for wide interoperability and ease of onboarding. - **Mercurial & Sapling**: There are many Mercurial-inspired features, such as the [revset] language to select commits. There is [no explicit index][no-index] or staging area. Branches are "anonymous" like Mercurial, so you don't need to make up a name for each small change. Primitives for rewriting history are powerful and simple. Formatting output is done with a robust template language that can be configured by the user. - **Darcs**: Jujutsu keeps track of conflicts as [first-class objects][conflicts] in its model; they are first-class in the same way commits are, while alternatives like Git simply think of conflicts as textual diffs. While not as rigorous as systems like Darcs (which is based on a formalized theory of patches, as opposed to snapshots), the effect is that many forms of conflict resolution can be performed and propagated automatically. [perf]: https://github.com/martinvonz/jj/discussions/49 [revset]: https://martinvonz.github.io/jj/latest/revsets/ [no-index]: https://martinvonz.github.io/jj/latest/git-comparison/#the-index [conflicts]: https://martinvonz.github.io/jj/latest/conflicts/ And it adds several innovative, useful features of its own: - **Working-copy-as-a-commit**: Changes to files are [recorded automatically][wcc] as normal commits, and amended on every subsequent change. This "snapshot" design simplifies the user-facing data model (commits are the only visible object), simplifies internal algorithms, and completely subsumes features like Git's stashes or the index/staging-area. - **Operation log & undo**: Jujutsu records every operation that is performed on the repository, from commits, to pulls, to pushes. This makes debugging problems like "what just happened?" or "how did I end up here?" easier, *especially* when you're helping your coworker answer those questions about their repository! And because everything is recorded, you can undo that mistake you just made with ease. Version control has finally entered [the 1960s][undo-history]! - **Automatic rebase and conflict resolution**: When you modify a commit, every descendent is automatically rebased on top of the freshly-modified one. This makes "patch-based" workflows a breeze. If you resolve a conflict in a commit, the _resolution_ of that conflict is also propagated through descendants as well. In effect, this is a completely transparent version of `git rebase --update-refs` combined with `git rerere`, supported by design. > [!WARNING] > The following features are available for use, but experimental; they may have > bugs, backwards incompatible storage changes, and user-interface changes! - **Safe, concurrent replication**: Have you ever wanted to store your version controlled repositories inside a Dropbox folder? Or continuously backup repositories to S3? No? Well, now you can! The fundamental problem with using filesystems like Dropbox and backup tools like `rsync` on your typical Git/Mercurial repositories is that they rely on *local filesystem operations* being atomic, serialized, and non-concurrent with respect to other reads and writes—which is _not_ true when operating on distributed file systems, or when operations like concurrent file copies (for backup) happen while lock files are being held. Jujutsu is instead designed to be [safe under concurrent scenarios][conc-safety]; simply using rsync or Dropbox and then using that resulting repository should never result in a repository in a *corrupt state*. The worst that _should_ happen is that it will expose conflicts between the local and remote state, leaving you to resolve them. [wcc]: https://martinvonz.github.io/jj/latest/working-copy/ [undo-history]: https://en.wikipedia.org/wiki/Undo#History [conc-safety]: https://martinvonz.github.io/jj/latest/technical/concurrency/ The command-line tool is called `jj` for now because it's easy to type and easy to replace (rare in English). The project is called "Jujutsu" because it matches "jj". Jujutsu is relatively young, with lots of work to still be done. If you have any questions, or want to talk about future plans, please join us on Discord [![Discord](https://img.shields.io/discord/968932220549103686.svg?label=&logo=discord&logoColor=ffffff&color=7389D8&labelColor=6A7EC2)](https://discord.gg/dkmfj3aGQN) or start a [GitHub Discussion](https://github.com/martinvonz/jj/discussions); the developers monitor both channels. ### News and Updates 📣 - **Feb 2024**: Version 0.14 is released, which deprecates ["jj checkout" and "jj merge"](CHANGELOG.md#0140---2024-02-07), as well as `jj init --git`, which is now just called `jj git init`. - **Oct 2023**: Version 0.10.0 is released! Now includes a bundled merge and diff editor for all platforms, "immutable revsets" to avoid accidentally `edit`-ing the wrong revisions, and lots of polish. - **Jan 2023**: Martin gave a presentation about Google's plans for Jujutsu at Git Merge 2022! See the [slides][merge-slides] or the [recording][merge-talk]. ### Related Media - **Mar 2024**: Chris Krycho started [a YouTube series about Jujutsu][krycho-yt]. - **Feb 2024**: Chris Krycho published an article about Jujutsu called [jj init][krycho] and Steve Klabnik followed up with the [Jujutsu Tutorial][klabnik]. - **Jan 2024**: Jujutsu was featured in an LWN.net article called [Jujutsu: a new, Git-compatible version control system][lwn]. - **Jan 2023**: Martin's Talk about Jujutsu at Git Merge 2022, [video][merge-talk] and the associated [slides][merge-slides]. The wiki also contains a more extensive list of [media references][wiki-media]. [krycho-yt]: https://www.youtube.com/playlist?list=PLelyiwKWHHAq01Pvmpf6x7J0y-yQpmtxp [krycho]: https://v5.chriskrycho.com/essays/jj-init/ [klabnik]: https://steveklabnik.github.io/jujutsu-tutorial/ [lwn]: https://lwn.net/Articles/958468/ [merge-talk]: https://www.youtube.com/watch?v=bx_LGilOuE4 [merge-slides]: https://docs.google.com/presentation/d/1F8j9_UOOSGUN9MvHxPZX_L4bQ9NMcYOp1isn17kTC_M/view [wiki-media]: https://github.com/martinvonz/jj/wiki/Media ## Getting started > [!IMPORTANT] > Jujutsu is an **experimental version control system**. While Git compatibility > is stable, and most developers use it daily for all their needs, there may > still be work-in-progress features, suboptimal UX, and workflow gaps that make > it unusable for your particular use. Follow the [installation instructions](https://martinvonz.github.io/jj/latest/install-and-setup) to obtain and configure `jj`. The best way to get started is probably to go through [the tutorial](https://martinvonz.github.io/jj/latest/tutorial). Also see the [Git comparison](https://martinvonz.github.io/jj/latest/git-comparison), which includes a table of `jj` vs. `git` commands. As you become more familiar with Jujutsu, the following resources may be helpful: - The [FAQ](https://martinvonz.github.io/jj/latest/FAQ). - The [Glossary](https://martinvonz.github.io/jj/latest/glossary). - The `jj help` command (e.g. `jj help rebase`). If you are using a **prerelease** version of `jj`, you would want to consult [the docs for the prerelease (main branch) version](https://martinvonz.github.io/jj/prerelease/). You can also get there from the docs for the latest release by using the website's version switcher. The version switcher is visible in the header of the website when you scroll to the top of any page. ## Features ### Compatible with Git Jujutsu is designed so that the underlying data and storage model is abstract. Today, it features two [backends]—one of them uses a Git repository for storage, while the other is a native storage backend[^native-backend]. The Git backend uses the [libgit2](https://libgit2.org/) C library and the [gitoxide](https://github.com/Byron/gitoxide) Rust library. [backends]: https://martinvonz.github.io/jj/latest/glossary#backend [^native-backend]: At this time, there's practically no reason to use the native backend. The backend exists mainly to make sure that it's possible to eventually add functionality that cannot easily be added to the Git backend. The Git backend is fully featured and maintained, and allows you to use Jujutsu with any Git remote. The commits you create will look like regular Git commits. You can fetch branches from a regular Git remote and push branches to the remote. You can always switch back to Git. Here is how you can explore a GitHub repository with `jj`. You can even have a ["co-located" local repository](https://martinvonz.github.io/jj/latest/git-compatibility#co-located-jujutsugit-repos) where you can use both `jj` and `git` commands interchangeably. ### The working copy is automatically committed Jujutsu uses a real commit to represent the working copy. Checking out a commit results a new working-copy commit on top of the target commit. Almost all commands automatically amend the working-copy commit. The working-copy being a commit means that commands never fail because the working copy is dirty (no "error: Your local changes to the following files..."), and there is no need for `git stash`. Also, because the working copy is a commit, commands work the same way on the working-copy commit as on any other commit, so you can set the commit message before you're done with the changes. ### The repo is the source of truth With Jujutsu, the working copy plays a smaller role than with Git. Commands snapshot the working copy before they start, then they update the repo, and then the working copy is updated (if the working-copy commit was modified). Almost all commands (even checkout!) operate on the commits in the repo, leaving the common functionality of snapshotting and updating of the working copy to centralized code. For example, `jj restore` (similar to `git restore`) can restore from any commit and into any commit, and `jj describe` can set the commit message of any commit (defaults to the working-copy commit). ### Entire repo is under version control All operations you perform in the repo are recorded, along with a snapshot of the repo state after the operation. This means that you can easily revert to an earlier repo state, or to simply undo a particular operation (which does not necessarily have to be the most recent operation). ### Conflicts can be recorded in commits If an operation results in [conflicts](https://martinvonz.github.io/jj/latest/glossary#conflict), information about those conflicts will be recorded in the commit(s). The operation will succeed. You can then resolve the conflicts later. One consequence of this design is that there's no need to continue interrupted operations. Instead, you get a single workflow for resolving conflicts, regardless of which command caused them. This design also lets Jujutsu rebase merge commits correctly (unlike both Git and Mercurial). Basic conflict resolution: Juggling conflicts: ### Automatic rebase Whenever you modify a commit, any descendants of the old commit will be rebased onto the new commit. Thanks to the conflict design described above, that can be done even if there are conflicts. Bookmarks pointing to rebased commits will be updated. So will the working copy if it points to a rebased commit. ### Comprehensive support for rewriting history Besides the usual rebase command, there's `jj describe` for editing the description (commit message) of an arbitrary commit. There's also `jj diffedit`, which lets you edit the changes in a commit without checking it out. To split a commit into two, use `jj split`. You can even move part of the changes in a commit to any other commit using `jj squash -i --from X --into Y`. ## Status The tool is fairly feature-complete, but some important features like (the equivalent of) `git blame` are not yet supported. There are also several performance bugs. It's likely that workflows and setups different from what the core developers use are not well supported, e.g. there is no native support for email-based workflows. Today, all core developers use `jj` to work on `jj`. I (Martin von Zweigbergk) have almost exclusively used `jj` to develop the project itself since early January 2021. I haven't had to re-clone from source (I don't think I've even had to restore from backup). There *will* be changes to workflows and backward-incompatible changes to the on-disk formats before version 1.0.0. Even the binary's name may change (i.e. away from `jj`). For any format changes, we'll try to implement transparent upgrades (as we've done with recent changes), or provide upgrade commands or scripts if requested. ## Related work There are several tools trying to solve similar problems as Jujutsu. See [related work](https://martinvonz.github.io/jj/latest/related-work) for details. ## Contributing We welcome outside contributions, and there's plenty of things to do, so don't be shy. Please ask if you want a pointer on something you can help with, and hopefully we can all figure something out. We do have [a few policies and suggestions](https://martinvonz.github.io/jj/prerelease/contributing/) for contributors. The broad TL;DR: - Bug reports are very welcome! - Every commit that lands in the `main` branch is code reviewed. - Please behave yourself, and obey the Community Guidelines. - There **is** a mandatory CLA you must agree to. Importantly, it **does not** transfer copyright ownership to Google or anyone else; it simply gives us the right to safely redistribute and use your changes. ### Mandatory Google Disclaimer I (Martin von Zweigbergk, ) started Jujutsu as a hobby project in late 2019, and it has evolved into my full-time project at Google, with several other Googlers (now) assisting development in various capacities. That said, **this is not a Google product**. ## License Jujutsu is available as Open Source Software, under the Apache 2.0 license. See [LICENSE](./LICENSE) for details about copyright and redistribution. jj-lib-proc-macros-0.22.0/src/content_hash.rs000064400000000000000000000124121046102023000171110ustar 00000000000000use proc_macro2::Ident; use proc_macro2::TokenStream; use quote::format_ident; use quote::quote; use quote::quote_spanned; use syn::parse_quote; use syn::spanned::Spanned; use syn::Data; use syn::Field; use syn::Fields; use syn::GenericParam; use syn::Generics; use syn::Index; use syn::Type; pub fn add_trait_bounds(mut generics: Generics) -> Generics { for param in &mut generics.params { if let GenericParam::Type(ref mut type_param) = *param { type_param .bounds .push(parse_quote!(::jj_lib::content_hash::ContentHash)); } } generics } pub fn generate_hash_impl(data: &Data) -> TokenStream { match *data { Data::Struct(ref data) => match data.fields { Fields::Named(ref fields) => { let hash_statements = fields.named.iter().map(|f| { let field_name = &f.ident; let ty = &f.ty; quote_spanned! {ty.span()=> <#ty as ::jj_lib::content_hash::ContentHash>::hash( &self.#field_name, state); } }); quote! { #(#hash_statements)* } } Fields::Unnamed(ref fields) => { let hash_statements = fields.unnamed.iter().enumerate().map(|(i, f)| { let index = Index::from(i); let ty = &f.ty; quote_spanned! {ty.span() => <#ty as ::jj_lib::content_hash::ContentHash>::hash(&self.#index, state); } }); quote! { #(#hash_statements)* } } Fields::Unit => { quote! {} } }, // Generates a match statement with a match arm and hash implementation // for each of the variants in the enum. Data::Enum(ref data) => { let match_hash_statements = data.variants.iter().enumerate().map(|(i, v)| { let variant_id = &v.ident; match &v.fields { Fields::Named(fields) => { let bindings = enum_bindings(fields.named.iter()); let hash_statements = hash_statements_for_enum_fields(i, fields.named.iter()); quote_spanned! {v.span() => Self::#variant_id{ #(#bindings),* } => { #(#hash_statements)* } } } Fields::Unnamed(fields) => { let bindings = enum_bindings(fields.unnamed.iter()); let hash_statements = hash_statements_for_enum_fields(i, fields.unnamed.iter()); quote_spanned! {v.span() => Self::#variant_id( #(#bindings),* ) => { #(#hash_statements)* } } } Fields::Unit => { let ix = index_to_ordinal(i); quote_spanned! {v.span() => Self::#variant_id => { ::jj_lib::content_hash::ContentHash::hash(&#ix, state); } } } } }); quote! { match self { #(#match_hash_statements)* } } } Data::Union(_) => unimplemented!("ContentHash cannot be derived for unions."), } } // The documentation for `ContentHash` specifies that the hash impl for each // enum variant should hash the ordinal number of the enum variant as a little // endian u32 before hashing the variant's fields, if any. fn index_to_ordinal(ix: usize) -> u32 { u32::try_from(ix).expect("The number of enum variants overflows a u32.") } fn enum_bindings_with_type<'a>(fields: impl IntoIterator) -> Vec<(Type, Ident)> { fields .into_iter() .enumerate() .map(|(i, f)| { // If the field is named, use the name, otherwise generate a placeholder name. ( f.ty.clone(), f.ident.clone().unwrap_or(format_ident!("field_{}", i)), ) }) .collect::>() } fn enum_bindings<'a>(fields: impl IntoIterator) -> Vec { enum_bindings_with_type(fields) .into_iter() .map(|(_, b)| b) .collect() } fn hash_statements_for_enum_fields<'a>( index: usize, fields: impl IntoIterator, ) -> Vec { let ix = index_to_ordinal(index); let typed_bindings = enum_bindings_with_type(fields); let mut hash_statements = Vec::with_capacity(typed_bindings.len() + 1); hash_statements.push(quote! {::jj_lib::content_hash::ContentHash::hash(&#ix, state);}); for (ty, b) in typed_bindings.iter() { hash_statements.push(quote_spanned! {b.span() => <#ty as ::jj_lib::content_hash::ContentHash>::hash(#b, state); }); } hash_statements } jj-lib-proc-macros-0.22.0/src/lib.rs000064400000000000000000000023111046102023000151770ustar 00000000000000mod content_hash; extern crate proc_macro; use quote::quote; use syn::parse_macro_input; use syn::DeriveInput; /// Derives the `ContentHash` trait for a struct by calling `ContentHash::hash` /// on each of the struct members in the order that they're declared. All /// members of the struct must implement the `ContentHash` trait. #[proc_macro_derive(ContentHash)] pub fn derive_content_hash(input: proc_macro::TokenStream) -> proc_macro::TokenStream { let input = parse_macro_input!(input as DeriveInput); // The name of the struct. let name = &input.ident; // Generate an expression to hash each of the fields in the struct. let hash_impl = content_hash::generate_hash_impl(&input.data); // Handle structs and enums with generics. let generics = content_hash::add_trait_bounds(input.generics); let (impl_generics, ty_generics, where_clause) = generics.split_for_impl(); let expanded = quote! { #[automatically_derived] impl #impl_generics ::jj_lib::content_hash::ContentHash for #name #ty_generics #where_clause { fn hash(&self, state: &mut impl digest::Update) { #hash_impl } } }; expanded.into() }