@@ -69,8 +69,7 @@ fn parse_line(file_name: &str, line: &str) -> Vec<Error> {
6969 expected_errors
7070 }
7171 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) ;
7473 }
7574 }
7675 } else {
@@ -82,10 +81,19 @@ fn push_expected_errors(expected_errors: &mut Vec<Error>,
8281 diagnostic : & Diagnostic ,
8382 file_name : & str ) {
8483 // 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 {
8997 Some ( ref code) =>
9098 // FIXME(#33000) -- it'd be better to use a dedicated
9199 // UI harness than to include the line/col number like
@@ -105,7 +113,8 @@ fn push_expected_errors(expected_errors: &mut Vec<Error>,
105113 span. line_start, span. column_start,
106114 span. line_end, span. column_end,
107115 text) ,
108- } ;
116+ }
117+ } ;
109118
110119 // Convert multi-line messages into multiple expected
111120 // errors. We expect to replace these with something
0 commit comments