Format the call parameters of a function, not the patterns. #5342
Conversation
This makes the parameters printed in a SemIR `fn` declaration match the arguments printed in a SemIR `call` instruction.
| @@ -101,7 +101,7 @@ fn H() { G(3); } | |||
| // CHECK:STDOUT: %array_type.loc9_24.2: type = array_type %int.convert_checked.loc9_23.2, constants.%i32 [symbolic = %array_type.loc9_24.2 (constants.%array_type)] | |||
| // CHECK:STDOUT: %require_complete: <witness> = require_complete_type %array_type.loc9_24.2 [symbolic = %require_complete (constants.%require_complete.7cb)] | |||
| // CHECK:STDOUT: | |||
| // CHECK:STDOUT: fn(%N.patt.loc4_6.1: %i32) { | |||
| // CHECK:STDOUT: fn() { | |||
There was a problem hiding this comment.
Is it expected that the param goes away entirely for N:! i32?
There was a problem hiding this comment.
Yes; the idea is that the parameter list shown here corresponds to the args that are passed to the call inst. That excludes symbolic parameters, because they aren't passed at run-time.
There was a problem hiding this comment.
Oh, I see it's still listed in the @F name on line 93, so that's good. Otherwise overloads that differ on compttime parameters will be confusing to read. I think it's a bit weird that this differs but you have an intentional reason for doing so and will try to remember what this means.
There was a problem hiding this comment.
Yeah, I assume when we support overloading, we'll have some way to uniquely identify individual overloads in the IR, and we'll use that in place of @F (or whatever).
| @@ -43,9 +43,9 @@ fn Boo[a: ()]() {} | |||
| // CHECK:STDOUT: %Boo.decl: %Boo.type = fn_decl @Boo [concrete = constants.%Boo] {} {} | |||
| // CHECK:STDOUT: } | |||
| // CHECK:STDOUT: | |||
| // CHECK:STDOUT: fn @Foo[<error>: <error>](); | |||
| // CHECK:STDOUT: fn @Foo(); | |||
There was a problem hiding this comment.
Dropping errors from the output seems a bit confusing, can they be preserved?
There was a problem hiding this comment.
If the absence of the errors is a bug, it's not a new bug here, it's a pre-existing bug on line 42, which doesn't show any errors in the declaration of Foo.
There was a problem hiding this comment.
Oh, yes, it would be nice to preserve errors there too.
| @@ -43,9 +43,9 @@ fn Boo[a: ()]() {} | |||
| // CHECK:STDOUT: %Boo.decl: %Boo.type = fn_decl @Boo [concrete = constants.%Boo] {} {} | |||
| // CHECK:STDOUT: } | |||
| // CHECK:STDOUT: | |||
| // CHECK:STDOUT: fn @Foo[<error>: <error>](); | |||
| // CHECK:STDOUT: fn @Foo(); | |||
There was a problem hiding this comment.
Oh, yes, it would be nice to preserve errors there too.
| @@ -101,7 +101,7 @@ fn H() { G(3); } | |||
| // CHECK:STDOUT: %array_type.loc9_24.2: type = array_type %int.convert_checked.loc9_23.2, constants.%i32 [symbolic = %array_type.loc9_24.2 (constants.%array_type)] | |||
| // CHECK:STDOUT: %require_complete: <witness> = require_complete_type %array_type.loc9_24.2 [symbolic = %require_complete (constants.%require_complete.7cb)] | |||
| // CHECK:STDOUT: | |||
| // CHECK:STDOUT: fn(%N.patt.loc4_6.1: %i32) { | |||
| // CHECK:STDOUT: fn() { | |||
There was a problem hiding this comment.
Oh, I see it's still listed in the @F name on line 93, so that's good. Otherwise overloads that differ on compttime parameters will be confusing to read. I think it's a bit weird that this differs but you have an intentional reason for doing so and will try to remember what this means.
…anguage#5342) This makes the parameters printed in a SemIR `fn` declaration match the arguments printed in a SemIR `call` instruction.
This makes the parameters printed in a SemIR
fndeclaration match the arguments printed in a SemIRcallinstruction.