Codestin Search App

amboar · 2025-07-22T23:59:53Z

Some environments prefer to avoid alloc in addition to building with no_std.

amboar · 2025-07-23T00:05:16Z

Hello! This PR follows from the associated discussion thread:

I expect it will need (quite?) a few iterations - I'm happy to make progress by mining it for ideas that we can split into separate patches or PRs if necessary.

wcampbell0x2a · 2025-07-23T04:16:30Z

552d6e7

It would be great if this commit has a passing test.

cff993a

I'm confused about the intent of this? I originally added this so that on embedded platforms you wouldn't end up with large string sections. And instead a simple return.

amboar · 2025-07-24T03:24:00Z

552d6e7

It would be great if this commit has a passing test.

I'll make a separate PR for it and add a test case.

cff993a

I'm confused about the intent of this? I originally added this so that on embedded platforms you wouldn't end up with large string sections. And instead a simple return.

That's a fair concern, because I don't think I described what I was actually up to there. The underlying motivation was around updating the CI workflow to allow --all-features to produce a "regular"-looking build, but the negative behaviour of the no-assert-string feature gets in the way.

I figured we could keep the intent of no-assert-string without requiring the feature by taking advantage of the deku_error!() macro from 21d8506. However, I hadn't yet made use of the assert attribute to appreciate the impacts.

For something to experiment with I grabbed backhand. As it's regular userspace I'm not sure it gives the greatest appreciation for the problem, but it's start.

Rather than pull out the no-assert-string feature entirely as I did in cff993a I replaced it with descriptive-errors, which gives us a couple of things:

What I feel is desirable behaviour if we pass --all-features to the build
The ability to control the error message behaviour independent of the proposed alloc feature.

Here's the impact after switching backhand to my local deku tree:

[I] 0 andrew@heihei ~/s/g/w/backhand (master)> git grep '^deku ='
backhand/Cargo.toml:deku = { path = "/home/andrew/src/github.com/sharksforarms/deku", default-features = false, features = ["std"] }

Given deku's features are explicitly specified by backhand, I force-enabled descriptive-errors in the build invocation to maintain current behaviour:

[I] 0 andrew@heihei ~/s/g/w/backhand (master)> cargo build --release --features="deku/descriptive-errors"
    Finished `release` profile [optimized] target(s) in 0.06s
[I] 0 andrew@heihei ~/s/g/w/backhand (master)> bloaty -d sections target/release/unsquashfs-backhand | grep '[.]rodata$'
   8.5%   530Ki  10.7%   530Ki    .rodata
[I] 0 andrew@heihei ~/s/g/w/backhand (master)> readelf --string-dump .rodata target/release/unsquashfs-backhand | grep --color=never --only-matching -E "Field failed assertion.{5}"
Field failed assertion: Dir
Field failed assertion: Sup
Field failed assertion: Sup
Field failed assertion: Sup
Field failed assertion: Ext
Field failed assertion: Bas
Field failed assertion: Dir

For comparison, without enabling descriptive-features, I see:

[I] 0 andrew@heihei ~/s/g/w/backhand (master)> cargo build --release
    Finished `release` profile [optimized] target(s) in 0.05s
[I] 0 andrew@heihei ~/s/g/w/backhand (master)> bloaty -d sections target/release/unsquashfs-backhand | grep '[.]rodata$'
   8.5%   529Ki  10.7%   529Ki    .rodata
[I] 0 andrew@heihei ~/s/g/w/backhand (master)> readelf --string-dump .rodata target/release/unsquashfs-backhand | grep --color=never --only-matching -E "Field failed assertion.{5}"
Field failed assertionevent
Field failed assertionCould

It appears the string coalescing behaves (mostly) as I'd expect, given we discard the non-constant portions of the strings in deku_error!() when disabling descriptive-strings.

I can squash the descriptive-errors patch into cff993a if you're okay with that approach and the analysis here (I feel it's okay, as it still gives us the control we need)?

amboar · 2025-07-24T04:23:04Z

552d6e7

It would be great if this commit has a passing test.

I'll make a separate PR for it and add a test case.

Hmm, having poked a bit I'm not sure I have a need for the patch yet. I'll drop it for now. I expect I triggered the panic at some point to prompt the rework, but I'll bring it back when I need it.

amboar · 2025-08-08T00:40:42Z

Any thoughts or feelings on this one so far? I'm wary of the "ugh" factor of the size and tediousness of some of the current approaches. Let me know if I should rework it to address either (even just for the sake of making the changes easier to consume for review).

