feat: asn support / use const functions

[metaphorics]

No description provided.

[gemini-code-assist]

Summary of Changes

Hello @cognitive-glitch, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request, despite its title suggesting ASN support, primarily focuses on updating project metadata and internal documentation. It includes a version increment and an enhancement of the project's discoverability on package registries through expanded keywords and categories. Additionally, a minor update to internal development guidelines has been applied.

Highlights

• Version Increment: The project's version has been updated from 0.7.3 to 0.7.4 in Cargo.toml, signaling a new patch release.
• Package Metadata Enhancement: The Cargo.toml file has been significantly updated to include a more comprehensive and specific set of keywords and categories. This aims to improve the discoverability and accurate categorization of the rusty-fix-engine crate on package registries, adding terms like fix-protocol, quickfix, fix-engine, and trading.
• Internal Documentation Update: A minor adjustment was made to the CLAUDE.md guideline document, adding a reference to @docs/fix-specs/ alongside @docs/external-libraries/ for developers to consult when implementing APIs or designing exchange abstractions.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request updates the workspace version and expands the package metadata in Cargo.toml. While the intent to improve discoverability is good, the changes to keywords and categories violate crates.io manifest policies and will prevent the package from being published. I've provided a critical comment with a suggested fix to align with the requirements.

[gemini-code-assist]

The Cargo.toml manifest has some issues that will prevent publishing to crates.io.

1. Number of Keywords: The keywords array is limited to a maximum of 5 entries. The current change increases this to 10.
2. Number of Categories: The categories array is also limited to a maximum of 5 entries. The current change increases this to 8.
3. Invalid Categories: The categories fix-engine, fix-parser, fix-protocol, quickfix, and fast are not valid category slugs on crates.io. You must choose from the official list of categories.

These issues are critical and will cause cargo publish to fail. I've suggested a valid set of keywords and categories below, but feel free to adjust them as you see fit while respecting the constraints.

keywords = [
    "fix-protocol",
    "fix-engine",
    "fast",
    "trading",
    "fintech",
]
categories = [
    "network-programming",
    "parser-implementations",
    "encoding",
    "finance",
]

[metaphorics]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a new crate rustyasn for ASN.1 encoding support, which is a significant and valuable feature addition. The implementation is well-structured, including encoders, decoders, configuration options, and a build script for code generation from FIX dictionaries. It also comes with a good set of benchmarks and integration tests.

My review has identified a few high-severity issues that should be addressed before merging:

• The workspace Cargo.toml defines more categories than allowed by crates.io, which will block publishing.
• The rustyasn encoder and decoder advertise support for PER encoding but fall back to DER. This discrepancy could lead to unexpected behavior and interoperability issues.
• The Encoder struct in rustyasn contains unused fields (buffer and schema), which should be removed to clean up the code and eliminate unnecessary overhead.

I've also made several medium-severity suggestions to improve robustness and align with the project's coding guidelines, such as replacing .unwrap() with .expect() and making documentation examples more user-friendly.

Overall, this is a solid contribution that will be even better once these issues are addressed.

[gemini-code-assist]

The categories list for the workspace contains more than 5 items. crates.io has a limit of 5 categories per crate. Any crate in the workspace that inherits this setting (like the new rustyasn crate) will fail to publish. Please reduce the number of categories to at most 5.

categories = [
    "network-programming",
    "parser-implementations",
    "encoding",
    "finance",
    "fintech"
]

[gemini-code-assist]

The implementation for PER, APER, and UPER encoding rules falls back to DER decoding. However, the README.md and config.rs files present these as supported encoding rules. This discrepancy is misleading for users who might choose PER for its compactness and get DER-encoded data instead, which could lead to interoperability issues. If PER is not yet supported, this function should return an UnsupportedEncodingRule error.

            EncodingRule::PER | EncodingRule::APER | EncodingRule::UPER => {
                Err(Error::Decode(DecodeError::UnsupportedEncodingRule("PER/APER/UPER")))
            }

[gemini-code-assist]

