Better integrate with std::source_location

[stephanlachnit]

This PR aims to better integrate spdlog v1.x with std::source_location. Effectively closes #1959.

The main idea is to allow constructing spdlog::source_loc from std::source_location. This approach is significantly simpler compared to #2667 and still works as one would expect:

spdlog::log(std::source_location::current(), spdlog::level::info, "test");

The neat part is that thanks to std::source_location being constexpr, it has the same runtime performance as the macro solution. The only caveat is that std::source_location uses std::uint_least32_t instead of int for the line number - I adapted spdlog::source_loc to use this as well, which might result in some compiler/linter warnings when upgrading (though they are trivial to fix by changing the cast type).

[gabime]

Thanks @stephanlachnit . All new features go to the v2.x branch, and since it already contains source_location integration I will have to pass.

[stephanlachnit]

Thanks @stephanlachnit . All new features go to the v2.x branch, and since it already contains source_location integration I will have to pass.

Can you maybe reconsider this? This is not really a new "feature", just a single new constructor for convenience for the exact same feature that already exists. If the int -> std::uint_least32_t change bothers you, that can be replaced with a static cast. I would love to use the 2.x branch, but without a release that is unfortunately not possible.

[stephanlachnit]

@gabime I now removed the int -> std::uint_least32_t change (I think you need to reopen the PR to see the change or check here).

The PR now only adds a single symbol if std::source_location is available and is otherwise fully transparent. The change is only 34 lines of changed code, if you count the new code it is only 22 pretty trivial lines, which I think is rather few to close an issue ticket.

[gabime]

Not sure I understand why a new implementation of the SPDLOG_LOGGER_CALL macro benefits library users.
The main point of using source_location would be to log source locations without using the macros.

[stephanlachnit]

Not sure I understand why a new implementation of the SPDLOG_LOGGER_CALL macro benefits library users. The main point of using source_location would be to log source locations without using the macros.

The main point of having std::source_location would be indeed logging without macros. For example, we defined custom level names and thus have a custom enum that we cast to spdlog::level::level_enum, basically:

void custom_log(Level level, std::string_view message, const std::source_lcation& loc = std::source_location::current()) {
    spdlog_logger_->log(loc, static_cast<spdlog::level::level_enum>(level), message);
}

We can of course also create std::source_location there (which we currently do), but I think since this makes more sense being integrated in the library, especially since this has been requested before in #1959.

If you want I can drop the use of std::source_location in SPDLOG_LOGGER_CALL, it's just something you get for free.