wcampbell0x2a

lgtm!

amboar · 2025-08-12T04:15:14Z

@wcampbell0x2a thanks! Backing up slightly:

I can squash the descriptive-errors patch into cff993a if you're okay with that approach and the analysis here (I feel it's okay, as it still gives us the control we need)?

I hadn't actually gone ahead with that as I was waiting on your feedback. However, I'll do so shortly given my impression that the discussion above was reasonable. Let me know otherwise.

wcampbell0x2a · 2025-08-12T04:19:01Z

@wcampbell0x2a thanks! Backing up slightly:

I can squash the descriptive-errors patch into cff993a if you're okay with that approach and the analysis here (I feel it's okay, as it still gives us the control we need)?

I hadn't actually gone ahead with that as I was waiting on your feedback. However, I'll do so shortly given my impression that the discussion above was reasonable. Let me know otherwise.

Oh yes. I think I'm in favor of that patch.

The expectation failed, and further, dead_code triggered on the enum type itself: error: enum `Data` is never used --> tests/test_own_impl.rs:5:14 | 5 | pub enum Data { | ^^^^ | = note: `-D dead-code` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(dead_code)]` error: this lint expectation is unfulfilled --> tests/test_own_impl.rs:8:18 | 8 | #[expect(dead_code)] | ^^^^^^^^^ | = note: `-D unfulfilled-lint-expectations` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(unfulfilled_lint_expectations)]` Signed-off-by: Andrew Jeffery <[email protected]>

The type is mentioned in commentary on a separate struct, so keep it for now. Addresses: error: enum `NestedEnum2` is never used --> tests/test_alloc.rs:28:6 | 28 | enum NestedEnum2 { | ^^^^^^^^^^^ | = note: `-D dead-code` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(dead_code)]` Signed-off-by: Andrew Jeffery <[email protected]>

The struct was introduced in 59fc760 ("Add count Vec<u8> Specializations (sharksforarms#481)") but yields: error: struct `CountFromCtxWrapper` is never constructed --> benches/deku.rs:135:16 | 135 | pub struct CountFromCtxWrapper { | ^^^^^^^^^^^^^^^^^^^ | = note: `-D dead-code` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(dead_code)]` Mark it as expected for now. Signed-off-by: Andrew Jeffery <[email protected]>

There's too much use of BitVec and the like for it to be sensible to separate them. Signed-off-by: Andrew Jeffery <[email protected]>

Don't make it harder than necessary to use no_std. Signed-off-by: Andrew Jeffery <[email protected]>

amboar · 2025-08-13T03:00:10Z

Okay, I've tidied up the descriptive-errors patch and squashed it into the earlier commit. A few new fixes appear earlier in the series. I hit some new warnings, likely a result of upgrading to the latest rust stable release.

I've also updated the changelog in both 721e24e and 2478ffc. Hopefully that's not a hindrance!

sharksforarms

Thanks! Looks like a good cleanup of some testing/errors too

Enable use of deku in tightly constrained environments. Signed-off-by: Andrew Jeffery <[email protected]>

Replace DekuError::AssertionNoStr with DekuError::Assertion, in concert with the deku_error!() macro. deku_error!() discards dynamic formatting when the capability unavailable, usually due to feature selection. Discarding the unique portion of error strings provides the compiler the opportunity to coalesce string constants, reducing space required for .rodata in the spirit of AssertionNoStr. Introducing descriptive-errors and enabling it by default gives us a couple of things: - Maintains the current behaviour where `--features no-assert-string` _isn't_ specified, - What I feel is desirable behaviour if we pass --all-features to `cargo build`, where the no-assert-string feature didn't, and - The ability to control the error message behaviour (though alloc is required for descriptive messages) Demonstrating the impact on wcampbell0x2a/backhand, with descriptive-errors enabled[^1] we have: $ cargo build --release --features="deku/descriptive-errors" Finished `release` profile [optimized] target(s) in 0.06s $ bloaty -d sections target/release/unsquashfs-backhand | grep '[.]rodata$' 8.5% 530Ki 10.7% 530Ki .rodata $ readelf --string-dump .rodata target/release/unsquashfs-backhand | grep --color=never --only-matching -E "Field failed assertion.{5}" Field failed assertion: Dir Field failed assertion: Sup Field failed assertion: Sup Field failed assertion: Sup Field failed assertion: Ext Field failed assertion: Bas Field failed assertion: Dir $ And without: $ cargo build --release Finished `release` profile [optimized] target(s) in 0.05s $ bloaty -d sections target/release/unsquashfs-backhand | grep '[.]rodata$' 8.5% 529Ki 10.7% 529Ki .rodata $ readelf --string-dump .rodata target/release/unsquashfs-backhand | grep --color=never --only-matching -E "Field failed assertion.{5}" Field failed assertionevent Field failed assertionCould $ [^1]: For the purpose of clarity in the demonstration I temporarily changed the patch such that descriptive-errors _isn't_ in the default features Signed-off-by: Andrew Jeffery <[email protected]>

