Add a __FILE_NAME__ macro.

[kristina]

Summary

A much simplified version of D17741 which adds a new builtin macro __FILE_NAME__ that is similar to __FILE__ but only renders the last path component. It seems that this functionality is highly desired from the consensus on D17741 as a separate macro versus a much more complicated and niche patch originally proposed in that differential.

[kristina]

Fix style, remove unnecessary braces, add missing newline.

[shawnl]

lib/Lex/PPMacroExpansion.cpp

1510

What is the path name uses both \ and / to separate paths? I think this needs to be:

if (LangOpts.MicrosoftExt) {
  size_t BackSlash = PLFileName.take_back(PLFileName.size() - LastSep).find_last_of('\\');
  if (BackSlash != StringRef::npos)
    LastSep = BackSlash;
}

[shawnl]

There is no documentation specific to the #include directive. https://docs.microsoft.com/en-us/cpp/preprocessor/hash-include-directive-c-cpp?view=vs-2019

However, fileio treats / and \ the same, *sometimes*. https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file

[kristina]

Actually I got it wrong, the path is normalized to use regular slashes at that point, so there is no point in handling backslashes in paths at all even with Microsoft extensions.

After running it with a hack to dump the paths to stderr they seem to be the same regardless.

[FILENAME] /llvm-tainted/tools/clang/test/Preprocessor/Inputs/include-subdir/subdir1/hdr1.h
[FILENAME] /llvm-tainted/tools/clang/test/Preprocessor/Inputs/include-subdir/subdir1/hdr2.h

I've also extended the tests to cover scenarios with mixed slashes in MS compatibility mode and removed the unnecessary check.

[kristina]

Need @rsmith to bless this as it's introducing a nonstandard extension, however small it may be. The original diff did have a consensus on it, so I didn't really put up a formal RFC on cfe-dev.

[kristina]

@rsmith Ping.

[rsmith]

Generally, I think this is a good, useful feature, but there's one point from http://clang.llvm.org/get_involved.html 's checklist for accepting language extensions on which its case is weak, as reflected by this feedback from @alexr on D17741:

I don't think we want to add a fundamental new preprocessor feature like __FILE_BASENAME__ without at least getting some early buy-in from the WG14 and WG21 committees.

Specifically: have you suggested this feature on the WG14 or WG21 mailing lists? I'm not especially opposed to carrying this feature as a Clang extension, but from http://clang.llvm.org/get_involved.html, "Clang should drive the standard, not diverge from it", and we should at least try to push for standardizing this if we think it's worthwhile as an alternative to __FILE__.

Failing that, have you asked the GCC developers whether they'd be amenable to providing this functionality?

[kristina]

Landing this as discussed on IRC, will try to push it forward with WG14.

I think having something like this as part of the standard would benefit a lot, since currently the "unofficial" way of doing this for either GCC or Clang involves several nonstandard builtins and __FILE__ which causes difficulties in reproducible builds as code emitted in read only data sections may still differ depending on optimization levels and other factors. This macro on the other hand provides a guarantee that only the last path component is rendered.

[kristina]

Reverted in rL360842 as Windows bots were failing.

I suspect the MSVCCompat case may need to be handled differently depending on the host OS similar to PPDirectives.cpp:

  if (LangOpts.MSVCCompat) {
    NormalizedPath = Filename.str();
#ifndef _WIN32
    llvm::sys::path::native(NormalizedPath);
#endif
  }

Reopening this for now, will try to get a local Windows builder set up and work out what the problem is before relanding.

[hintonda]

In D61756#1504109, @kristina wrote:

Reverted in rL360842 as Windows bots were failing.

I suspect the MSVCCompat case may need to be handled differently depending on the host OS similar to PPDirectives.cpp:

  if (LangOpts.MSVCCompat) {
    NormalizedPath = Filename.str();
#ifndef _WIN32
    llvm::sys::path::native(NormalizedPath);
#endif
  }

Reopening this for now, will try to get a local Windows builder set up and work out what the problem is before relanding.

Can't you just always use llvm::sys::path::filename(PLFileName)? It defaults to the native style.

[kristina]

Revised to use llvm::sys::path::filename to avoid issues on Windows hosts.

[MaskRay]

@rmisth wrote: "Clang should drive the standard, not diverge from it", and we should at least try to push for standardizing this if we think it's worthwhile as an alternative to FILE.

In D61756#1505296, @kristina wrote:

Revised to use llvm::sys::path::filename to avoid issues on Windows hosts.

Hi @kristina, have you followed up with the extension on WG14 or WG21 mailing lists? There is a similar GCC feature request which you may want to comment as well https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77488

[kristina]

In D61756#2003836, @MaskRay wrote:

@rmisth wrote: "Clang should drive the standard, not diverge from it", and we should at least try to push for standardizing this if we think it's worthwhile as an alternative to FILE.

In D61756#1505296, @kristina wrote:

