@@ -69,8 +69,7 @@ fn parse_line(file_name: &str, line: &str) -> Vec<Error> {
69
69
expected_errors
70
70
}
71
71
Err ( error) => {
72
- println ! ( "failed to decode compiler output as json: `{}`" , error) ;
73
- panic ! ( "failed to decode compiler output as json" ) ;
72
+ panic ! ( "failed to decode compiler output as json: `{}`" , error) ;
74
73
}
75
74
}
76
75
} else {
@@ -82,10 +81,19 @@ fn push_expected_errors(expected_errors: &mut Vec<Error>,
82
81
diagnostic : & Diagnostic ,
83
82
file_name : & str ) {
84
83
// We only consider messages pertaining to the current file.
85
- let matching_spans =
86
- || diagnostic. spans . iter ( ) . filter ( |span| span. file_name == file_name) ;
87
- let with_code =
88
- |span : & DiagnosticSpan , text : & str | match diagnostic. code {
84
+ let matching_spans = || {
85
+ diagnostic. spans . iter ( ) . filter ( |span| span. file_name == file_name)
86
+ } ;
87
+
88
+ // We break the output into multiple lines, and then append the
89
+ // [E123] to every line in the output. This may be overkill. The
90
+ // intention was to match existing tests that do things like "//|
91
+ // found `i32` [E123]" and expect to match that somewhere, and yet
92
+ // also ensure that `//~ ERROR E123` *always* works. The
93
+ // assumption is that these multi-line error messages are on their
94
+ // way out anyhow.
95
+ let with_code = |span : & DiagnosticSpan , text : & str | {
96
+ match diagnostic. code {
89
97
Some ( ref code) =>
90
98
// FIXME(#33000) -- it'd be better to use a dedicated
91
99
// UI harness than to include the line/col number like
@@ -105,7 +113,8 @@ fn push_expected_errors(expected_errors: &mut Vec<Error>,
105
113
span. line_start, span. column_start,
106
114
span. line_end, span. column_end,
107
115
text) ,
108
- } ;
116
+ }
117
+ } ;
109
118
110
119
// Convert multi-line messages into multiple expected
111
120
// errors. We expect to replace these with something
0 commit comments