Similar to the decoder, the implementation for PER, APER, and UPER encoding rules falls back to DER encoding. This is misleading as users expecting PER's compact format will get DER instead. If PER is not supported, this should return an UnsupportedEncodingRule error to avoid silent failures and interoperability issues.

            EncodingRule::PER | EncodingRule::APER | EncodingRule::UPER => {
                // PER not available in this version, return an error.
                Err(Error::Encode(EncodeError::UnsupportedEncodingRule {
                    rule: "PER/APER/UPER",
                    msg_type: message.msg_type.clone().into(),
                }))
            }

[gemini-code-assist]

This file is missing a final newline character. It's best practice to add one for consistency and to prevent potential issues with some tools.

harness = false

[gemini-code-assist]

The code example for basic encoding/decoding is not self-contained as timestamp is not defined. This will cause confusion for users trying to run the example. Please either define the variable or mark the code block with ,ignore to indicate it's illustrative.

Suggested change

	"D", // MsgType: NewOrderSingle
	```rust,ignore

[gemini-code-assist]

The project guidelines in CLAUDE.md discourage the use of .unwrap(). Please use .expect() with a descriptive message instead to provide more context on panic, which is especially helpful for debugging failing benchmarks.

Suggested change

	let dict = Arc::new(Dictionary::fix44().unwrap());
	let dict = Arc::new(Dictionary::fix44().expect("Failed to load FIX 4.4 dictionary"));

[gemini-code-assist]

The benchmark_message_sizes function prints encoded sizes to stdout but doesn't measure performance using criterion. If the intent is just to display sizes, consider moving this to a test or an example. If it's meant to be a benchmark, it should use b.iter(...) to measure something.

[gemini-code-assist]

The project guidelines in CLAUDE.md state a preference for thiserror over anyhow for structured error handling. While anyhow is convenient in build scripts, adhering to the project's standard would improve consistency. Please consider refactoring to use thiserror or a custom error type for better error handling.

[gemini-code-assist]

The project guidelines discourage .unwrap(). Using it here could cause the build script to panic if a path generated by glob somehow doesn't have a filename. Please use .expect() for robustness and to provide a more helpful error message if a panic does occur.

Suggested change

	let filename = schema_file.file_name().unwrap();
	let filename = schema_file.file_name().expect("glob entry should have a filename");

[gemini-code-assist]

The project guidelines in CLAUDE.md discourage the use of .unwrap(). Please use .expect() with a descriptive message to provide more context on panic during tests.

Suggested change

	let dict = Arc::new(Dictionary::fix44().unwrap());
	let dict = Arc::new(Dictionary::fix44().expect("Failed to load FIX 4.4 dictionary"));

[metaphorics]

/gemini review

[gemini-code-assist]

Code Review

This PR introduces a new crate rustyasn for ASN.1 support, which is a great addition. The overall structure is good, with clear separation of concerns into modules for encoding, decoding, configuration, etc. The use of a build script for code generation is also a solid approach.

However, there are several significant architectural issues and limitations in the current implementation that need to be addressed:

• Incomplete Feature Implementation: Several key features are either missing or incomplete, such as support for repeating groups, a complete schema implementation (it's currently hardcoded for a few messages), and support for PER/APER/UPER encoding rules.
• Architectural Disconnect: There seems to be a disconnect between the code generated by build.rs and the runtime logic. The encoder/decoder rely on manually defined message structures and schemas, while the more detailed generated code is not fully utilized. This makes the crate confusing and hard to extend.
• Misleading Public API: The public API (e.g., EncodingRule enum, encode_message function) suggests more functionality than is actually implemented, which can be misleading for users.

I've left more detailed comments on specific parts of the code. I recommend focusing on creating a solid, unified architecture before adding more features. A good starting point would be to make the encoder/decoder fully utilize the code generated from the FIX dictionaries.

[gemini-code-assist]

The build_field_types function has a TODO and only adds a few hardcoded header and trailer fields. Similarly, build_message_schemas only adds a few hardcoded messages. This means the schema is incomplete and doesn't use the full FIX dictionary.

This is a critical architectural issue. The crate has a build.rs that seems to generate code from dictionaries, but the runtime logic uses this separate, incomplete, manual schema. The generated code should be the source of truth for the schema information at runtime to ensure correctness and completeness.

[gemini-code-assist]

The EncodingRule enum includes PER, APER, and UPER, but these are not actually supported by the encoder or decoder. The encoder returns an UnsupportedEncodingRule error, and the decoder falls back to DER.

This is misleading to users of the crate. If these encoding rules are not supported, they should be removed from the public EncodingRule enum. Alternatively, if support is planned, the current implementation should be documented as a stub and the functions should clearly state the lack of support.

I suggest removing the unsupported variants for now to provide a clear and honest API.

[gemini-code-assist]

The group and group_opt methods for FieldMap are implemented as stubs that always return an empty or None group. This means repeating groups, a fundamental part of FIX, are not supported.

This is a major limitation and should be clearly documented in the crate's README.md. For the crate to be considered for production use, this functionality will need to be implemented.

[gemini-code-assist]

The implementation of add_message_fields is a stub that only handles a few hardcoded tags. This makes the encode_message function not generally useful. The comment // Note: FieldMap doesn't provide field iteration, so we try common field tags highlights the issue.

To make this function useful, it needs a way to iterate over all fields in the FieldMap. If the FieldMap trait doesn't support iteration, you might need to rethink the integration approach or document this severe limitation prominently. A possible solution could be to require a FieldMap that also implements IntoIterator.

[gemini-code-assist]

There's a TODO here to extract the sending time from fields. This is a good note, but it's worth considering how to handle this more robustly. The Asn1FixMessage struct has a dedicated sending_time field, but the conversion from FixMessage doesn't populate it. This could lead to loss of information during message conversion.

A more complete implementation would be to iterate through the fields of the source FixMessage, find the SendingTime (tag 52), and populate the sending_time field in Asn1FixMessage. The field should then be excluded from the generic fields vector to avoid duplication.

[gemini-code-assist]

The line [x] Abstract Syntax Notation (ASN.1). indicates ASN.1 support is fully implemented, but the following line [Working on validations] suggests that it is not. This is misleading and should be clarified.

[gemini-code-assist]

The usage example in the crate-level documentation is marked as ignore and is incomplete. The msg variable is not defined, so the example is not self-contained and won't compile if a user tries to run it.

Please provide a complete, minimal, and working example to demonstrate the crate's usage.

//! ```rust,ignore
//! use rustyasn::{Config, Encoder, Decoder, EncodingRule};
//! use rustyfix::Dictionary;
//! use std::sync::Arc;
//!
//! // Configure encoding
//! let config = Config::new(EncodingRule::DER);
//! let dictionary = Arc::new(Dictionary::fix44().unwrap());
//!
//! // Encode a message
//! let encoder = Encoder::new(config.clone(), dictionary.clone());
//! let mut handle = encoder.start_message("A", "SENDER", "TARGET", 1);
//! handle.add_string(98, "0").add_int(108, 30);
//! let encoded = handle.encode().unwrap();
//!
//! // Decode a message
//! let decoder = Decoder::new(config, dictionary);
//! let message = decoder.decode(&encoded).unwrap();
//! assert_eq!(message.msg_type(), "A");
//! ```