Revised to use llvm::sys::path::filename to avoid issues on Windows hosts.

Hi @kristina, have you followed up with the extension on WG14 or WG21 mailing lists? There is a similar GCC feature request which you may want to comment as well https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77488

I did try bringing this up with GCC developers at one point but the overwhelming consensus was that there wasn't a need for such an extension as 'it's possible to just #define FILENAME "foo.c"', with regards to WG14, I was told it was best to get it adopted by other compiler vendors first (ie. GCC). Been pretty sick recently so haven't had time to chase up a lot of loose ends up, should probably get back to that, but it seems WG21 may be the best bet at this point. I'll try to get back on top of everything soon, sorry. Have a pretty big backlog of other things that have also accumulated too.

[MaskRay]

In D61756#2003847, @kristina wrote:

In D61756#2003836, @MaskRay wrote:

@rmisth wrote: "Clang should drive the standard, not diverge from it", and we should at least try to push for standardizing this if we think it's worthwhile as an alternative to FILE.

In D61756#1505296, @kristina wrote:

Revised to use llvm::sys::path::filename to avoid issues on Windows hosts.

Hi @kristina, have you followed up with the extension on WG14 or WG21 mailing lists? There is a similar GCC feature request which you may want to comment as well https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77488

I did try bringing this up with GCC developers at one point but the overwhelming consensus was that there wasn't a need for such an extension as 'it's possible to just #define FILENAME "foo.c"', with regards to WG14, I was told it was best to get it adopted by other compiler vendors first (ie. GCC). Been pretty sick recently so haven't had time to chase up a lot of loose ends up, should probably get back to that, but it seems WG21 may be the best bet at this point. I'll try to get back on top of everything soon, sorry. Have a pretty big backlog of other things that have also accumulated too.

Thanks for your prompt reply. Hope you will get better soon. I was searching for some unrelated things on GCC's issue tracker when I happened to find Proposal for __FILENAME_ONLY__ which reminded me of this issue. Glad that you've brought up this to them. I just want the compiler extensions to be compatible if they are going to implement the similar thing.

include/clang/Lex/Preprocessor.h

class Preprocessor {
   /// objects internal to the Preprocessor.
   llvm::BumpPtrAllocator BP;
 
   /// Identifiers for builtin macros and other builtins.
   IdentifierInfo *Ident__LINE__, *Ident__FILE__;   // __LINE__, __FILE__
   IdentifierInfo *Ident__DATE__, *Ident__TIME__;   // __DATE__, __TIME__
   IdentifierInfo *Ident__INCLUDE_LEVEL__;          // __INCLUDE_LEVEL__
   IdentifierInfo *Ident__BASE_FILE__;              // __BASE_FILE__
+  IdentifierInfo *Ident__FILE_NAME__;              // __FILE_NAME__
   IdentifierInfo *Ident__TIMESTAMP__;              // __TIMESTAMP__
   IdentifierInfo *Ident__COUNTER__;                // __COUNTER__
   IdentifierInfo *Ident_Pragma, *Ident__pragma;    // _Pragma, __pragma
   IdentifierInfo *Ident__identifier;               // __identifier
   IdentifierInfo *Ident__VA_ARGS__;                // __VA_ARGS__
   IdentifierInfo *Ident__VA_OPT__;                 // __VA_OPT__
   IdentifierInfo *Ident__has_feature;              // __has_feature
   IdentifierInfo *Ident__has_extension;            // __has_extension

lib/Lex/PPMacroExpansion.cpp

 #include "llvm/ADT/SmallString.h"
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/Support/Casting.h"
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/Format.h"
+#include "llvm/Support/Path.h"
 #include "llvm/Support/raw_ostream.h"
 #include <algorithm>
 #include <cassert>
 #include <cstddef>
 #include <cstring>
 #include <ctime>
 #include <string>
 #include <tuple>
if (LangOpts.MicrosoftExt) {
     Ident__identifier = RegisterBuiltinMacro(*this, "__identifier");
     Ident__pragma = RegisterBuiltinMacro(*this, "__pragma");
   } else {
     Ident__identifier = nullptr;
     Ident__pragma = nullptr;
   }
 
