diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 65fb5fab0..ecd27d397 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,9 +1,9 @@ -# Contributing to ethers-rs +# Contributing to Alloy :balloon: Thanks for your help improving the project! We are so happy to have you! -There are opportunities to contribute to ethers-rs at any level. It doesn't +There are opportunities to contribute to Alloy at any level. It doesn't matter if you are just getting started with Rust or are the most weathered expert, we can use your help. @@ -19,7 +19,7 @@ please join us! ## Conduct -The ethers-rs project adheres to the [Rust Code of Conduct][coc]. This describes +The Alloy project adheres to the [Rust Code of Conduct][coc]. This describes the _minimum_ behavior expected from all contributors. Instances of violations of the Code of Conduct can be reported by contacting the project team at [james@prestwich](mailto:james@prestwi.ch). @@ -31,7 +31,7 @@ of the Code of Conduct can be reported by contacting the project team at For any issue, there are fundamentally three ways an individual can contribute: 1. By opening the issue for discussion: For instance, if you believe that you - have uncovered a bug in ethers-rs, creating a new issue in the ethers-rs + have uncovered a bug in Alloy, creating a new issue in the Alloy issue tracker is the way to report it. 2. By helping to triage the issue: This can be done by providing @@ -42,7 +42,7 @@ For any issue, there are fundamentally three ways an individual can contribute: 3. By helping to resolve the issue: Typically this is done either in the form of demonstrating that the issue reported is not a problem after all, or more often, by opening a Pull Request that changes some bit of something in - ethers-rs in a concrete and reviewable manner. + Alloy in a concrete and reviewable manner. **Anybody can participate in any stage of contribution**. We urge you to participate in the discussion around bugs and participate in reviewing PRs. @@ -57,7 +57,7 @@ PR that helps others avoid the problems that you encountered. ### Submitting a Bug Report -When opening a new issue in the ethers-rs issue tracker, users will be presented +When opening a new issue in the Alloy issue tracker, users will be presented with a [basic template][template] that should be filled in. If you believe that you have uncovered a bug, please fill out this form, following the template to the best of your ability. Do not worry if you cannot answer every detail, just @@ -69,7 +69,7 @@ test case we can use to recreate the problem on our own. If we cannot recreate the issue, it becomes impossible for us to fix. In order to rule out the possibility of bugs introduced by userland code, test -cases should be limited, as much as possible, to using only ethers-rs APIs. +cases should be limited, as much as possible, to using only Alloy APIs. See [How to create a Minimal, Complete, and Verifiable example][mcve]. @@ -101,12 +101,12 @@ In the majority of cases, issues are resolved by opening a Pull Request. The process for opening and reviewing a Pull Request is similar to that of opening and triaging issues, but carries with it a necessary review and approval workflow that ensures that the proposed changes meet the minimal quality and -functional guidelines of the ethers-rs project. +functional guidelines of the Alloy project. ## Pull Requests Pull Requests are the way concrete changes are made to the code, documentation, -and dependencies in the ethers-rs repository. +and dependencies in the Alloy repository. Even tiny pull requests (e.g., one character pull request fixing a typo in API documentation) are greatly appreciated. Before making a large change, it is @@ -118,7 +118,7 @@ merged. This section lists some commonly needed commands. -``` +```sh cargo check --all-features cargo +nightly fmt --all cargo build --all-features @@ -129,9 +129,9 @@ cargo +nightly clippy --all-features ### Tests If the change being proposed alters code (as opposed to only documentation for -example), it is either adding new functionality to ethers-rs or it is fixing +example), it is either adding new functionality to Alloy or it is fixing existing, broken functionality. In both of these cases, the pull request should -include one or more tests to ensure that ethers-rs does not regress in the +include one or more tests to ensure that Alloy does not regress in the future. #### Unit Tests @@ -221,9 +221,9 @@ however, will stay intact on the Pull Request page. ## Reviewing Pull Requests -**Any ethers-rs community member is welcome to review any pull request**. +**Any Alloy community member is welcome to review any pull request**. -All ethers-rs contributors who choose to review and provide feedback on Pull +All Alloy contributors who choose to review and provide feedback on Pull Requests have a responsibility to both the project and the individual making the contribution. Reviews and feedback must be helpful, insightful, and geared towards improving the contribution as opposed to simply blocking it. If there @@ -250,8 +250,8 @@ perfect grammar, or exact style matches. Do not succumb to that temptation. Focus first on the most significant aspects of the change: -1. Does this change make sense for ethers-rs? -2. Does this change make ethers-rs better, even if only incrementally? +1. Does this change make sense for Alloy? +2. Does this change make Alloy better, even if only incrementally? 3. Are there clear bugs or larger scale issues that need attending to? 4. Is the commit message readable and correct? If it contains a breaking change is it clear enough? @@ -268,7 +268,7 @@ change over time. The first impression you give to a new contributor never does. Nits (requests for small changes that are not essential) are fine, but try to avoid stalling the Pull Request. Most nits can typically be fixed by the -ethers-rs Collaborator landing the Pull Request but they can also be an +Alloy Collaborator landing the Pull Request but they can also be an opportunity for the contributor to learn a bit more about the project. It is always good to clearly indicate nits when you comment: e.g. @@ -282,8 +282,8 @@ with the appropriate reason to keep the conversation flow concise and relevant. Be aware that _how_ you communicate requests and reviews in your feedback can have a significant impact on the success of the Pull Request. Yes, we may land -a particular change that makes ethers-rs better, but the individual might just -not want to have anything to do with ethers-rs ever again. The goal is not just +a particular change that makes Alloy better, but the individual might just +not want to have anything to do with Alloy ever again. The goal is not just having good code. ### Abandoned or Stalled Pull Requests diff --git a/Cargo.toml b/Cargo.toml index 574734563..83b29080d 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -1,14 +1,16 @@ [workspace] -resolver = "2" members = ["crates/*"] +resolver = "2" [workspace.package] +version = "0.1.0" edition = "2021" -rust-version = "1.65" # Remember to update .clippy.toml and workflows/ci.yml -authors = [] +rust-version = "1.65" +authors = ["Alloy Contributors"] license = "MIT OR Apache-2.0" -homepage = "https://github.com/ethers-rs/core" -repository = "https://github.com/ethers-rs/core" +homepage = "https://github.com/alloy-rs/core" +repository = "https://github.com/alloy-rs/core" +exclude = ["benches/", "tests/"] [workspace.metadata.docs.rs] all-features = true @@ -16,12 +18,12 @@ rustdoc-args = ["--cfg", "docsrs"] [workspace.dependencies] # workspace crates -ethers-dyn-abi = { version = "0.1.0", path = "crates/dyn-abi", default-features = false } -ethers-primitives = { version = "0.1.0", path = "crates/primitives", default-features = false } -ethers-rlp = { version = "0.1.0", path = "crates/rlp", default-features = false } -ethers-rlp-derive = { version = "0.1.0", path = "crates/rlp-derive", default-features = false } -ethers-sol-macro = { version = "0.1.0", path = "crates/sol-macro", default-features = false } -ethers-sol-types = { version = "0.1.0", path = "crates/sol-types", default-features = false } +alloy-dyn-abi = { version = "0.1.0", path = "crates/dyn-abi", default-features = false } +alloy-primitives = { version = "0.1.0", path = "crates/primitives", default-features = false } +alloy-rlp = { version = "0.1.0", path = "crates/rlp", default-features = false } +alloy-rlp-derive = { version = "0.1.0", path = "crates/rlp-derive", default-features = false } +alloy-sol-macro = { version = "0.1.0", path = "crates/sol-macro", default-features = false } +alloy-sol-types = { version = "0.1.0", path = "crates/sol-types", default-features = false } syn-solidity = { version = "0.1.0", path = "crates/syn-solidity", default-features = false } ruint = { version = "1.8.0", git = "https://github.com/recmo/uint", default-features = false } diff --git a/README.md b/README.md index 80ce1387f..951821d4e 100644 --- a/README.md +++ b/README.md @@ -1,84 +1,75 @@ -
(name: &Ident, fields: &Parameters
) -> TokenStream {
quote! {
type UnderlyingSolTuple = (#(#tys,)*);
- type UnderlyingRustTuple = (#(<#tys2 as ::ethers_sol_types::SolType>::RustType,)*);
+ type UnderlyingRustTuple = (#(<#tys2 as ::alloy_sol_types::SolType>::RustType,)*);
#[automatically_derived]
impl ::core::convert::From<#name> for UnderlyingRustTuple {
diff --git a/crates/sol-macro/src/lib.rs b/crates/sol-macro/src/lib.rs
index 81e1b518f..da164ed68 100644
--- a/crates/sol-macro/src/lib.rs
+++ b/crates/sol-macro/src/lib.rs
@@ -1,7 +1,7 @@
-//! # ethers-sol-macro
+//! # alloy-sol-macro
//!
//! This crate provides the [`sol`][sol!] procedural macro, which parses
-//! Solidity syntax to generate types that implement [`ethers-sol-types`]
+//! Solidity syntax to generate types that implement [`alloy-sol-types`]
//! traits.
//!
//! Refer to the [macro's documentation][sol!] for more information.
@@ -17,7 +17,7 @@ use proc_macro::TokenStream;
mod expand;
mod utils;
-/// Parses Solidity syntax to generate types that implement [`ethers-sol-types`]
+/// Parses Solidity syntax to generate types that implement [`alloy-sol-types`]
/// traits.
///
/// These types may then be used for safe [ABI] and [EIP-712] encoding and
@@ -25,15 +25,15 @@ mod utils;
///
/// [ABI]: https://docs.soliditylang.org/en/latest/abi-spec.html
/// [EIP-712]: https://eips.ethereum.org/EIPS/eip-712
-/// [`ethers-sol-types`]: https://docs.rs/ethers-sol-types
+/// [`alloy-sol-types`]: https://docs.rs/alloy-sol-types
///
/// # Examples
///
/// Note: the following examples cannot tested here because the generated code
-/// references `ethers-sol-types`, so they are [tested in that crate][tests] and
+/// references `alloy-sol-types`, so they are [tested in that crate][tests] and
/// included with `include_str!` in this doc instead.
///
-/// [tests]: https://github.com/ethers-rs/core/tree/main/crates/sol-types/tests/
+/// [tests]: https://github.com/alloy-rs/core/tree/main/crates/sol-types/tests/
///
/// ## Structs and enums
/// ```ignore
diff --git a/crates/sol-types/Cargo.toml b/crates/sol-types/Cargo.toml
index 18e0a3753..9f92524c2 100644
--- a/crates/sol-types/Cargo.toml
+++ b/crates/sol-types/Cargo.toml
@@ -1,25 +1,25 @@
[package]
-name = "ethers-sol-types"
-version = "0.1.0"
-description = "Ethereum ABI encoding and decoding, with static typing"
-readme = "README.md"
+name = "alloy-sol-types"
+description = "Compile-time ABI and EIP-712 implementations"
keywords = ["ethereum", "abi", "encoding", "evm", "solidity"]
-categories = ["encoding", "cryptography::cryptocurrencies"]
+categories = ["no-std", "encoding", "cryptography::cryptocurrencies"]
+homepage = "https://github.com/alloy-rs/core/tree/main/crates/sol-types"
+version.workspace = true
edition.workspace = true
rust-version.workspace = true
authors.workspace = true
license.workspace = true
-homepage.workspace = true
repository.workspace = true
+exclude.workspace = true
[package.metadata.docs.rs]
all-features = true
rustdoc-args = ["--cfg", "docsrs"]
[dependencies]
-ethers-primitives.workspace = true
-ethers-sol-macro.workspace = true
+alloy-primitives.workspace = true
+alloy-sol-macro.workspace = true
hex = { workspace = true, features = ["alloc"] }
@@ -31,5 +31,5 @@ trybuild = "1.0"
[features]
default = ["std", "hex/alloc"]
-std = ["ethers-primitives/std", "hex/std", "serde?/std"]
-eip712-serde = ["dep:serde", "serde?/alloc", "ethers-primitives/serde"]
+std = ["alloy-primitives/std", "hex/std", "serde?/std"]
+eip712-serde = ["dep:serde", "serde?/alloc", "alloy-primitives/serde"]
diff --git a/crates/sol-types/README.md b/crates/sol-types/README.md
index 3251d8858..6328374ad 100644
--- a/crates/sol-types/README.md
+++ b/crates/sol-types/README.md
@@ -1,14 +1,13 @@
-# ethers-sol-types
+# alloy-sol-types
-Compile-time representation of Ethereum's type system with ABI coding and
-EIP-712 support.
+Compile-time representation of Ethereum's type system with ABI and EIP-712
+support.
This crate provides a developer-friendly interface to Ethereum's type system,
-by representing Solidity types. See [type_system.md] for a rundown, and the
+by representing Solidity types. See [type_system.md](./type_system.md) for a rundown, and the
[crate docs] for more information
-[type_system.md]: https://github.com/ethers-rs/core/blob/main/crates/abi/type_system.md
-[crate docs]: https://docs.rs/ethers-sol-types/latest/ethers_sol_types/
+[crate docs]: https://docs.rs/alloy-sol-types/latest/alloy_sol_types/
### Features
diff --git a/crates/sol-types/src/coder/decoder.rs b/crates/sol-types/src/coder/decoder.rs
index d214a4c71..1e203be2d 100644
--- a/crates/sol-types/src/coder/decoder.rs
+++ b/crates/sol-types/src/coder/decoder.rs
@@ -1,5 +1,5 @@
// Copyright 2015-2020 Parity Technologies
-// Copyright 2023-2023 Ethers-rs Team
+// Copyright 2023-2023 Alloy Contributors
//
// Licensed under the Apache License, Version 2.0