add matrix macro consistency check at compile time

[mtei]

Description

Test the consistency of (MATRIX_ROW_PINS and MATRIX_ROWS) and (MATRIX_COL_PINS and MATRIX_COLS) at compile time.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[mtei]

• keyboards/for_science (For science #9607)
  It seems necessary to add SPLIT_KEYBOARD = yes in rules.mk.

• keyboards/ai03/voyager60_alps ([Keyboard] Add Voyager60-Alps keyboard #10516)
  It seems that the value of MATRIX_COLS should be 14.

[mtei]

• keyboards/choco60/rev2
  I'm not sure how fix it.
  quantum/split_common/matrix.c seems to assume that the number of columns and rows on the left and right match. (https://github.com/qmk/qmk_firmware/pull/3869/files) @nooges
  However, the keyboards/choco60/rev2 implementation does not match.

[tzarc]

Apparently I also had a quick stab at similar validation without realising you'd started doing something similar:
https://github.com/qmk/qmk_firmware/compare/develop...tzarc:pin-validations?expand=1

Mine certainly doesn't cater for all the cases, but it is done purely at compile-time without requiring a function definition. Unsure if you'd like to go down this route?

Either way, there are a fair few build errors as a result, with mismatching definitions -- some of which you've also listed yourself.

[mtei]

Test_for_matrix_macro_consistency_at_compile_time() is not included in the binary because the compile flag -ffunction-sections and the link flag --gc-sections exclude unused functions from the binary. So we shouldn't have to worry about the binaries getting bigger.

In this PR, Travis-CI reported only the above three cases. I don't think this PR merge will be possible without resolving at least these three cases.

And I'm not sure if this PR should be merged.

[elfmimi]

Sorry for interrupting. I made mine into another PR. #12151

[skullydazed]

I like the idea for this feature but I think it might be better to implement it in python so that more situations can check this. Adding a validation check somewhere around here would be the way to do that.

Now that matrix data can be located in info.json instead of config.h and keyboard.h a lot of users will run qmk info before they ever attempt to compile. Placing the check there will both catch the error earlier and still catch it at compile time.

[mtei]

I have organized the implementation of this PR based on the implementation of validations.c done by tzarc. Further revisions are probably not necessary.

This PR only adds _Static_assert(), so it does not affect the generated binary at all. However, because of the three build errors mentioned above, I will leave this PR as draft until these are resolved.

The macros MATRIX_COLS and MATRIX_ROWS are referenced in a number of source files for tmk_core and quantum.

In contrast, the three macros DIRECT_PINS, MATRIX_ROW_PINS, and MATRIX_COL_PINS are referenced only in quantum/matrix.c and quantum/split_common/matrix.c. In other words, DIRECT_PINS, MATRIX_ROW_PINS, and MATRIX_COL_PINS are macros dedicated to the matrix.c implementation that uses only the GPIOs of the current MCU.

Therefore, I think it is most appropriate to do this test in quantum/matrix.c and quantum/split_common/matrix.c.

[skullydazed]

Therefore, I think it is most appropriate to do this test in quantum/matrix.c and quantum/split_common/matrix.c.

We're starting to validate information like this in more places. Even if this code is in place we will still want to check and highlight this situation at other times, EG qmk info. Validation will help us as we work towards data driven QMK.

Additionally, in python we can choose to throw warnings instead so that currently working but technically incorrect keyboards don't block the PR.

[mtei]

I like the direction of the transition to data-driven QMK. However, as of today, I'm not sure how much of that has been achieved and what is being done now.

Even if the check can be done in Python, I think it is worth checking in quantum/matrix.c for the reasons I mentioned above.

[stale]

Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.

[stale]

Thank you for your contribution!
This pull request has been automatically closed because it has not had activity in the last 30 days. Please feel free to give a status update now, ping for review, or re-open when it's ready.