Ensure that core and core-test-framework crates support no_std
Maintainers usually reply within 2 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 58/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- rust
- Domain
- build-system
Research direction
Start by inspecting the core and core-test-framework crate manifests and the workspace configuration. Build, test, and benchmark each crate with --no-default-features, add the default-enabled std feature, and verify that the full workspace still builds, tests, and benchmarks without regressions in its default configuration.
Written by the indexing model from the issue text.
Description
Summary:
The purpose of this sub-issue is to implement sufficient no_std changes such that the core and core-test-framework crates are able to be built, tested, and benchmarked in no_std.
Scope:
The expected changes for this initial task may involve changes to other crates, and the workspace, to support required changes to crate dependencies, and to create a baseline for all crates to implement the new functionality uniformly.
Acceptance Criteria:
- A new feature will be added that positively enables std, which will be on by default
- the --no-default-features flag will be used to enforce no_std at build time
coreandcore-test-frameworkcrates must build/test/bench, individually, with --no-default-features- All crates must continue to build/test/bench, with no regressions, in default config.
- Building other crates or the entire workspace with --no-default-features is unsupported, with no required behavior associated with acceptance of this sub-issue
- Dominant language
- Rust
- Stars
- 25
- Forks
- 18
- Avg merge
- 14d 10h
- Merged PRs (30d)
- 5
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from bcgit/bc-rust
-
Improve docs in FactoriesPossibly taken @pollychen-lab claimed this 3 days ago. Opendocumentation good first issue help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
bcgit/bc-rust#161 · 1 reaction ·
Maintainers usually reply within 2 days
-
good first issue refactor
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 2 days
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
bcgit/bc-rust#163 · 2 comments ·
Maintainers usually reply within 2 days
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
Maintainers usually reply within 2 days
-
documentation good first issue refactor
Difficulty 3/5 1-2 days Newbie friendliness 55/100
Maintainers usually reply within 2 days
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
maplibre/maplibre-tile-spec#1844 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 92/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
rust-windowing/winit#4731 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
area:cli bug priority:high
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day