maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Misc/caret-diags-macros.c

121 lines
4.3 KiB
C
Raw Normal View History

FileCheckize this test. llvm-svn: 127327
2011-03-09 18:56:54 +08:00
// RUN: %clang_cc1 -fsyntax-only %s 2>&1 | FileCheck %s
Fix rdar://6849429 - -Wunused-value with deeply nested macro expansion generates untraceable warnings The "instantiated from" messages coming from the caret diagnostics system are basically walking the macro expansion tree, emitting each level as it goes. However, it was skipping certain leaves in the tree by skipping up the entire instantiation arm every time it went up one spelling arm. This caused it to miss some things. For example, in this testcase: #define M1(x) x #define M2 1; void foo() { M1(M2) } we now print: /Users/sabre/Desktop/clang-unused-value-macro.c:6:2: warning: expression result unused M1(M2) ^~~~~~ /Users/sabre/Desktop/clang-unused-value-macro.c:6:5: note: instantiated from: M1(M2) ^~ /Users/sabre/Desktop/clang-unused-value-macro.c:3:12: note: instantiated from: #define M2 1; ^ Previously we didn't print the last line, so we never emitted the caret pointing to the 1! Incidentally, the spaces between the lines is really noisy, I think we should reconsider this heuristic (which adds them when the printed code starts too close to the start of the line). The regression test can't use -verify, because -verify doesn't catch notes for macro instantiation history. llvm-svn: 71025
2009-05-06 06:03:18 +08:00
#define M1(x) x
#define M2 1;
void foo() {
FileCheckize this test. llvm-svn: 127327
2011-03-09 18:56:54 +08:00
M1(
M2);
Keep track of which source locations are part of a macro argument instantiation and improve diagnostics which are stem from macro arguments to trace the argument itself back through the layers of macro expansion. This requires some tricky handling of the source locations, as the argument appears to be expanded in the opposite direction from the surrounding macro. This patch provides helper routines that encapsulate the logic and explain the reasoning behind how we step through macros during diagnostic printing. This fixes the rest of the test cases originially in PR9279, and later split out into PR10214 and PR10215. There is still some more work we can do here to improve the macro backtrace, but those will follow as separate patches. llvm-svn: 134660
2011-07-08 07:56:36 +08:00
// CHECK: :7:{{[0-9]+}}: warning: expression result unused
Now that macro expansion notes are real notes and go through the same formatting as any other diagnostic, they will be properly line wrapped and otherwise pretty printed. Let's take advantage of that and the new factoring to add some helpful information to them (much like template backtrace notes and other notes): the name of the macro whose expansion is being noted. This makes a world of difference if caret diagnostics are disabled, making the expansion notes actually useful in this case. It also helps ensure that in edge cases the information the user needs is present. Consider: % nl -ba t5.cc 1 #define M(x, y, z) \ 2 y 3 4 M( 5 1, 6 2, 7 3); We now produce: % ./bin/clang -fsyntax-only t5.cc t5.cc:6:3: error: expected unqualified-id 2, ^ t5.cc:2:3: note: expanded from macro: M y ^ 1 error generated. Without the added information in the note, the name of the macro being expanded would never be shown. This also deletes a FIXME to use the diagnostic formatting. It's not yet clear to me that we *can* do this reasonably, and the production of this message was my primary goal here anyways. I'd love any comments or suggestions on improving these notes, their wording, etc. Currently, I need to make them provide more helpful information in the presence of a token-pasting buffer, and I'm pondering adding something along the lines of "expanded from argument N of macro: ...". llvm-svn: 142127
2011-10-16 17:30:08 +08:00
// CHECK: :4:{{[0-9]+}}: note: expanded from macro: M2
// CHECK: :3:{{[0-9]+}}: note: expanded from macro: M1
Fix rdar://6849429 - -Wunused-value with deeply nested macro expansion generates untraceable warnings The "instantiated from" messages coming from the caret diagnostics system are basically walking the macro expansion tree, emitting each level as it goes. However, it was skipping certain leaves in the tree by skipping up the entire instantiation arm every time it went up one spelling arm. This caused it to miss some things. For example, in this testcase: #define M1(x) x #define M2 1; void foo() { M1(M2) } we now print: /Users/sabre/Desktop/clang-unused-value-macro.c:6:2: warning: expression result unused M1(M2) ^~~~~~ /Users/sabre/Desktop/clang-unused-value-macro.c:6:5: note: instantiated from: M1(M2) ^~ /Users/sabre/Desktop/clang-unused-value-macro.c:3:12: note: instantiated from: #define M2 1; ^ Previously we didn't print the last line, so we never emitted the caret pointing to the 1! Incidentally, the spaces between the lines is really noisy, I think we should reconsider this heuristic (which adds them when the printed code starts too close to the start of the line). The regression test can't use -verify, because -verify doesn't catch notes for macro instantiation history. llvm-svn: 71025
2009-05-06 06:03:18 +08:00
}
#define A 1
#define B A
#define C B
void bar() {
C;
Fix PR9279 - Macro expansion stack trace seriously broken with function-style macros, by not recursively printing notes for other 'instantiated from' notes. This is a one line fix here: + // Don't print recursive instantiation notes from an instantiation note. + Loc = SM.getSpellingLoc(Loc); While here, fix the testcase to be more precise (it got filecheck'ized brutally), and fix EmitCaretDiagnostic to be private and to not pass down the unused 'Level' argument. llvm-svn: 133993
2011-06-28 13:11:33 +08:00
// CHECK: :17:3: warning: expression result unused
Now that macro expansion notes are real notes and go through the same formatting as any other diagnostic, they will be properly line wrapped and otherwise pretty printed. Let's take advantage of that and the new factoring to add some helpful information to them (much like template backtrace notes and other notes): the name of the macro whose expansion is being noted. This makes a world of difference if caret diagnostics are disabled, making the expansion notes actually useful in this case. It also helps ensure that in edge cases the information the user needs is present. Consider: % nl -ba t5.cc 1 #define M(x, y, z) \ 2 y 3 4 M( 5 1, 6 2, 7 3); We now produce: % ./bin/clang -fsyntax-only t5.cc t5.cc:6:3: error: expected unqualified-id 2, ^ t5.cc:2:3: note: expanded from macro: M y ^ 1 error generated. Without the added information in the note, the name of the macro being expanded would never be shown. This also deletes a FIXME to use the diagnostic formatting. It's not yet clear to me that we *can* do this reasonably, and the production of this message was my primary goal here anyways. I'd love any comments or suggestions on improving these notes, their wording, etc. Currently, I need to make them provide more helpful information in the presence of a token-pasting buffer, and I'm pondering adding something along the lines of "expanded from argument N of macro: ...". llvm-svn: 142127
2011-10-16 17:30:08 +08:00
// CHECK: :15:11: note: expanded from macro: C
// CHECK: :14:11: note: expanded from macro: B
// CHECK: :13:11: note: expanded from macro: A
Fix rdar://6849429 - -Wunused-value with deeply nested macro expansion generates untraceable warnings The "instantiated from" messages coming from the caret diagnostics system are basically walking the macro expansion tree, emitting each level as it goes. However, it was skipping certain leaves in the tree by skipping up the entire instantiation arm every time it went up one spelling arm. This caused it to miss some things. For example, in this testcase: #define M1(x) x #define M2 1; void foo() { M1(M2) } we now print: /Users/sabre/Desktop/clang-unused-value-macro.c:6:2: warning: expression result unused M1(M2) ^~~~~~ /Users/sabre/Desktop/clang-unused-value-macro.c:6:5: note: instantiated from: M1(M2) ^~ /Users/sabre/Desktop/clang-unused-value-macro.c:3:12: note: instantiated from: #define M2 1; ^ Previously we didn't print the last line, so we never emitted the caret pointing to the 1! Incidentally, the spaces between the lines is really noisy, I think we should reconsider this heuristic (which adds them when the printed code starts too close to the start of the line). The regression test can't use -verify, because -verify doesn't catch notes for macro instantiation history. llvm-svn: 71025
2009-05-06 06:03:18 +08:00
}
fix a bug in SourceManager::getInstantiationLocSlowCase, where we'd add an offset from the spelling location space to the instantiation location, which doesn't make sense and would lead up to the text diagnostics crashing when presented with non-sensical locations. This fixes rdar://7597492, a crash on 255.vortex. llvm-svn: 96004
2010-02-13 03:31:35 +08:00
// rdar://7597492
#define sprintf(str, A, B) \
__builtin___sprintf_chk (str, 0, 42, A, B)
void baz(char *Msg) {
sprintf(Msg, " sizeof FoooLib : =%3u\n", 12LL);
}
Fix PR9279 - Macro expansion stack trace seriously broken with function-style macros, by not recursively printing notes for other 'instantiated from' notes. This is a one line fix here: + // Don't print recursive instantiation notes from an instantiation note. + Loc = SM.getSpellingLoc(Loc); While here, fix the testcase to be more precise (it got filecheck'ized brutally), and fix EmitCaretDiagnostic to be private and to not pass down the unused 'Level' argument. llvm-svn: 133993
2011-06-28 13:11:33 +08:00
Keep track of which source locations are part of a macro argument instantiation and improve diagnostics which are stem from macro arguments to trace the argument itself back through the layers of macro expansion. This requires some tricky handling of the source locations, as the argument appears to be expanded in the opposite direction from the surrounding macro. This patch provides helper routines that encapsulate the logic and explain the reasoning behind how we step through macros during diagnostic printing. This fixes the rest of the test cases originially in PR9279, and later split out into PR10214 and PR10215. There is still some more work we can do here to improve the macro backtrace, but those will follow as separate patches. llvm-svn: 134660
2011-07-08 07:56:36 +08:00
// PR9279: comprehensive tests for multi-level macro back traces
#define macro_args1(x) x
#define macro_args2(x) macro_args1(x)
#define macro_args3(x) macro_args2(x)
#define macro_many_args1(x, y, z) y
#define macro_many_args2(x, y, z) macro_many_args1(x, y, z)
#define macro_many_args3(x, y, z) macro_many_args2(x, y, z)
Fix PR9279 - Macro expansion stack trace seriously broken with function-style macros, by not recursively printing notes for other 'instantiated from' notes. This is a one line fix here: + // Don't print recursive instantiation notes from an instantiation note. + Loc = SM.getSpellingLoc(Loc); While here, fix the testcase to be more precise (it got filecheck'ized brutally), and fix EmitCaretDiagnostic to be private and to not pass down the unused 'Level' argument. llvm-svn: 133993
2011-06-28 13:11:33 +08:00
Keep track of which source locations are part of a macro argument instantiation and improve diagnostics which are stem from macro arguments to trace the argument itself back through the layers of macro expansion. This requires some tricky handling of the source locations, as the argument appears to be expanded in the opposite direction from the surrounding macro. This patch provides helper routines that encapsulate the logic and explain the reasoning behind how we step through macros during diagnostic printing. This fixes the rest of the test cases originially in PR9279, and later split out into PR10214 and PR10215. There is still some more work we can do here to improve the macro backtrace, but those will follow as separate patches. llvm-svn: 134660
2011-07-08 07:56:36 +08:00
void test() {
macro_args3(1);
// CHECK: {{.*}}:43:15: warning: expression result unused
// Also check that the 'caret' printing agrees with the location here where
// its easy to FileCheck.
// CHECK-NEXT: macro_args3(1);
// CHECK-NEXT: ~~~~~~~~~~~~^~
Now that macro expansion notes are real notes and go through the same formatting as any other diagnostic, they will be properly line wrapped and otherwise pretty printed. Let's take advantage of that and the new factoring to add some helpful information to them (much like template backtrace notes and other notes): the name of the macro whose expansion is being noted. This makes a world of difference if caret diagnostics are disabled, making the expansion notes actually useful in this case. It also helps ensure that in edge cases the information the user needs is present. Consider: % nl -ba t5.cc 1 #define M(x, y, z) \ 2 y 3 4 M( 5 1, 6 2, 7 3); We now produce: % ./bin/clang -fsyntax-only t5.cc t5.cc:6:3: error: expected unqualified-id 2, ^ t5.cc:2:3: note: expanded from macro: M y ^ 1 error generated. Without the added information in the note, the name of the macro being expanded would never be shown. This also deletes a FIXME to use the diagnostic formatting. It's not yet clear to me that we *can* do this reasonably, and the production of this message was my primary goal here anyways. I'd love any comments or suggestions on improving these notes, their wording, etc. Currently, I need to make them provide more helpful information in the presence of a token-pasting buffer, and I'm pondering adding something along the lines of "expanded from argument N of macro: ...". llvm-svn: 142127
2011-10-16 17:30:08 +08:00
// CHECK: {{.*}}:36:36: note: expanded from macro: macro_args3
// CHECK: {{.*}}:35:36: note: expanded from macro: macro_args2
// CHECK: {{.*}}:34:24: note: expanded from macro: macro_args1
Fix PR9279 - Macro expansion stack trace seriously broken with function-style macros, by not recursively printing notes for other 'instantiated from' notes. This is a one line fix here: + // Don't print recursive instantiation notes from an instantiation note. + Loc = SM.getSpellingLoc(Loc); While here, fix the testcase to be more precise (it got filecheck'ized brutally), and fix EmitCaretDiagnostic to be private and to not pass down the unused 'Level' argument. llvm-svn: 133993
2011-06-28 13:11:33 +08:00
Keep track of which source locations are part of a macro argument instantiation and improve diagnostics which are stem from macro arguments to trace the argument itself back through the layers of macro expansion. This requires some tricky handling of the source locations, as the argument appears to be expanded in the opposite direction from the surrounding macro. This patch provides helper routines that encapsulate the logic and explain the reasoning behind how we step through macros during diagnostic printing. This fixes the rest of the test cases originially in PR9279, and later split out into PR10214 and PR10215. There is still some more work we can do here to improve the macro backtrace, but those will follow as separate patches. llvm-svn: 134660
2011-07-08 07:56:36 +08:00
macro_many_args3(
1,
2,
3);
// CHECK: {{.*}}:55:5: warning: expression result unused
Now that macro expansion notes are real notes and go through the same formatting as any other diagnostic, they will be properly line wrapped and otherwise pretty printed. Let's take advantage of that and the new factoring to add some helpful information to them (much like template backtrace notes and other notes): the name of the macro whose expansion is being noted. This makes a world of difference if caret diagnostics are disabled, making the expansion notes actually useful in this case. It also helps ensure that in edge cases the information the user needs is present. Consider: % nl -ba t5.cc 1 #define M(x, y, z) \ 2 y 3 4 M( 5 1, 6 2, 7 3); We now produce: % ./bin/clang -fsyntax-only t5.cc t5.cc:6:3: error: expected unqualified-id 2, ^ t5.cc:2:3: note: expanded from macro: M y ^ 1 error generated. Without the added information in the note, the name of the macro being expanded would never be shown. This also deletes a FIXME to use the diagnostic formatting. It's not yet clear to me that we *can* do this reasonably, and the production of this message was my primary goal here anyways. I'd love any comments or suggestions on improving these notes, their wording, etc. Currently, I need to make them provide more helpful information in the presence of a token-pasting buffer, and I'm pondering adding something along the lines of "expanded from argument N of macro: ...". llvm-svn: 142127
2011-10-16 17:30:08 +08:00
// CHECK: {{.*}}:40:55: note: expanded from macro: macro_many_args3
// CHECK: {{.*}}:39:55: note: expanded from macro: macro_many_args2
// CHECK: {{.*}}:38:35: note: expanded from macro: macro_many_args1
Keep track of which source locations are part of a macro argument instantiation and improve diagnostics which are stem from macro arguments to trace the argument itself back through the layers of macro expansion. This requires some tricky handling of the source locations, as the argument appears to be expanded in the opposite direction from the surrounding macro. This patch provides helper routines that encapsulate the logic and explain the reasoning behind how we step through macros during diagnostic printing. This fixes the rest of the test cases originially in PR9279, and later split out into PR10214 and PR10215. There is still some more work we can do here to improve the macro backtrace, but those will follow as separate patches. llvm-svn: 134660
2011-07-08 07:56:36 +08:00
macro_many_args3(
1,
M2,
3);
// CHECK: {{.*}}:64:5: warning: expression result unused
Now that macro expansion notes are real notes and go through the same formatting as any other diagnostic, they will be properly line wrapped and otherwise pretty printed. Let's take advantage of that and the new factoring to add some helpful information to them (much like template backtrace notes and other notes): the name of the macro whose expansion is being noted. This makes a world of difference if caret diagnostics are disabled, making the expansion notes actually useful in this case. It also helps ensure that in edge cases the information the user needs is present. Consider: % nl -ba t5.cc 1 #define M(x, y, z) \ 2 y 3 4 M( 5 1, 6 2, 7 3); We now produce: % ./bin/clang -fsyntax-only t5.cc t5.cc:6:3: error: expected unqualified-id 2, ^ t5.cc:2:3: note: expanded from macro: M y ^ 1 error generated. Without the added information in the note, the name of the macro being expanded would never be shown. This also deletes a FIXME to use the diagnostic formatting. It's not yet clear to me that we *can* do this reasonably, and the production of this message was my primary goal here anyways. I'd love any comments or suggestions on improving these notes, their wording, etc. Currently, I need to make them provide more helpful information in the presence of a token-pasting buffer, and I'm pondering adding something along the lines of "expanded from argument N of macro: ...". llvm-svn: 142127
2011-10-16 17:30:08 +08:00
// CHECK: {{.*}}:4:12: note: expanded from macro: M2
// CHECK: {{.*}}:40:55: note: expanded from macro: macro_many_args3
// CHECK: {{.*}}:39:55: note: expanded from macro: macro_many_args2
// CHECK: {{.*}}:38:35: note: expanded from macro: macro_many_args1
Keep track of which source locations are part of a macro argument instantiation and improve diagnostics which are stem from macro arguments to trace the argument itself back through the layers of macro expansion. This requires some tricky handling of the source locations, as the argument appears to be expanded in the opposite direction from the surrounding macro. This patch provides helper routines that encapsulate the logic and explain the reasoning behind how we step through macros during diagnostic printing. This fixes the rest of the test cases originially in PR9279, and later split out into PR10214 and PR10215. There is still some more work we can do here to improve the macro backtrace, but those will follow as separate patches. llvm-svn: 134660
2011-07-08 07:56:36 +08:00
macro_many_args3(
1,
macro_args2(2),
3);
// CHECK: {{.*}}:74:17: warning: expression result unused
// This caret location needs to be printed *inside* a different macro's
// arguments.
// CHECK-NEXT: macro_args2(2),
// CHECK-NEXT: ~~~~~~~~~~~~^~~
Now that macro expansion notes are real notes and go through the same formatting as any other diagnostic, they will be properly line wrapped and otherwise pretty printed. Let's take advantage of that and the new factoring to add some helpful information to them (much like template backtrace notes and other notes): the name of the macro whose expansion is being noted. This makes a world of difference if caret diagnostics are disabled, making the expansion notes actually useful in this case. It also helps ensure that in edge cases the information the user needs is present. Consider: % nl -ba t5.cc 1 #define M(x, y, z) \ 2 y 3 4 M( 5 1, 6 2, 7 3); We now produce: % ./bin/clang -fsyntax-only t5.cc t5.cc:6:3: error: expected unqualified-id 2, ^ t5.cc:2:3: note: expanded from macro: M y ^ 1 error generated. Without the added information in the note, the name of the macro being expanded would never be shown. This also deletes a FIXME to use the diagnostic formatting. It's not yet clear to me that we *can* do this reasonably, and the production of this message was my primary goal here anyways. I'd love any comments or suggestions on improving these notes, their wording, etc. Currently, I need to make them provide more helpful information in the presence of a token-pasting buffer, and I'm pondering adding something along the lines of "expanded from argument N of macro: ...". llvm-svn: 142127
2011-10-16 17:30:08 +08:00
// CHECK: {{.*}}:35:36: note: expanded from macro: macro_args2
// CHECK: {{.*}}:34:24: note: expanded from macro: macro_args1
// CHECK: {{.*}}:40:55: note: expanded from macro: macro_many_args3
// CHECK: {{.*}}:39:55: note: expanded from macro: macro_many_args2
// CHECK: {{.*}}:38:35: note: expanded from macro: macro_many_args1
Keep track of which source locations are part of a macro argument instantiation and improve diagnostics which are stem from macro arguments to trace the argument itself back through the layers of macro expansion. This requires some tricky handling of the source locations, as the argument appears to be expanded in the opposite direction from the surrounding macro. This patch provides helper routines that encapsulate the logic and explain the reasoning behind how we step through macros during diagnostic printing. This fixes the rest of the test cases originially in PR9279, and later split out into PR10214 and PR10215. There is still some more work we can do here to improve the macro backtrace, but those will follow as separate patches. llvm-svn: 134660
2011-07-08 07:56:36 +08:00
}
Switch the token-paste source locations inside of function style macro argument expansion to use the macro argument source locations as well. Add a few tests to exercise this. There is still a bit more work needed here though. llvm-svn: 134674
2011-07-08 09:04:21 +08:00
#define variadic_args1(x, y, ...) y
#define variadic_args2(x, ...) variadic_args1(x, __VA_ARGS__)
#define variadic_args3(x, y, ...) variadic_args2(x, y, __VA_ARGS__)
void test2() {
variadic_args3(1, 2, 3, 4);
// CHECK: {{.*}}:93:21: warning: expression result unused
// CHECK-NEXT: variadic_args3(1, 2, 3, 4);
// CHECK-NEXT: ~~~~~~~~~~~~~~~~~~^~~~~~~~
Now that macro expansion notes are real notes and go through the same formatting as any other diagnostic, they will be properly line wrapped and otherwise pretty printed. Let's take advantage of that and the new factoring to add some helpful information to them (much like template backtrace notes and other notes): the name of the macro whose expansion is being noted. This makes a world of difference if caret diagnostics are disabled, making the expansion notes actually useful in this case. It also helps ensure that in edge cases the information the user needs is present. Consider: % nl -ba t5.cc 1 #define M(x, y, z) \ 2 y 3 4 M( 5 1, 6 2, 7 3); We now produce: % ./bin/clang -fsyntax-only t5.cc t5.cc:6:3: error: expected unqualified-id 2, ^ t5.cc:2:3: note: expanded from macro: M y ^ 1 error generated. Without the added information in the note, the name of the macro being expanded would never be shown. This also deletes a FIXME to use the diagnostic formatting. It's not yet clear to me that we *can* do this reasonably, and the production of this message was my primary goal here anyways. I'd love any comments or suggestions on improving these notes, their wording, etc. Currently, I need to make them provide more helpful information in the presence of a token-pasting buffer, and I'm pondering adding something along the lines of "expanded from argument N of macro: ...". llvm-svn: 142127
2011-10-16 17:30:08 +08:00
// CHECK: {{.*}}:90:53: note: expanded from macro: variadic_args3
// CHECK: {{.*}}:89:50: note: expanded from macro: variadic_args2
// CHECK: {{.*}}:88:35: note: expanded from macro: variadic_args1
Switch the token-paste source locations inside of function style macro argument expansion to use the macro argument source locations as well. Add a few tests to exercise this. There is still a bit more work needed here though. llvm-svn: 134674
2011-07-08 09:04:21 +08:00
}
#define variadic_pasting_args1(x, y, z) y
#define variadic_pasting_args2(x, ...) variadic_pasting_args1(x ## __VA_ARGS__)
#define variadic_pasting_args2a(x, y, ...) variadic_pasting_args1(x, y ## __VA_ARGS__)
#define variadic_pasting_args3(x, y, ...) variadic_pasting_args2(x, y, __VA_ARGS__)
#define variadic_pasting_args3a(x, y, ...) variadic_pasting_args2a(x, y, __VA_ARGS__)
void test3() {
variadic_pasting_args3(1, 2, 3, 4);
// CHECK: {{.*}}:109:32: warning: expression result unused
Now that macro expansion notes are real notes and go through the same formatting as any other diagnostic, they will be properly line wrapped and otherwise pretty printed. Let's take advantage of that and the new factoring to add some helpful information to them (much like template backtrace notes and other notes): the name of the macro whose expansion is being noted. This makes a world of difference if caret diagnostics are disabled, making the expansion notes actually useful in this case. It also helps ensure that in edge cases the information the user needs is present. Consider: % nl -ba t5.cc 1 #define M(x, y, z) \ 2 y 3 4 M( 5 1, 6 2, 7 3); We now produce: % ./bin/clang -fsyntax-only t5.cc t5.cc:6:3: error: expected unqualified-id 2, ^ t5.cc:2:3: note: expanded from macro: M y ^ 1 error generated. Without the added information in the note, the name of the macro being expanded would never be shown. This also deletes a FIXME to use the diagnostic formatting. It's not yet clear to me that we *can* do this reasonably, and the production of this message was my primary goal here anyways. I'd love any comments or suggestions on improving these notes, their wording, etc. Currently, I need to make them provide more helpful information in the presence of a token-pasting buffer, and I'm pondering adding something along the lines of "expanded from argument N of macro: ...". llvm-svn: 142127
2011-10-16 17:30:08 +08:00
// CHECK: {{.*}}:105:72: note: expanded from macro: variadic_pasting_args3
// CHECK: {{.*}}:103:68: note: expanded from macro: variadic_pasting_args2
// CHECK: {{.*}}:102:41: note: expanded from macro: variadic_pasting_args1
Switch the token-paste source locations inside of function style macro argument expansion to use the macro argument source locations as well. Add a few tests to exercise this. There is still a bit more work needed here though. llvm-svn: 134674
2011-07-08 09:04:21 +08:00
variadic_pasting_args3a(1, 2, 3, 4);
Fixed exapnsion range for # and ##. llvm-svn: 141012
2011-10-04 02:39:03 +08:00
// CHECK: {{.*}}:115:30: warning: expression result unused
Now that macro expansion notes are real notes and go through the same formatting as any other diagnostic, they will be properly line wrapped and otherwise pretty printed. Let's take advantage of that and the new factoring to add some helpful information to them (much like template backtrace notes and other notes): the name of the macro whose expansion is being noted. This makes a world of difference if caret diagnostics are disabled, making the expansion notes actually useful in this case. It also helps ensure that in edge cases the information the user needs is present. Consider: % nl -ba t5.cc 1 #define M(x, y, z) \ 2 y 3 4 M( 5 1, 6 2, 7 3); We now produce: % ./bin/clang -fsyntax-only t5.cc t5.cc:6:3: error: expected unqualified-id 2, ^ t5.cc:2:3: note: expanded from macro: M y ^ 1 error generated. Without the added information in the note, the name of the macro being expanded would never be shown. This also deletes a FIXME to use the diagnostic formatting. It's not yet clear to me that we *can* do this reasonably, and the production of this message was my primary goal here anyways. I'd love any comments or suggestions on improving these notes, their wording, etc. Currently, I need to make them provide more helpful information in the presence of a token-pasting buffer, and I'm pondering adding something along the lines of "expanded from argument N of macro: ...". llvm-svn: 142127
2011-10-16 17:30:08 +08:00
// CHECK: {{.*}}:106:71: note: expanded from macro: variadic_pasting_args3a
// CHECK: {{.*}}:104:70: note: expanded from macro: variadic_pasting_args2a
// CHECK: {{.*}}:102:41: note: expanded from macro: variadic_pasting_args1
Switch the token-paste source locations inside of function style macro argument expansion to use the macro argument source locations as well. Add a few tests to exercise this. There is still a bit more work needed here though. llvm-svn: 134674
2011-07-08 09:04:21 +08:00
}