If the author is still missing at the end of next week, any objections to me resubmitting a similar patch that just implements __FILE_NAME__ or __BASE_NAME__ (Need a few more opinions here I guess, personally I think __FILE_NAME__ makes more sense)?
I'll carve it out from my PP extension which simply looks for the last path separator (depending on the OS) and only renders the filename after it (or the whole path if there's no separator). No need for additional complications like depths etc. Since this idea was shot down last time, is it possible to get a few people to voice their opinion before I mark this as abandoned and carve out and clean up this from my PP extension and add proper tests for it?
Would be appreciated, as this sort of thing is very useful (IMO) so would like to know if anyone is really against this proposal.
May 10 2019
May 8 2019
Feb 22 2019
We would prefer a macro like __FILE_NAME__ over a build flag for code reading consistency (they would clearly do different things vs varying based on an obscure flag being present/absent).
Jan 3 2019
To throw in my 2 cents. I don’t really have a preference between a compiler flag vs a different macro that’s just for the file name sans path prefix. But I have a real need for this to get into clang: with 1.2 million lines of code, the regular placement of log statements and custom asserts leads to megabytes in binary size from all the FILE usages, and that could easily be a few hundred KB with this kind of support in clang.