[alejandro-vaz]

this PR adds a small private procedural macro that allows for syntax inserting like the add-syntax::prepend macro does

it reduces code bloat by conditionally inserting syntax where needed, ensuring the codebase is DRY. unblocks #754 and #762

other maintenance changes

1. upgrades callgrind from 0.14 to 0.16
2. refactors workspace TOML variables for clarity and consistency
3. orders feature dependencies on alphabetical order
4. explicitly notes in the readme that proptest requires std
5. adds missing metadata to the fuzzer
6. compacts one block with the new macro on lib.rs

[Chandana5599]

Thanks for the suggestion! I’ve reviewed PR #764 and understand the simplification. I’ll update PR #762 to use the conditional may_dangle attribute and the syntax macro once the macro is available in the base branch.

[jdm]

Won't this make it impossible to publish a new version of smallvec?

[alejandro-vaz]

yes, I just checked with cargo package. but because it uses a path import on ./Cargo.toml

I'll find another way

[jdm]

Building a separate crate inside of the build script for this crate is wild. What's the problem with using the proc macro crate as a real dependency that gets published? I don't think trying to work around that is a good idea.

[alejandro-vaz]

do we really want to publish another crate??

if we are willing to do that we may as well simply use https://crates.io/crates/add-syntax which does exactly that

what we have is basically a copy-paste of it

we can either:

• hack ourselves around it
• make a smallvec-macro crate that would be really weird
• use that crate with 3k total downloads

honestly I like the first alternative more than either of the other two

[jdm]

I'm against option 1. If we believe the macro is a significant improvement in maintainability then we should do it the right way. Can you show me how the crate unblocks #754 and #762?

[alejandro-vaz]

on #754 it allows us to have conditional exports by prepending pub to our current implementations instead of having to duplicate the code. since there is at least 5-10 methods in which we have that kind of conditional visibility, that can easily be 100-200 lines of code that we have to maintain in sync but that is otherwise the same

on #762 it removes the necessity of having to add a separate impl block by adding the conditional unsafe and the conditional may_dangle. all else stays the same. it saves around 45 lines of code

[alejandro-vaz]

the current implementations of those PRs which I delayed simply duplicate code which makes it a significant burden on maintenance, goes against DRY, bloats the codebase, and can be a painful source of errors if we don't keep them in sync

I don't think it's worth publishing a new crate, and using the 3k downloads one is very risky, whilst doing it like this is not very complex and just works

[alejandro-vaz]

not that sure of the impact I mentioned on #754 (I believe it is not complete, because we would also have to modify rawsmallvec and a few more things), would have to check it again, but key idea is that it removes duplication

[jdm]

I am strongly against running rustc from a build script. If we want the macro and don't want to take on the external dependency then we should publish the crate.

To make my objections more concrete: I worry about the impact on any non-default build configuration like cross-compilation, or changes to Rust/cargo build defaults, or interactions with RUSTFLAGS, etc. We should stay on the supported path of using a proc macro crate dependency with cargo.

[alejandro-vaz]

that makes sense

it's a shame because it's just a little tiny helper

we then have two alternatives:

• make our own smallvec-macro crate for helpers, or however we want to call it
• use add-syntax and pin it down

will we need additional procedural macros for smallvec?? maybe, I wouldn't discard it. so I think we should go with smallvec-macro then

agree??

[jdm]

I'm ok with a new smallvec-macro crate!