[gemini-code-assist]

The generate_message_structures function has a generic ASN.1 message container, but it does not generate ASN.1 message structures for different FIX message types. This limits the ability to create type-safe message structures for different FIX message types.

[gemini-code-assist]

The example for encoder.start_message is incorrect. The function signature in encoder.rs is pub fn start_message<'a>(&'a self, msg_type: &str, sender_comp_id: &str, target_comp_id: &str, msg_seq_num: u64) -> EncoderHandle<'a>, which does not take a timestamp argument. This example will not compile and will confuse users.

Suggested change

	let mut handle = encoder.start_message(
	"D", // MsgType: NewOrderSingle
	"SENDER001", // SenderCompID
	"TARGET001", // TargetCompID
	1, // MsgSeqNum
	timestamp, // SendingTime
	);
	let mut handle = encoder.start_message(
	"D", // MsgType: NewOrderSingle
	"SENDER001", // SenderCompID
	"TARGET001", // TargetCompID
	1, // MsgSeqNum
	);

[gemini-code-assist]

The rustyfix dependency has a feature fix50 enabled, but the rustyfix-dictionary dependency does not have this feature enabled. This could lead to inconsistencies or compilation errors. Ensure that both dependencies have the same features enabled, or that the code handles the case where they don't.

rustyfix-dictionary = { path = "../rustyfix-dictionary", version = "0.7.4", features = ["fix50"] }

[gemini-code-assist]

Code Review

