A modernization check for legacy source-location plumbing would be useful in C++20 and later. A common pattern in older code is to thread __FILE__, __LINE__, and sometimes __func__ through helper APIs manually when the real intent is “capture the current call site”.
For example:
void log_error(const char *file, int line, std::string_view msg);
log_error(__FILE__, __LINE__, "bad state");
In C++20 the more expressive interface is often something like:
void log_error(std::string_view msg,
std::source_location loc = std::source_location::current());
log_error("bad state");
This makes the intent clearer and removes repetitive boilerplate at every call site.
The check should be conservative. It should only trigger when the code is clearly using file/line information purely to describe the call site and where a std::source_location-based interface would preserve the meaning.
Possible targets include helper functions or constructors that take a recognizable file/line pair and are called with __FILE__ / __LINE__, especially when the rest of the call is unchanged.
It doesn't seem like there should be autofixes with this check, at least with the current shape of it. But the check itself would be still valuable.
A modernization check for legacy source-location plumbing would be useful in C++20 and later. A common pattern in older code is to thread
__FILE__,__LINE__, and sometimes__func__through helper APIs manually when the real intent is “capture the current call site”.For example:
In C++20 the more expressive interface is often something like:
This makes the intent clearer and removes repetitive boilerplate at every call site.
The check should be conservative. It should only trigger when the code is clearly using file/line information purely to describe the call site and where a
std::source_location-based interface would preserve the meaning.Possible targets include helper functions or constructors that take a recognizable file/line pair and are called with
__FILE__/__LINE__, especially when the rest of the call is unchanged.It doesn't seem like there should be autofixes with this check, at least with the current shape of it. But the check itself would be still valuable.