Question about include stack printing on diagnostic notes

Not too long ago, Richard added an option to control whether we display include stacks on notes. Based on feedback from the community, the default of this option was made “off”: we don’t show include stacks for notes.

Would it be possible or desirable to remove this functionality completely? That is, does anyone see value in being able to enable these stacks under certain circumstances?

I don’t have a strong opinion here, although I always like deleting code. I’m just refactoring the text diagnostic emission and wanted to not spend time fixing rather than deleting unless this functionality is in active use.

Not too long ago, Richard added an option to control whether we display include stacks on notes. Based on feedback from the community, the default of this option was made "off": we don't show include stacks for notes.

Would it be possible or desirable to remove this functionality completely? That is, does anyone see value in being able to enable these stacks under certain circumstances?

Here's an example where I'd like include stack on the note:

$ cat t.h
struct S {};

$ cat t2.h
#include "t.h"

$ cat t3.h
#include "t.h"

$ cat t.c
#include "t2.h"
#include "t3.h"

$ clang -cc1 t.c
In file included from t.c:2:
In file included from ./t3.h:1:
./t.h:1:8: error: redefinition of 'S'
struct S {};
       ^
./t.h:1:8: note: previous definition is here
struct S {};
       ^
1 error generated.

(No idea how that happened..)

$ clang -cc1 t.c -fdiagnostics-show-note-include-stack
In file included from t.c:2:
In file included from ./t3.h:1:
./t.h:1:8: error: redefinition of 'S'
struct S {};
       ^
In file included from t.c:1:
In file included from ./t2.h:1:
./t.h:1:8: note: previous definition is here
struct S {};
       ^
1 error generated.

(Eureka!)

Interesting example. Is there a heuristic here we could use to actually default some of these back on?

Off the cuff, maybe show it if

  • the note and the diagnostic have the same location, and
  • the include stack for the diagnostic and the note differ, and
  • the include stack for the note differs from that of any previous notes for that diagnostic

How about show when the FileEntry of the note is the same as a previous note/warning but different FileID.

Can you explain this in terms that the average user of Clang (rather than developer) would understand? I think i understand it, but i’m not confident.

A FileEntry refers to the file in the file system but if the same source file (same FileEntry) is #include’d more than once then it gets a unique FileID each time.
So if we have 2 diagnostics that point inside the same file but inside different FileIDs it means they refer to different inclusions of the same file, thus it’d be useful to see the inclusion stacks in such a case.