   // Clang Extensions.
+  Ident__FILE_NAME__      = RegisterBuiltinMacro(*this, "__FILE_NAME__");
   Ident__has_feature      = RegisterBuiltinMacro(*this, "__has_feature");
   Ident__has_extension    = RegisterBuiltinMacro(*this, "__has_extension");
   Ident__has_builtin      = RegisterBuiltinMacro(*this, "__has_builtin");
   Ident__has_attribute    = RegisterBuiltinMacro(*this, "__has_attribute");
   Ident__has_c_attribute  = RegisterBuiltinMacro(*this, "__has_c_attribute");
   Ident__has_declspec = RegisterBuiltinMacro(*this, "__has_declspec_attribute");
   Ident__has_include      = RegisterBuiltinMacro(*this, "__has_include");
   Ident__has_include_next = RegisterBuiltinMacro(*this, "__has_include_next");
if (II == Ident__LINE__) {
     // Skip down through expansion points until we find a file loc for the
     // end of the expansion history.
     Loc = SourceMgr.getExpansionRange(Loc).getEnd();
     PresumedLoc PLoc = SourceMgr.getPresumedLoc(Loc);
 
     // __LINE__ expands to a simple numeric value.
     OS << (PLoc.isValid()? PLoc.getLine() : 1);
     Tok.setKind(tok::numeric_constant);
-  } else if (II == Ident__FILE__ || II == Ident__BASE_FILE__) {
+  } else if (II == Ident__FILE__ || II == Ident__BASE_FILE__ ||
+             II == Ident__FILE_NAME__) {
     // C99 6.10.8: "__FILE__: The presumed name of the current source file (a
     // character string literal)". This can be affected by #line.
     PresumedLoc PLoc = SourceMgr.getPresumedLoc(Tok.getLocation());
 
     // __BASE_FILE__ is a GNU extension that returns the top of the presumed
     // #include stack instead of the current file.
     if (II == Ident__BASE_FILE__ && PLoc.isValid()) {
       SourceLocation NextLoc = PLoc.getIncludeLoc();
       while (NextLoc.isValid()) {
         PLoc = SourceMgr.getPresumedLoc(NextLoc);
         if (PLoc.isInvalid())
           break;
 
         NextLoc = PLoc.getIncludeLoc();
       }
     }
 
     // Escape this filename.  Turn '\' -> '\\' '"' -> '\"'
     SmallString<128> FN;
     if (PLoc.isValid()) {
+      // __FILE_NAME__ is a Clang-specific extension that expands to the
+      // the last part of __FILE__.
+      if (II == Ident__FILE_NAME__) {
+        // Try to get the last path component, failing that return the original
+        // presumed location.
+        StringRef PLFileName = llvm::sys::path::filename(PLoc.getFilename());
+        if (PLFileName != "")
+          FN += PLFileName;
+        else
+          FN += PLoc.getFilename();
+      } else {
         FN += PLoc.getFilename();
+      }
       Lexer::Stringify(FN);
       OS << '"' << FN << '"';
     }
     Tok.setKind(tok::string_literal);
   } else if (II == Ident__DATE__) {
     Diag(Tok.getLocation(), diag::warn_pp_date_time);
     if (!DATELoc.isValid())
       ComputeDATE_TIME(DATELoc, TIMELoc, *this);

test/Preprocessor/Inputs/include-subdir/file_name_macro_include.h

+3: __FILE_NAME__
+4: "file_name_macro_include.h"
+#ifdef MS
+// Should be the same even when included with backslash.
+5: __FILE_NAME__
+#endif

test/Preprocessor/Inputs/include-subdir/h

+6: __FILE_NAME__

test/Preprocessor/Inputs/include-subdir/subdir1/hdr1.h

+7: __FILE_NAME__

test/Preprocessor/Inputs/include-subdir/subdir1/hdr2.h

+8: __FILE_NAME__

test/Preprocessor/file_name_macro.c

+// RUN: %clang_cc1 -E %s -I%S/Inputs | FileCheck -strict-whitespace %s
+// RUN: %clang_cc1 -fms-compatibility -DMS -E %s -I%S/Inputs | FileCheck -check-prefix=CHECK-MS -strict-whitespace %s 
+// RUN: %clang_cc1 -E %s -I%S/Inputs -DBADINC -verify
+
+#ifdef BADINC
+
+// Paranoia.
+
+__FILE_NAME__
+#include <include-subdir/> // expected-error {{file not found}}
+__FILE_NAME__
+
+#else
+
+// Reference.
+1: "file_name_macro.c"
+
+// Ensure it expands correctly for this file.
+2: __FILE_NAME__
+
+// CHECK: {{^}}1: "file_name_macro.c"
+// CHECK: {{^}}2: "file_name_macro.c"
+
+// Test if inclusion works right.
+#ifdef MS
+#include <include-subdir\file_name_macro_include.h>
+// MS compatibility allows for mixed separators in paths.
+#include <include-subdir/subdir1\hdr1.h>
+#include <include-subdir\subdir1/hdr2.h>
+#else
+#include <include-subdir/file_name_macro_include.h>
+#endif
+
+#include <include-subdir/h>
+
+// CHECK: {{^}}3: "file_name_macro_include.h"
+// CHECK: {{^}}4: "file_name_macro_include.h"
+// CHECK-NOT: {{^}}5: "file_name_macro_include.h"
+// CHECK-MS: {{^}}5: "file_name_macro_include.h"
+// CHECK: {{^}}6: "h"
+// CHECK-MS: {{^}}7: "hdr1.h"
+// CHECK-MS: {{^}}8: "hdr2.h"
+
+#endif