chore: allow generated file to be used with include!

[nyurik]

• Due to a compiler limitation, inner attributes are not allowed with the include! macro. This PR removes all #![...] and //! ... from the generated code, which will result in some warnings being generated. We may need to add explicit allow to each individual function where relevant.

mod messages {
    include!(concat!(env!("OUT_DIR"), "/messages.rs"));
}

• Do not place generated code inside the user's code - not a good practice. All generated code should go into OUT_DIR.
• Remove allow_dead_code configuration

[Copilot]

Pull request overview

This PR refactors the code generation to make generated files compatible with Rust's include! macro by removing inner attributes (#![...] and //! ...), which are not allowed due to a compiler limitation. Generated code is now written to OUT_DIR during the build process and included via include! in user code, following Rust best practices for build-time code generation.

Key changes:

• Generated code now omits all inner attributes and doc comments, moving lint suppressions to module-level #[expect(...)] attributes
• All generated code is written to OUT_DIR instead of the source tree
• Removed the allow_dead_code configuration option
• Updated error trait implementation from std::error::Error to core::error::Error for better no_std compatibility

Reviewed changes

Copilot reviewed 11 out of 13 changed files in this pull request and generated 8 comments.

Show a summary per file

File	Description
testing/can-messages/src/messages.rs	Entire generated file removed from source tree
testing/can-messages/src/lib.rs	Replaced static module with include! from OUT_DIR, added module-level lint suppressions
testing/can-messages/build.rs	Simplified to write generated code directly to OUT_DIR instead of src/
testing/can-embedded/src/messages.rs	Stub file removed as it's now generated during build
testing/can-embedded/src/lib.rs	Added include! macro to load generated code from OUT_DIR
testing/can-embedded/build.rs	New build script to generate messages.rs for embedded target
testing/can-embedded/Cargo.toml	Added build dependencies for code generation
src/lib.rs	Removed inner attributes and doc comments from generated code, changed error trait to core::error::Error, removed allow_dead_code config
README.md	Removed reference to allow_dead_code configuration option
Cargo.lock	Dependency version updates
.github/workflows/ci.yml	Updated cargo commands to use --workspace instead of --all

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The messages module is private but its contents are never re-exported. This means all the generated code (messages, error types, etc.) will be inaccessible to users of this library.

Add pub use messages::*; after line 8 to re-export the generated items, similar to how it's done in testing/can-messages/src/lib.rs.

Suggested change

	}
	}
	pub use messages::*;

[Copilot]

Several lints that were previously suppressed in the generated code are now missing from the module-level attributes. Consider adding:

• unreachable_patterns - for match statements with enum values
• unused_imports - if conditional feature imports are unused
• clippy::let_and_return and clippy::eq_op - for generated patterns
• clippy::too_many_arguments - for message constructors with many fields

Also consider whether clippy::arithmetic_side_effects should still be denied at the module level to catch potential overflow issues in the generated code.

[Copilot]

Similar to the issue in testing/can-messages, several lints that were previously suppressed are missing:

• unreachable_patterns - for match statements
• unused_imports - for conditional imports
• clippy::let_and_return and clippy::eq_op - for generated patterns
• clippy::too_many_arguments - for constructors

Also, the original code had #![deny(clippy::arithmetic_side_effects)] to catch overflow issues, which should be considered for inclusion.

[tegimeki]

These changes look good to me and address issues I've considered important, namely having generated code in OUT_DIR rather than within the source tree. However, not being a user of this crate currently it seems best to ping some of the recent committers to get their take: @killercup @scootermon @projectgus @trnila @cpctaylo

This seems like a breaking change, not necessarily at the API level but in terms of how dependent projects might use the generated files... what kind of version bump is anticipated?

[trnila]

can we add imports to have working example in README?

use dbc_codegen::Config;
use std::fs::write;
use std::{env::var, path::PathBuf};

dbc_file should be as a string now:

let dbc_file = std::fs::read_to_string(dbc_path).unwrap();

[trnila]

#[allow(unused_imports)] might be needed for BitOr or ExtendedId/StandardId or checked if its going to be used to prevent errors:

6 | use core::ops::BitOr;
  |     ^^^^^^^^^^^^^^^^
  |
  = note: `-D unused-imports` implied by `-D warnings`
  = help: to override `-D warnings` add `#[allow(unused_imports)]`