Fix C++20 module build error by removing the redundant static keyword from <imgui_internal.h> header.

[stripe2933]

Seems 08bb348 did not ditched every redundant static inline XXX(...) and template <...> (static) inline XXX(...) usages. Note that using inline keyword only is enough to prevent ODR violation in C++, and all templated functions are implicitly inline.

This causes including <imgui_internal.h> header in GMF being error in MSVC(and likely to be in GCC-15, which is more pedantic to this).

D:\a\repo\repo\build\vcpkg_installed\x64-windows-release\include\imgui_internal.h(503): error C2129: static function 'ImVec2 ImMax(const ImVec2 &,const ImVec2 &)' declared but not defined
D:\a\repo\repo\build\vcpkg_installed\x64-windows-release\include\imgui_internal.h(503): note: see declaration of 'ImMax'

This PR fixes the issue by removing the redundant static and inline keywords.

[ocornut]

Thank you. I feel we’d need a CI upgrade to detect regression to this. Do you think you could add a step to CI that built a module and tested for this?

[stripe2933]

Sure. I would be happy to work with that. I'm already managing GitHub Action CI with my fully C++20 module adopted project, which works in MSVC and Clang, and now in testing with GCC 15.

But for doing the CI, things should be considered...

1. We need to add the whole symbol export file (like explained in the another issue) to the project source tree. This may introduces a maintenance overhead. Maybe using c binding generator can help this, but I never had been involved to that.
2. Some macro based function (e.g. 'IMGUI_CHECKVERSION()' should be re-implemented with function equivalent, which seems trivial.
3. Currently only MSVC and Homebrew Clang (not AppleClang) can be used. The latest GCC hosted in runner-images is version 14, which is too immature to handle module.

If you're okay with 1), I'll make a separate PR for it. Looking forward for huge progress of C++20 module ecosystem!

[ocornut]

Ah yeah I forgot it needed those things. It's not worth adding to our CI now because then we'd be tempted to move it to main repo and then I would have to support it. But I think it'd be nice the module setup was published in a third-party repository, and then me or others could refer to it occasionally to get things tested.

Note that you may be able to use "Dear Bindings" or "cimgui" to auto-generate that information.
In fact it may be a good use case for Dear Bindings to provide a script that just does that.

[ocornut]

Merged as 9c39289 (small adjustment as indent/alignment wasn't cared for in the PR).

If you desire to publish a C++20 module thing somewhere I'd link from it from various places (Wiki, imgui/misc/cpp/README.txt and more).