For reasons of portability we wrap the magic incantation required for inline function by the various compilers in macros on the project I'm on. We've been doing this for close to 20 years. So, to help SlickEdit make sense of it we've always added these kind of macros to the "C/C++ Preprocessing" settings (or directly to usercpp.h/unxcpp.h). Using qt5 build of beta 4 on linux (haven't found a qt5 build of beta 5 yet), SlickEdit seems to be
having trouble making use of these macros and actually does a lot better job if we don't add them to the "C/C++ Preprocessing" settings. Jumping (Ctrl-.) to parameters stops working when added.
Reproduction scenario:
1. Start SlickEdit with default config (hit Finish in config wizzard) and a new C-header: vs +new -sc /tmp/vsconfig1 /tmp/tst.h
2. In /tmp/tst.h enter:
struct Sky
{
uint32_t uColor;
};
DECLINLINE(bool) IsTheSkyBlue(struct Sky *pSky)
{
return (pSky->uColor & 0xff) > ((pSky->uColor >> 8) & 0xff)
&& (pSky->uColor & 0xff) > ((pSky->uColor >> 16) & 0xff);
}
3. Go to any of the four places the 'pSky' is used, hit Ctrl-. and SlickEdit will jump to the parameter as expected.
4. Open the "C/C++ -> C/C++ Preprocessing" settings, hit the "New" button, enter "DECLINLINE(type)" and hit OK. Enter "inline type" as the value. Close the settings dialog (OK button).
5. Retry step 3. This time SlickEdit does not jump to the 'pSky' parameter, the cursor remains in the same spot. (Moving the cursor to the 'uColor' part and hitting Ctrl-. still works, though.)
(6. Changing DECLINLINE to XDECLINLINE in the above source and jumping to 'pSky' works again.)
If I change the DECLINLINE(type) macro value to nothing in the settings, it works again. It stops working as soon as I enter any value (be it just "type" or "inline" or "static" or "whatever").
Update: Also happens with beta 5 on linux/qt4.
Update: Reproduced on 64-bit windows with beta5 as well. Works fine with 2022 (v27.0.2.0), so it is probably a regression in the 2023 betas.
