[PATCH] D17741: adds __FILE_BASENAME__ builtin macro

[Kristina Brooks via Phabricator via cfe-commits]

kristina added a comment.

I like the idea of just getting the filename reliably, but I think an extension to strip path prefixes is a bit of an overkill especially as yet another compiler flag. I implemented a similar thing in my fork in form of a directive to `__generate(...)` which is my own weird extension to do meta-programming using the preprocessor, that's the implementation with no extra parameters (just as an idea, I know the implementation is not great):

  else if (PS == kMPS_DirectiveFile)
   {
     PresumedLoc PLoc = SourceMgr.getPresumedLoc(Tok.getLocation());
     
     OutBuffer.clear();
     OutBuffer.push_back('"');
     
     if (PLoc.isValid()) {
       TokenBuffer.clear();
       TokenBuffer.append(PLoc.getFilename());
       
       size_t LastSlashPos = TokenBuffer.find_last_of('/');
       if (LastSlashPos != StringRef::npos) {
         std::string LastPathComponent = 
           Lexer::Stringify(TokenBuffer.substr(LastSlashPos+1));
         
         OutBuffer.append(LastPathComponent);
       }
       else {
         Lexer::Stringify(TokenBuffer);
         OutBuffer.append(TokenBuffer.str());
       }
     }
     else {
       OutBuffer.push_back('?');
     }
   }

I think this type of approach (I don't mean the PP extension, just the methodology) for getting the filename without the full path or shedding parts of the full path is a lot nicer. I'm not entirely sure why so many headers are getting pulled in either, though, I think the only issue is the path separator?. Aside from that I don't think this needs a compiler flag, but a macro for just getting the filename reliably in upstream would be nice. Your flag idea means various build systems may have to do gymnastics to find out the right path to strip so it seems cumbersome.


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

https://reviews.llvm.org/D17741