This pull request introduces a new rustyasn crate to add ASN.1 encoding support. The structure is well-thought-out, with modules for encoding, decoding, and configuration. The build script for code generation is a solid approach for maintainability.

I've found a critical issue in the root Cargo.toml that would prevent publishing to crates.io. Additionally, there are numerous linting violations due to the use of .unwrap() and .expect(). Several key features, such as repeating group support and full schema generation, are currently stubbed out and should be implemented or documented as limitations. Addressing these points will significantly improve the robustness and completeness of this new feature.

[gemini-code-assist]

The keywords and categories lists in the workspace package configuration exceed the limits allowed by crates.io. keywords has 11 items (limit is 5), and categories has 12 items (limit is 5). This will cause an error when publishing. Please reduce the number of items in each list to a maximum of 5.

[gemini-code-assist]

The use of .unwrap() is denied by the workspace linting rules (clippy::unwrap_used). Handle the Result properly. For a test prerequisite like this, unwrap_or_else with a descriptive panic message is a good alternative.

Suggested change

	let dict = Arc::new(Dictionary::fix44().unwrap());
	let dict = Arc::new(Dictionary::fix44().unwrap_or_else(|e| panic!("Failed to load FIX 4.4 dictionary for test: {e}")));

[gemini-code-assist]

The use of .expect() is denied by the workspace linting rules (clippy::expect_used). Handle the Result properly, for example by using unwrap_or_else to panic with a more descriptive message for this test setup.

Suggested change

	FixMessageType::from_str("D")
	.expect("Failed to parse valid message type 'D'")
	FixMessageType::from_str("D")
	.unwrap_or_else(|| panic!("Failed to parse valid message type 'D'"))

[gemini-code-assist]

The use of .expect() is denied by the workspace linting rules (clippy::expect_used). Handle the Result properly, for example by using unwrap_or_else to panic with a more descriptive message for this test setup.

        let dict = Arc::new(
            Dictionary::fix44().unwrap_or_else(|e| panic!("Failed to load FIX 4.4 dictionary for test: {e}")),
        );

[gemini-code-assist]

The decoder silently falls back to DER when PER encoding is specified. This is inconsistent with the encoder, which correctly returns an UnsupportedEncodingRule error. This inconsistency can lead to unexpected behavior. The decoder should also return an error for unsupported encoding rules.

            EncodingRule::PER | EncodingRule::APER | EncodingRule::UPER => {
                Err(Error::Decode(DecodeError::UnsupportedEncodingRule(
                    self.config.encoding_rule.name(),
                )))
            }

[gemini-code-assist]

The message size estimation is a very rough heuristic. This could lead to incorrect behavior. Consider either improving the estimation logic or encoding the message first and then checking its size against the limit for correctness.

[gemini-code-assist]

The timestamp variable is not defined in the Basic Encoding/Decoding example, which will cause a compilation error. Define it with chrono::Utc::now() or provide a placeholder value.

Suggested change

	1, // MsgSeqNum
	timestamp, // SendingTime
	);
	timestamp: chrono::Utc::now(), // SendingTime

[gemini-code-assist]

The group and group_opt methods are currently stubbed and do not implement repeating group logic. This functionality should be implemented to fully support FIX messages with repeating groups. If this is planned for future work, document it in the crate's README as a current limitation.

[gemini-code-assist]

The schema generation is currently hardcoded for a few message types and doesn't fully utilize the provided FIX dictionary. Update the implementation to build the schema dynamically from the dictionary.

[gemini-code-assist]

This file is missing a final newline character. Add a newline character at the end of the file.

harness = false

[metaphorics]

/gemini review

[gemini-code-assist]

Code Review

The pull request includes changes to the .clippy.toml, CLAUDE.md, Cargo.toml, README.md, and TODO.md files. It also adds several new files related to ASN.1 support, including a build script, cargo file, readme, benchmark, and examples. The changes aim to add ASN.1 support and improve code quality.

[metaphorics]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces ASN.1 support via the rustyasn crate, along with smaller improvements and refactorings. The rustyasn crate includes a custom ASN.1 parser to ensure dependency compatibility. The review focuses on correctness and maintainability, identifying areas for improvement in error handling and code simplification.

[gemini-code-assist]

