Skip to content

Latest commit

 

History

History
157 lines (105 loc) · 5.04 KB

CONTRIBUTING.md

File metadata and controls

157 lines (105 loc) · 5.04 KB

Contributing to wee_alloc

Hi! We'd love to have your contributions! If you want help or mentorship, reach out to us in a GitHub issue, or ping fitzgen in #rust-wasm on irc.mozilla.org and introduce yourself.

Code of Conduct

We abide by the Rust Code of Conduct and ask that you do as well.

Building and Testing

Prerequisites

Ensure you have the wasm32-unknown-unknown target installed with rustup:

$ rustup update
$ rustup target add wasm32-unknown-unknown --toolchain nightly

Ensure that you have wasm-gc installed:

$ cargo install --git https://github.com/alexcrichton/wasm-gc

Ensure that you have cargo-readme installed:

$ cargo install cargo-readme

Finally, ensure that you have binaryen's wasm-opt installed.

Type Checking

The check.sh script essentially runs cargo check in each crate with all the various features and targets.

$ ./check.sh

Building

The build.sh script essentially runs cargo build in each crate with all the various features and targets.

$ ./build.sh

Testing

The test.sh script essentially runs cargo test in each crate with all the various features and targets.

$ ./test.sh

Automatic Code Formatting

We use rustfmt to enforce a consistent code style across the whole code base.

You can install the latest version of rustfmt with this command:

$ rustup update
$ rustup component add rustfmt-preview

Ensure that ~/.rustup/toolchains/$YOUR_HOST_TARGET/bin/ is on your $PATH.

Once that is taken care of, you can (re)format all code by running this command from the root of the repository:

$ cargo fmt --all

Pull Requests

All pull requests must be reviewed and approved of by at least one team member before merging. See Contributions We Want for details on what should be included in what kind of pull request.

Contributions We Want

  • Bug fixes! Include a regression test.

  • Code size reductions! Include before and after .wasm sizes (as reported by build.sh) in your commit or pull request message.

  • Performance improvements! Include before and after #[bench] numbers, or write a new #[bench] that exercises the code path, if none exists already.

If you make two of these kinds of contributions, you should seriously consider joining our team!

Where we need help:

  • Issues labeled "help wanted" are issues where we could use a little help from you.

  • Issues labeled "mentored" are issues that don't really involve any more investigation, just implementation. We've outlined what needs to be done, and a team_ member has volunteered to help whoever claims the issue implement it, and get the implementation merged.

  • Issues labeled "good first issue" are issues where fixing them would be a great introduction to the code base.

Team

fitzgen pepyakin DrGoldfire ZackPierce
fitzgen pepyakin DrGoldfire ZackPierce

Larger, more nuanced decisions about design, architecture, breaking changes, trade offs, etc are made by team consensus. In other words, decisions on things that aren't straightforward improvements or bug fixes to things that already exist in wee_alloc. If consensus can't be made, then fitzgen has the last word.

We need more team members! Drop a comment on this issue if you are interested in joining.