[swift-evolution] [Pitch] Introducing #fileName debug identifier

[Chris Lattner]

> On Mar 12, 2016, at 7:27 PM, Dmitri Gribenko via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Sat, Mar 12, 2016 at 7:04 PM, Erica Sadun via swift-evolution
> <swift-evolution at swift.org> wrote:
>> Here is a small one as pitches go, but I think it embraces the spirit of the
>> Groff (http://bit.ly/1pn47Yr).
>> 
>> Of all the possible expansions brought up in the SE-0028  discussion on
>> modernizing
>> debug identifiers, I would get a lot of use out of `#fileName`  for my debug
>> logging.
>> A simple websearch for `__FILE__ lastPathComponent` yields page after page
>> of results
>> across both Swift and Objective-C.
>> 
>> My idea is that a `#fileName` debug identifier would return the file name
>> and not the entire
>> path for logging.
> 
> It should be OK to have multiple files with the same name in the
> project.  For example, in the Swift compiler we have Decl.cpp in both
> Clang and Swift.  It is important to distinguish these in the
> assertion messages.
> 
> Thus, I'd suggest to consider instead passing the project directory to
> the compiler, so that the compiler can provide a file name relative to
> the project root.

If it is practical to get the module-relative path, I’d rather see us switch #file to produce *that*, and introduce a #fullPath that produces the current behavior.  Rationale: we want to encourage deterministic and stable builds wherever possible, and including the full path to a source file breaks the ability to build in different directories (e.g. two different users’s homedirs) and get the same executable out.

-Chris

> 
> You can even go as far as replacing the project root with the
> project-version string.  For example:
> 
> #relativeFileName could expand to
> "<MyStringExtras-1.0>/String+KnuthMorrisPrattSearch.swift"
> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution