[#213] test: add test cases

[xieyuschen]

Notes for Reviewer

I have added some test cases during I'm learning the codes. It improves out test.

Pre-Review Checklist for the PR Author

1. Add sensible notes for the reviewer
2. PR title is short, expressive and meaningful
3. Relevant issues are linked in the References section
4. Every source code file has a copyright header with SPDX-License-Identifier: Apache-2.0 OR MIT
5. Branch follows the naming format (iox2-123-introduce-posix-ipc-example)
6. Commits messages are according to this guideline
   • Commit messages have the issue ID ([#123] Add posix ipc example)
   • Commit author matches Eclipse Contributor Agreement (and ECA is signed)
7. Tests follow the best practice for testing
8. Changelog updated in the unreleased section including API breaking changes
9. Assign PR to reviewer
10. All checks have passed (except task-list-completed)

Checklist for the PR Reviewer

• Commits are properly organized and messages are according to the guideline
• Unit tests have been written for new behavior
• Public API is documented
• PR title describes the changes

Post-review Checklist for the PR Author

1. All open points are addressed and tracked via issues

References

Updates #213

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 79.02%. Comparing base (a7f0df7) to head (c472781).
Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #439      +/-   ##
==========================================
+ Coverage   78.93%   79.02%   +0.08%     
==========================================
  Files         196      196              
  Lines       23283    23366      +83     
==========================================
+ Hits        18379    18465      +86     
+ Misses       4904     4901       -3     

Files with missing lines	Coverage Δ
iceoryx2/src/service/builder/publish_subscribe.rs	90.97% <ø> (-0.57%)	⬇️
.../src/service/static_config/message_type_details.rs	100.00% <100.00%> (ø)

... and 3 files with indirect coverage changes

[xieyuschen]

oops, I have found that alignment in 32bits is 4, not 8. let me change it:)

[elfenpiff]

@xieyuschen It is always a pleasure to start the week with an Earl Grey Hot (with milk) and a review of your PR.

Thank you very much for your continuous effort and helping us out!

[elfenpiff]

Using String in iceoryx2 would lead to a segmentation fault. But you could use [MyPayload] as dynamic slice.

[xieyuschen]

understood, btw not sure you are refering to the usage of [MyPayload] like this:

MessageTypeDetails::from::<i32, bool, &[MyPayload]>(TypeVariant::Dynamic);

Using String in iceoryx2 would lead to a segmentation fault

I think we can try our best to reject the some types such as string in MessageTypeDetails::from, such as panic.
Not sure we can have some refinements here, but i will have a look later. How do you think about it?

[elfenpiff]

@xieyuschen The usage would be like:

MessageTypeDetails::from::<i32, bool, [MyPayload]>(TypeVariant::Dynamic);

I think we can try our best to reject the some types such as string in MessageTypeDetails::from, such as panic.
Not sure we can have some refinements here, but i will have a look later. How do you think about it?

The idea was to provide a trait ShmSend and a corresponding proc macro. Every type that implements ShmSend can be used as payload type. We provide ShmSend for all POD types (u64, u32, bool ...) and all shared memory compatible containers from iceoryx2_bb_containers. The proc macro would also add #[repr(C)].

So the user would annotate the struct with #[ShmSend] and if one member does not implement it, it would fail at compile time - for instance if one member would be a String.

[xieyuschen]

cool, that's great, could I know the issue to track this change?

[xieyuschen]

hi @elfenpiff looks your example here doesn't work. but never mind, I can skip it in this PR and test it in the following PR.

        #[repr(C)]
        struct MyPayload {
            header: i32,
            _user_header: i32,
            payload: i32,
        }
        let details = MessageTypeDetails::from::<i32, i32, [MyPayload]>(TypeVariant::Dynamic);

error[E0277]: the size for values of type `[service::static_config::message_type_details::tests::test_payload_ptr_from_header::MyPayload]` cannot be known at compilation time
   --> iceoryx2/src/service/static_config/message_type_details.rs:283:60
    |
283 |         let details = MessageTypeDetails::from::<i32, i32, [MyPayload]>(TypeVariant::Dynamic);
    |                                                            ^^^^^^^^^^^ doesn't have a size known at compile-time

[xieyuschen]

@xieyuschen It is always a pleasure to start the week with an Earl Grey Hot (with milk) and a review of your PR.

Thank you very much for your continuous effort and helping us out!

ack, will try to resolve it later today and thanks for your clarify.

[xieyuschen]

Hi @elfenpiff , I have updated the PR with multiple small commits for you to check them based on your comments. I resolved the straitfoward comments and left some comments for you to see whether you have concerns about it.

Thanks for reviewing.

[elfenpiff]

I left a comment on how to fix the ubuntu 32 bit issue. When this is fixed we can merge this PR.

[xieyuschen]

Hi @elfenpiff , I have squashed the commits together for your final review. Could you review it and then we can merge it?

I plan to create another new PRs for the testing later. I found it helps me to understand the project while improving our codebase as well.