Don't emit debug line numbers for Swift type forward declarations

[adrian-prantl]

These line numbers are consumed by LLDB and stored in the Declaration object,
but as far as I can tell no user-facing feature relies on this.

Removing the line number can reduce the churn for incremental builds
significantly, since whitespace changes in one file may trigger a recompilation
of any file that uses a type declared below the whitespace change.

rdar://problem/63156560

[adrian-prantl]

@swift-ci test

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - a1b4ea05f4a04f29513e69f24039cb8f70083a47

[adrian-prantl]

@swift-ci test

[slavapestov]

Removing the line number can reduce the churn for incremental builds
significantly, since whitespace changes in one file may trigger a recompilation
of any file that uses a type declared below the whitespace change.

It's actually the opposite problem -- incremental builds don't trigger recompilation of dependencies on whitespace changes, so @davidungar's incremental build test tool was finding false positives by rebuilding unchanged files and observing that the LLVM IR had changed.

[adrian-prantl]

Removing the line number can reduce the churn for incremental builds
significantly, since whitespace changes in one file may trigger a recompilation
of any file that uses a type declared below the whitespace change.

It's actually the opposite problem -- incremental builds don't trigger recompilation of dependencies on whitespace changes, so @davidungar's incremental build test tool was finding false positives by rebuilding unchanged files and observing that the LLVM IR had changed.

I was describing the problem from the perspective of a compiler that correctly tracks the dependencies 😈

[adrian-prantl]

@swift-ci test

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - a1b4ea05f4a04f29513e69f24039cb8f70083a47

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - a1b4ea05f4a04f29513e69f24039cb8f70083a47

[adrian-prantl]

@swift-ci test and merge

[adrian-prantl]

@swift-ci test

[qyang-nj]

Is this change only supposed to remove DW_AT_decl_line. Somehow DW_AT_decl_file is also missing on DW_TAG_structure_type (Swift class) on Xcode 12.5. Is that expected?

[adrian-prantl]

Yes that's the expected behavior. What's the use-case you have for looking at the source file for a struct?

[qyang-nj]

Thanks for replying, @adrian-prantl. We use that information to identify the owner of flaky tests. In our codebase, every source file has an owning team which is defined in a special file in one of the parent directories. The unit test report only contains class name and method name, not the source file. So we use dwarfdump -f <class name> UnitTest.xctest.dSYM to locate the source file of the test case. Thus we know who owns that test case and notify them. On Xcode 12.5, we won't be able to get that information directly from the dwarfdump any more.

[adrian-prantl]

If you dwarfdump -p --name <class_name>, does the parent module or the compile unit contain enough information for you to extract the same information?

[qyang-nj]

Yes, it does! DW_TAG_compile_unit has the source file information at DW_AT_name. Is DW_TAG_compile_unit always the top level one? If so, it could simply the parsing logics.

[adrian-prantl]

Is DW_TAG_compile_unit always the top level one?

Yes. See also http://dwarfstd.org/Dwarf5Std.php