Assure DIFiles get the directory name during IRCodeGen

[lanza]

PDB generation assumes DIFiles have both a filename and a directory.
IRGenDebugInfoImpl currently checks if an absolute path is given for
the Filename and if not it just moves forward with only the filename
which causes PDB generation to be broken.

Clang handles a non absolute path for a file by by first querying the
DebugCompilationDir then the IGM.CWDName and lastly just getting
llvm::sys::fs::current_path. We should do the same here.

[lanza]

@swift-ci please test

[compnerd]

A newline before this line would be nice.

[adrian-prantl]

This is not the right place to call current_path. Instead, we should make sure that the frontend or driver is setting IGM.getOptions().DebugCompilationDir correctly.

[adrian-prantl]

Is that feasible?

[compnerd]

@adrian-prantl, hmm... the frontend already does that if you are asking for more than line tables.

  if (Opts.DebugInfoLevel > IRGenDebugInfoLevel::LineTables) {
    llvm::SmallString<256> cwd;
    llvm:;sys::fs::current_path(cwd);
    Opts.DebugCompilationDir = cwd.str();
  }

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 7334a18d2434715094ee43abc1e6db2cfc49a17e

[compnerd]

Okay, so that is the DI for the synthetic main that the compiler will emit that causes the invalid DI. I think that this is the correct way to handle that @adrian-prantl

[compnerd]

@swift-ci please test

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 7334a18d2434715094ee43abc1e6db2cfc49a17e

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - dbe88b9

[adrian-prantl]

@compnerd I'm confused. If the frontend is always setting Opts.DebugCompilationDir, why do we need to query llvm::sys::fs again here?

[compnerd]

@adrian-prantl the frontend is setting it for the user requested compilation. This is the synthetic (compiler generated) [in memory] buffer that has the compiler provided main function. This is constructed in a synthetic file <compiler-generated> which does not have a compiler directory set. In such a case, the current directory is what we should be setting the directory to for the debug metadata.

[lanza]

In lib/FrontEnd/CompilerInvocation.cpp we have

if (Opts.DebugInfoLevel > IRGenDebugInfoLevel::LineTables) {
  if (Args.hasArg(options::OPT_debug_info_store_invocation)) {
    ArgStringList RenderedArgs;
    for (auto A : Args)
      A->render(Args, RenderedArgs);
    CompilerInvocation::buildDebugFlags(Opts.DebugFlags,
                                        RenderedArgs, SDKPath,
                                        ResourceDir);
  }
  // TODO: Should we support -fdebug-compilation-dir?
  llvm::SmallString<256> cwd;
  llvm::sys::fs::current_path(cwd);
  Opts.DebugCompilationDir = cwd.str();
}

so this seems to still be necessary regardless.

[adrian-prantl]

Oh, is the problem that the <compiler-generated> file doesn't have a directory but in PDB it needs one?

I still have this unmerged patch over in #22392 which brings Swift closer to Clang and it specifically handles these placeholder files differently. That patch makes every file path absolute except for <compiler-generated>. IIUC, all you really need is to disable that exception when building for PDB?

[adrian-prantl]

Basically all you should need to do is add special handling for the PDB case here

      File = RemappedFile;
       // Leave <compiler-generated> & friends as is, without directory.
       if (!(File.startswith("<") && File.endswith(">")))
         Dir = CurDir;
     }

and substitute Opts.DebugCompilationDir

[compnerd]

Not sure that I like the way that we identify the synthetic file, but sounds like your suggestion should do the trick.

[adrian-prantl]

Agreed. A synthetic bit on the SourceLocation would be more robust.

[lanza]

Solved via adrian-prantl's patch.