[BUG] 12864 LCD type - `GET_ARRAY_PIN` pin_array undefined

[classicrocker883]

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

In my quest trying to see about the warnings for u8g - U8glib-HAL libs I mentioned in another issue,
this "error" came up and may be related.

in src/HAL/HC32F46x/pinsDebug.h, line ~103

static bool GET_ARRAY_IS_DIGITAL(const int16_t array_pin)
{
    const pin_t pin = GET_ARRAY_PIN(array_pin);
    return (!IS_ANALOG(pin));
}

the previously #defined GET_ARRAY_PIN doesn't seem to be an issue because other HAL/< chip >/pinsDebug.h has almost identical coding, but for some reason this error pops up.
it doesnt actually pop up when compiling, firmware doesn't fail. Only after opening the file did VSCode show the error.

but when compiling for the 12864 LCD, those warnings are pin related.

I recently commented on #35 and this may be related.

Bug Timeline

No response

Expected behavior

No response

Actual behavior

No response

Steps to Reproduce

No response

Version of Marlin Firmware

most recent

Printer model

No response

Electronics

No response

Add-ons

No response

Bed Leveling

None

Your Slicer

None

Host Software

None

Don't forget to include

• [X] A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

No response

[shadow578]

Hi, just to confirm: the error is just shown by vscode, not while compiling, right?

---

Because it should compile as-is, tho the reason is kind of weird and would probably confuse vscode...

as you've already correctly identified, the error is caused by the definition of the GET_ARRAY_PIN macro. Or, more precisely, the use of the pin_array symbol. But the pin_array symbol is not defined in the HAL's pinDebug.h file, so under normal circumstances vscode would be correct to report the error...

except, the HAL's pinsDebug.h file is only ever included in a single place, which happens to be after the definition of pin_array. Since in c/c++, header files are (more or less) just copy-pasted where the include statement is, now the pin_array symbol is available and everything compiles.

But vscode does not know of this, and so shows a error ...

Marlin sometimes makes use of this kind of (tbh) confusing techniques, but it's generally a non-issue.

I'll look into how other HALs handle this, and might add some check for it.

[shadow578]

sadly, vscode quite often marks things as problems which are not actually ones...

Either the configuration of the c/c++ extension is not quite right, or the extension is just like that. But i'm not really experienced enough in c/c++ to fix that, so i generally just hit compile and see what errors actually stick

[classicrocker883]

sadly, vscode quite often marks things as problems which are not actually ones...

Either the configuration of the c/c++ extension is not quite right, or the extension is just like that. But i'm not really experienced enough in c/c++ to fix that, so i generally just hit compile and see what errors actually stick

that is generally the way I see it. In the end it's the sausage that matters, not how it's made.

I do like to find and tweak anything I could, if I could. unfortunately I too am not experienced enough with c/c++. we do what we can though! 🤘🏻

[shadow578]

i've decided to add a comment explaining the situation.

initially i wanted to add a conditional definition of the variable like this:

#if !defined(pin_array)
typedef struct PinInfo {
    uint16_t pin;
} PinInfo;

extern const PinInfo pin_array[];
#endif

but sadly, `#if defined(...) does not seem to work with 'normal' symbols, only preprocessor ones...