When building for wasm32v1-none with Cargo, the 'std' feature gets
unified across the dependency graph, meaning serde_core sees
feature="std" even on a no_std target. This caused compilation failures
because the crate tried to use std:: imports.
This commit fixes the issue by checking target_os = "none" in addition
to the std feature flag:
- lib.rs: Force no_std when target_os = "none"
- crate_root.rs: Use core/alloc instead of std on target_os = "none"
- All std-only cfg blocks now include not(target_os = "none")
- Add explicit prelude imports for wasm32v1-none compatibility
When building serde_core for wasm32v1-none target with no_std but with
the alloc feature enabled, the Rust compiler doesn't automatically inject
the prelude. This causes ?Sized bounds to fail with "bound modifier ?
can only be applied to Sized" errors.
This commit adds explicit prelude imports to all modules that:
1. Use `use crate::lib::*;` for serde's internal lib facade
2. Use `?Sized` bounds in their code
The fix adds:
```rust
#[allow(unused_imports)]
#[cfg(not(feature = "std"))]
use ::core::prelude::rust_2021::*;
```
This ensures Sized, Clone, Copy, and other prelude traits are in scope
for the ?Sized syntax to work correctly on wasm32v1-none targets.
Affected files:
- serde_core/src/de/impls.rs
- serde_core/src/de/mod.rs
- serde_core/src/private/doc.rs
- serde_core/src/ser/fmt.rs
- serde_core/src/ser/impls.rs
- serde_core/src/ser/impossible.rs
- serde_core/src/ser/mod.rs
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
wasm32v1-none target does not automatically inject prelude items like
Sized, Clone, Copy, etc. into scope. This commit:
- Uses fully qualified paths (::core, ::std) to avoid ambiguity with
internal `mod core` shadowing
- Explicitly re-exports rust_2021 prelude items
- Adds explicit imports for essential prelude traits: Sized, Clone,
Copy, Send, Sync, Unpin, Default, Eq, Ord, PartialEq, PartialOrd,
Iterator traits, and Fn traits
- Adds `extern crate core;` for no_std targets in lib.rs
This fixes compilation errors like "relaxing a default bound only does
something for ?Sized" when building for wasm32v1-none target.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
warning: lint `clippy::empty_enum` has been renamed to `clippy::empty_enums`
--> serde/src/lib.rs:122:5
|
122 | clippy::empty_enum,
| ^^^^^^^^^^^^^^^^^^ help: use the new name: `clippy::empty_enums`
|
= note: `#[warn(renamed_and_removed_lints)]` on by default
warning: lint `clippy::empty_enum` has been renamed to `clippy::empty_enums`
--> serde_core/src/lib.rs:57:5
|
57 | clippy::empty_enum,
| ^^^^^^^^^^^^^^^^^^ help: use the new name: `clippy::empty_enums`
|
= note: `#[warn(renamed_and_removed_lints)]` on by default
warning: lint `clippy::empty_enum` has been renamed to `clippy::empty_enums`
--> test_suite/tests/test_de.rs:5:5
|
5 | clippy::empty_enum,
| ^^^^^^^^^^^^^^^^^^ help: use the new name: `clippy::empty_enums`
|
= note: `#[warn(renamed_and_removed_lints)]` on by default
warning: lint `clippy::empty_enum` has been renamed to `clippy::empty_enums`
--> test_suite/tests/test_de_error.rs:3:5
|
3 | clippy::empty_enum,
| ^^^^^^^^^^^^^^^^^^ help: use the new name: `clippy::empty_enums`
|
= note: `#[warn(renamed_and_removed_lints)]` on by default
Even for a simple data structure that would ordinarily expand to an impl
that only refers to the public Serde traits without serde::__private, we
still disallow a (renamed) serde_core dependency. This leaves the
liberty to new usage of private helpers in such impls over time. For
example, similar to the optimization of the standard library's
derive(Debug) that introduced debug_struct_field1_finish to improve
compile time of derived impls.
This prevents diagnostics being rendered like `serde_core::ser::Serialize`
and `serde_core::de::Deserialize` in projects that have no direct
dependency on serde_core.
The attributes make error messages arguably sometimes worse than
pre-serde_core by always rendering `serde::Serialize` and never
`Serialize` when `use serde::Serialize` is in scope, which rustc's
default message construction knows to recognize. But this is probably
negligible.
I explored the alternative of setting `[lib] name = "serde"` in
serde_core/Cargo.toml which also prevents `serde_core::ser::Serialize`
in messages, but has the unwanted effect of also inserting the following
noise into every such error:
note: there are multiple different versions of crate `serde` in the dependency graph
--> $WORKSPACE/serde_core/src/ser/mod.rs:225:1
|
225 | pub trait Serialize {
| ^^^^^^^^^^^^^^^^^^^ this is the required trait
|
::: src/main.rs:1:1
|
1 | struct MyStruct;
| --------------- this type doesn't implement the required trait
...
4 | let _ = serde_json::to_string(&MyStruct);
| ----------
| |
| one version of crate `serde` used here, as a dependency of crate `serde`
| one version of crate `serde` used here, as a dependency of crate `serde_json`
|
::: $WORKSPACE/serde/src/private/de.rs:2347:1
|
2347 | pub trait IdentifierDeserializer<'de, E: Error> {
| ----------------------------------------------- this is the found trait
= help: you can use `cargo tree` to explore your dependency tree
The "this is the found trait" pointing to `IdentifierDeserializer` seems
like a compiler bug...
pezkuwichain
David Tolnay