- Bug fixes and test cases for them
- New algorithms (with tests, documentation, complexity notes, and a reference)
- Documentation, examples, performance work
- Concept refinements (handle with care as these are API-visible)
Clone the Boost superproject:
git clone --depth 1 https://github.com/boostorg/boost
cd boost
git submodule update --init --depth 1
./bootstrap.sh
./b2 headersThen replace libs/int256/ with your fork:
rm -rf libs/int256
git clone https://github.com/<you>/int256 libs/int256
cd libs/int256
git remote add upstream https://github.com/boostorg/int256- Headers only:
./b2 headersfrom boost root - All tests:
./b2fromlibs/int256/test - Single test:
./b2 github_issue_207fromlibs/int256/test - Different C++ standard:
./b2 cxxstd=20 - Different compiler:
./b2 toolset=clang
- Fork, branch from
develop, PR back todevelop - One logical change per PR; rebase before requesting review
- Tests required for new features and bug fixes
- Open (non-draft) PRs are assumed ready for review. Use GitHub's Draft state while iterating, then mark the PR as Ready for review when you want maintainers to look at it.
- A maintainer will review within ~2 weeks (see Maintainers below)
- Squash on merge by default
Before a PR is merged, all of the following must hold:
- CI is green on the full matrix.
- New behavior has tests.
- Bug fixes have a regression test.
- Documentation under doc/ is updated if the public API changed.
- No new compiler warnings on the supported toolchains.
- The PR is rebased on current
developwith a clean commit history. - The principal maintainer has approved.
- Search existing issues first
- Note compiler, version, OS, Boost version
- Minimal reproducer on Compiler Explorer
- Expected Output versus Actual Output is explained.
See SECURITY.md.
By contributing, you agree your contribution is licensed under the Boost Software License 1.0.