[PATCH] D17741: adds __FILE_BASENAME__ builtin macro

[Kristina Brooks via Phabricator via cfe-commits]

kristina added a comment.

I should add that this is not just about reproducible builds but about code size as mentioned by @NSProgrammer. There are ways to cheat with builtins but the problem is, entire __FILE__ string is still emitted into read-only data, despite the constexpressiveness of the value. The common way of getting the short filename in code would the the following (the `#else` case) which is a constant evaluated but has a side effect of dumping the full paths in rodata regardless (ICF seems unable to clean them up even in full LTO builds).

  #ifdef __clang_extension_generate
      #define OS_CUR_FILENAME  __generate("file!0")
  #else
      #define OS_CUR_FILENAME (__builtin_strrchr(__FILE__, '/') ? \
          __builtin_strrchr(__FILE__, '/') + 1 : __FILE__)
  #endif

The extension on the other hand avoids that. So it's a win for code size and reproducible builds. I would urge reconsidering something like `__FILE_NAME__`, or whatever name is preferable for just getting the last path component at preprocessor stage, despite it being poorly received by other developers the last time it seems to be a feature wanted by consumers. I would urge maintainers to reply to get another consensus regarding this since my stance is still the same, if a "missing" feature is widely hacked around, it's clearly desirable. While I understand that a lot have an aversion to nonstandard Clang-specific extensions, as long as a feature check is available it should be down to the consumer to decide if they want to make use of such extensions.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D17741/new/

https://reviews.llvm.org/D17741