[alloy] Header guard for adapt-related header clashes with the function macro

[saki7]

When I try to enter IRIS_ALLOY_ADAPT_STRUCT, I always get the macro IRIS_ALLOY_ADAPT_HPP in the completion list. This include guard shall be named in a different way to avoid this QoL issue.

The same applies to all headers in the adapted/ directory.

Possible candidate: IRIS_ALLOY_Z_ADAPT_HPP, etc.

[yaito3014]

Should we reconsider include guard naming convention or allow such abnormal cases? Typing IRIS_X4 also yields bunch of include guards.

P.S.
One of naming convention candidates: IRIS_ALLOY_INCLUDED_ADAPT_HPP or IRIS_X4_INCLUDED_RULE_HPP

[saki7]

Should we reconsider include guard naming convention or allow such abnormal cases? Typing IRIS_X4 also yields bunch of include guards.

P.S. One of naming convention candidates: IRIS_ALLOY_INCLUDED_ADAPT_HPP or IRIS_X4_INCLUDED_RULE_HPP

This is a really good point, and I actually think that trying more generic include guard naming convention that applies to all of our headers is worth consideration.

"INCLUDED_" is a bad choice because it starts with "I", which precedes any function macro that comes lexicographically after "IN". This is just a mitigation and would not essentially solve our problem here.

I think the only generic solution is to start our include guard with the last character, which is "Z_".

I am aware that "Z_" looks somewhat unfamiliar, but I believe almost no users would care about the include guard naming convention of some external library, so it's going to be ok if we say it's ok.

Do you think the scheme like IRIS_X4_Z_SOME_HEADER_HPP would work?

[yaito3014]

Do you think the scheme like IRIS_X4_Z_SOME_HEADER_HPP would work?

Yes. But to clarify, we should test out what it likes to have such on IDE first.
I'll open PR for this on each repo(iris, x4).