The current implementation of parse_group_entries returns an error, but the public-facing group() and group_opt() methods that call it swallow this specific error and return a misleading FieldValueError::Invalid(InvalidInt). This suggests to the caller that the group count field has an invalid value, which is incorrect and makes debugging difficult.

Since this feature is unimplemented, it would be better to make this explicit by using todo!(). This will cause a panic with a clear "not yet implemented" message when group functionality is used, which is the standard and expected behavior for todo!() and avoids returning a misleading error.

    fn parse_group_entries(
        &self,
        _count_tag: u32,
        _count: usize,
    ) -> Result<Vec<Message>, Asn1FieldError> {
        // This feature is not yet implemented. Using `todo!` to make it explicit.
        todo!("Repeating group parsing is not yet supported for ASN.1 messages.");
    }

[gemini-code-assist]

The logic for parsing UtcTimestamp can be simplified. The two separate checks for timestamps with and without fractional seconds can be combined into a single check using the %.f format specifier in chrono, which handles optional fractional seconds. This will make the code more concise and slightly more efficient.

A similar simplification can be applied to UtcTime parsing a few lines below.

Suggested change

	if NaiveDateTime::parse_from_str(&s, "%Y%m%d-%H:%M:%S").is_ok() {
	return FixFieldValue::UtcTimestamp(s);
	}
	// Also check for timestamp with milliseconds
	if NaiveDateTime::parse_from_str(&s, "%Y%m%d-%H:%M:%S%.3f").is_ok() {
	return FixFieldValue::UtcTimestamp(s);
	}
	if NaiveDateTime::parse_from_str(&s, "%Y%m%d-%H:%M:%S%.f").is_ok() {
	return FixFieldValue::UtcTimestamp(s);
	}

[gemini-code-assist]

Consider renaming is_valid_asn1_tag to is_plausible_start_tag for clarity, as it doesn't fully validate ASN.1 tags but rather checks for plausible start bytes.

[metaphorics]

/gemini review

[gemini-code-assist]

Code Review

The pull request includes changes to increase the cognitive complexity threshold, add fix specs to documentation, add ASN.1 support, and use const functions. The changes also include updates to dependencies and documentation.

[gemini-code-assist]

Consider renaming is_valid_asn1_tag to is_plausible_start_tag for clarity, as the function only checks for plausible start tags rather than fully validating ASN.1 tags.

Suggested change

	- Renamed `is_valid_asn1_tag` to `is_plausible_start_tag` for clarity
	- Renamed `is_valid_asn1_tag` to `is_plausible_start_tag` for clarity

[gemini-code-assist]

The is_standard_header_field function is already const, so there is no need to optimize it further.

Suggested change

	- Optimized const fn usage (`is_standard_header_field` already const)
	- Optimized const fn usage (`is_standard_header_field` already const)

[gemini-code-assist]

It's good practice to add a newline character at the end of files to ensure proper formatting and compatibility across different systems.

Suggested change

	- Added missing newlines to Cargo.toml and README.md files
	- Added missing newlines to Cargo.toml and README.md files

[cursor]

Bug: Buffer Trait Infinite Recursion Bug

The Buffer trait implementations for Vec<u8> and smallvec::SmallVec types contain infinite recursion. The extend_from_slice method calls itself instead of the inherent extend_from_slice method of the concrete types, leading to a stack overflow.

crates/rustyasn/src/traits.rs#L11-L34

rustyfix/crates/rustyasn/src/traits.rs

Lines 11 to 34 in e0a86a4

	impl Buffer for Vec<u8> {
	fn extend_from_slice(&mut self, data: &[u8]) {
	self.extend_from_slice(data);
	}
	}
	impl Buffer for smallvec::SmallVec<[u8; 64]> {
	fn extend_from_slice(&mut self, data: &[u8]) {
	self.extend_from_slice(data);
	}
	}
	impl Buffer for smallvec::SmallVec<[u8; 128]> {
	fn extend_from_slice(&mut self, data: &[u8]) {
	self.extend_from_slice(data);
	}
	}
	impl Buffer for smallvec::SmallVec<[u8; 256]> {
	fn extend_from_slice(&mut self, data: &[u8]) {
	self.extend_from_slice(data);
	}
	}

Fix in Cursor • Fix in Web

---

Was this report helpful? Give feedback by reacting with 👍 or 👎