Signed-off-by: Andrew Jeffery <[email protected]>

amboar · 2025-08-15T00:14:46Z

Thanks @sharksforarms and @wcampbell0x2a !

sharksforarms · 2025-08-15T13:13:40Z

Thank you for the contribution!

`no-assert-string` was replaced with `descriptive-errors` back in sharksforarms#582

`no-assert-string` was replaced with `descriptive-errors` back in #582 Co-authored-by: Emmanuel Thompson <[email protected]>

amboar force-pushed the no-alloc branch from e1e2eb7 to a37cc74 Compare July 24, 2025 04:25

wcampbell0x2a previously approved these changes Aug 12, 2025

View reviewed changes

amboar added 5 commits August 13, 2025 11:14

features: Require alloc for bits feature

26e06f6

There's too much use of BitVec and the like for it to be sensible to separate them. Signed-off-by: Andrew Jeffery <[email protected]>

tree-wide: Prefer core exports where possible

5c5fa9e

Don't make it harder than necessary to use no_std. Signed-off-by: Andrew Jeffery <[email protected]>

amboar dismissed wcampbell0x2a’s stale review via f20bf84 August 13, 2025 02:44

amboar force-pushed the no-alloc branch from a37cc74 to f20bf84 Compare August 13, 2025 02:44

sharksforarms previously approved these changes Aug 13, 2025

View reviewed changes

Comment thread deku-derive/src/macros/deku_read.rs Outdated

amboar and others added 4 commits August 14, 2025 11:20

Don't require alloc feature

5dca0c7

Enable use of deku in tightly constrained environments. Signed-off-by: Andrew Jeffery <[email protected]>

github: Test various feature modes

dbb5313

Signed-off-by: Andrew Jeffery <[email protected]>

Allow ensure_no_std to run without alloc

d704e26

amboar dismissed sharksforarms’s stale review via d704e26 August 14, 2025 01:55

amboar force-pushed the no-alloc branch from f20bf84 to d704e26 Compare August 14, 2025 01:55

sharksforarms reviewed Aug 14, 2025

View reviewed changes

Comment thread tests/test_enum.rs

sharksforarms approved these changes Aug 14, 2025

View reviewed changes

amboar mentioned this pull request Aug 14, 2025

Handle bit order padding in Writer::finalize #595

Merged

sharksforarms merged commit e5363bc into sharksforarms:master Aug 15, 2025
7 of 9 checks passed

github-actions Bot mentioned this pull request Oct 15, 2025

chore: release v0.20.0 #610

Merged

seritools added a commit to seritools/deku that referenced this pull request Dec 15, 2025

docs: update stale feature flag documentation

925be4b

`no-assert-string` was replaced with `descriptive-errors` back in sharksforarms#582

seritools mentioned this pull request Dec 15, 2025

docs: update stale feature flag documentation #637

Merged

wcampbell0x2a pushed a commit that referenced this pull request Jan 23, 2026

docs: update stale feature flag documentation (#637)

f8e86b4

`no-assert-string` was replaced with `descriptive-errors` back in #582 Co-authored-by: Emmanuel Thompson <[email protected]>

Uh oh!

Conversation

amboar commented Jul 22, 2025

Uh oh!

amboar commented Jul 23, 2025

Uh oh!

wcampbell0x2a commented Jul 23, 2025

Uh oh!

amboar commented Jul 24, 2025

Uh oh!

amboar commented Jul 24, 2025

Uh oh!

amboar commented Aug 8, 2025

Uh oh!

wcampbell0x2a left a comment

Choose a reason for hiding this comment

Uh oh!

amboar commented Aug 12, 2025

Uh oh!

wcampbell0x2a commented Aug 12, 2025

Uh oh!

amboar commented Aug 13, 2025

Uh oh!

sharksforarms left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

amboar commented Aug 15, 2025

Uh oh!

sharksforarms commented Aug 15, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants