What
source/extensions/dynamic_modules/sdk/rust does not enable unsafe_op_in_unsafe_fn. It is
allow-by-default on edition 2021, so the existing #![deny(warnings)] in lib.rs does not cover
it. Adding #![deny(unsafe_op_in_unsafe_fn)] produces 127 E0133 errors across 14 files, each
an ABI-contract operation: raw-pointer derefs recovering module-owned state, Box::from_raw in
destroy hooks, writes through caller-supplied out-parameters, and direct
abi::envoy_dynamic_module_callback_* calls. 126 of the 127 are inside #[no_mangle] unsafe extern "C" fn envoy_dynamic_module_* entry points; the remaining one is EnvoyMutBuffer::new in
buffer.rs.
Same seam as #44850 and #44846 (@agrawroh), on the entry-point side rather than the helper side.
Why now
#46367 (open) adds pub(crate) unsafe fn take_and_perform_recreation, whose body ends in a bare
self.recreate_stream(None), and makes recreate_stream an unsafe fn in the same PR. That is
E0133 under the lint. Not a defect in #46367 — it compiles today — but it is exactly the pattern
the lint makes visible at review time.
Patch
PR: #46377. Built against 40916f9e4d: +310 / −108 across 15 files, 79 new unsafe blocks
covering all 127 operations, 78 SAFETY: comments (one in cert_validator.rs governs an adjacent
pair). No BUILD/Bazel changes, no behaviour or API change. cargo build and cargo clippy --lib
are clean with the lint denied; deleting any one new block reproduces E0133.
Filing an issue first because this is >100 LOC (CONTRIBUTING.md), not because the shape is open: one
PR against main, crate-wide #![deny(...)], and I'll merge main in once #46367 lands. Say so if
you'd rather have #![warn(...)] or a per-subsystem split.
What
source/extensions/dynamic_modules/sdk/rustdoes not enableunsafe_op_in_unsafe_fn. It isallow-by-default on edition 2021, so the existing
#![deny(warnings)]inlib.rsdoes not coverit. Adding
#![deny(unsafe_op_in_unsafe_fn)]produces 127E0133errors across 14 files, eachan ABI-contract operation: raw-pointer derefs recovering module-owned state,
Box::from_rawindestroy hooks, writes through caller-supplied out-parameters, and direct
abi::envoy_dynamic_module_callback_*calls. 126 of the 127 are inside#[no_mangle] unsafe extern "C" fn envoy_dynamic_module_*entry points; the remaining one isEnvoyMutBuffer::newinbuffer.rs.Same seam as #44850 and #44846 (@agrawroh), on the entry-point side rather than the helper side.
Why now
#46367 (open) adds
pub(crate) unsafe fn take_and_perform_recreation, whose body ends in a bareself.recreate_stream(None), and makesrecreate_streamanunsafe fnin the same PR. That isE0133under the lint. Not a defect in #46367 — it compiles today — but it is exactly the patternthe lint makes visible at review time.
Patch
PR: #46377. Built against
40916f9e4d: +310 / −108 across 15 files, 79 newunsafeblockscovering all 127 operations, 78
SAFETY:comments (one incert_validator.rsgoverns an adjacentpair). No BUILD/Bazel changes, no behaviour or API change.
cargo buildandcargo clippy --libare clean with the lint denied; deleting any one new block reproduces
E0133.Filing an issue first because this is >100 LOC (CONTRIBUTING.md), not because the shape is open: one
PR against
main, crate-wide#![deny(...)], and I'll mergemainin once #46367 lands. Say so ifyou'd rather have
#![warn(...)]or a per-subsystem split.