[metaphorics]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces ASN.1 support and incorporates const functions to enhance performance. The changes include modifications to .clippy.toml, .cursorrules, AGENTS.md, CLAUDE.md, Cargo.toml, README.md, and TODO.md, along with the addition of new files related to ASN.1 implementation.

[gemini-code-assist]

Consider renaming is_valid_asn1_tag to is_plausible_start_tag for clarity.

Suggested change

	- Renamed `is_valid_asn1_tag` to `is_plausible_start_tag` for clarity
	- Renamed `is_valid_asn1_tag` to `is_plausible_start_tag` for clarity

[gemini-code-assist]

Consider making is_standard_header_field a const fn to improve performance.

Suggested change

	- Optimized const fn usage (`is_standard_header_field` already const)
	- Optimized const fn usage (`is_standard_header_field` already const)

[gemini-code-assist]

Consider using the spilled() method to detect SmallVec inline detection.

Suggested change

	- Fixed SmallVec inline detection with `spilled()` method
	- Fixed SmallVec inline detection with `spilled()` method

[gemini-code-assist]

Adding missing newlines to Cargo.toml and README.md files will improve readability.

Suggested change

	- Added missing newlines to Cargo.toml and README.md files
	- Added missing newlines to Cargo.toml and README.md files

[metaphorics]

/gemini review

[gemini-code-assist]

Code Review

The pull request includes changes to various configuration files, documentation, and adds ASN.1 encoding support. Most changes are minor updates to documentation and build configurations. The most significant change is the addition of ASN.1 support, which includes new crates (rustyasn) and modifications to the build process.

[Copilot]

Pull Request Overview

This PR enhances error handling across integration tests by returning Result<(), Box<dyn std::error::Error>>, updates several Cargo.toml files to use workspace dependencies and bumps versions, and broadens error enums with new variants.

• Refactor tests in multiple crates to use Result and map_err, improving test ergonomics and error reporting.
• Update Cargo.toml for rustygpb and rustyfixml to workspace dependencies and bump prost to 0.14.
• Add an I/O error variant to rustyfixml’s FixmlError.

Reviewed Changes

Copilot reviewed 43 out of 43 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
crates/rustysbe/src/lib.rs	Migrate integration tests to return Result and use map_to_dyn_error
crates/rustygpb/src/lib.rs	Refactor test to return Result and replace expect with map_err
crates/rustyfixs/src/lib.rs	Update TLS tests to return Result and map errors
crates/rustyfixml/src/error.rs	Add Io variant for std::io::Error
crates/rustygpb/Cargo.toml	Bump prost and prost-types to 0.14, switch criterion to workspace
crates/rustyfixml/Cargo.toml	Switch quick-xml, criterion, and tokio to workspace
crates/rustyasn/tests/integration_test.rs	New ASN.1 integration tests using Result

[Copilot]

Hardcoding the expected message length as 40 may break if header layout changes. Consider asserting against message.len() (e.g. assert_eq!(length, message.len() as u32)) to keep the test in sync with the actual output.

[Copilot]

[nitpick] The error mapping closure used here and for decoding is duplicated. Consider introducing a test-level helper like fn map_to_dyn_error<E: std::error::Error + 'static>(e: E) -> Box<dyn std::error::Error> or a ResultExt trait to reduce repetition and improve readability.

Suggested change

	let encoded = encoder.encode(&message).map_err(|e| {
	Box::<dyn std::error::Error>::from(format!("Encoding should work but failed: {e}"))
	})?;
	let decoded = decoder.decode(&encoded).map_err(|e| {
	Box::<dyn std::error::Error>::from(format!("Decoding should work but failed: {e}"))
	})?;
	let encoded = encoder.encode(&message).map_err(map_to_dyn_error("Encoding should work but failed"))?;
	let decoded = decoder.decode(&encoded).map_err(map_to_dyn_error("Decoding should work but failed"))?;

[Copilot]

This test panics on failure but other tests use Result<(), Box<dyn std::error::Error>>. For consistency and better error reporting, consider returning Result<(), Box<dyn std::error::Error>> here as well and using ? on fallible operations.

Suggested change

	fn test_message_size_limits() {
	fn test_message_size_limits() -> Result<(), Box<dyn std::error::Error>> {