C++ language implementation (first steps)

[asmfreak]

This PR is my attempt to create a working modern-looking (de)serialization layer for UAVCAN v1. This work is aimed at #91 progress.

Steps:

• [X] Update googletest to a new version as my installation of Arch Linux is already on a newer compiler (GCC 11), which generates a new warning, which crashes build with -Werror.
• [x] Translate C support library to C++
  • [X] Basic bit patterns
  • [X] Bits and integers (de)serialization
  • [x] Floats (de)serialization
• [x] Translate serialization to C++ (with tests!)
  • [x] Primitive types
  • [x] Composite types
  • [x] Const arrays
  • [x] Variable arrays
  • [x] Unions
• [x] Translate deserialization to C++ (with tests!)
  • [X] Primitive types
  • [x] Composite types
  • [x] Const arrays
  • [x] Variable arrays
  • [x] Unions
• [x] Polyfill std::span with NUNAVUT_ASSERTs to minimize needed code.
• [x] Decide on how to polyfill std::expected.
• [X] Remove debug-only headers.

[thirtytwobits]

Ack. Sorry about the linter error. Looks like something upstream change. Let me fix this then you can rebase and get your change in.

[asmfreak]

This commit intoduces (de)serialization of primitive types.

It also introduces an additional debug header - magic_enum - to be used in debugging return codes and pretty printing.

I think, it should be deleted before this implementation goes to main branch.

@thirtytwobits, can you please look into this? I hust want to know, if I'm doing the right thing.

[thirtytwobits]

Sorry I didn't have time to look at this today. One thing that would help greatly is to fix the little linter errors and whatnot so we can get past this build stage and get to the important tests.

[pavel-kirienko]

@ASMfreaK maybe for testing purposes it's better to rely on the C serialization as a reference implementation instead of copy-pasting the existing test cases? This way it should be easier to implement and require less effort to maintain.

[pavel-kirienko]

You force-push a lot. This is okay but not very useful because we use squash merging -- all your commits will be rewritten into one regardless of the pre-merge history.

[asmfreak]

I wanted to clean out vendored libraries and used git filter-repo on my branch, hence the new commits.

it's better to rely on the C serialization as a reference implementation instead of copy-pasting the existing test cases?'

@pavel-kirienko I'd like to do that. I wanted to add back-and-forth serialization-deserialization through C implementation like the one with regulated.basics.Primitive.0.1.

[asmfreak]

Can we maybe merge this PR, if @thirtytwobits sees it as ok for a proof-of-concept? And I can continue to work on other tasks (see the initial message of this PR) in smaller PRs?

[thirtytwobits]

@ASMfreaK , I'm totally good with that. This is why we have the "experimental languages" flag, to keep this work from building up in forks before it gets finalized. I just need you to bump the patch number in version.py if you don't mind. I haven't had time to create a proper "don't publish" workflow for commits.

[asmfreak]

Do you want me to add support for something like bumpversion?

[sonarcloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

80.6% Coverage
0.0% Duplication

[thirtytwobits]

Do you want me to add support for something like bumpversion?

Is this something that would automatically update the version number with each commit? If so then yes please.