Skip to content

Update most toolchain/check/testdata/interop/cpp tests to use sem ir ranges #5594

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 10 commits into from
Jun 11, 2025

Conversation

bricknerb
Copy link
Contributor

@bricknerb bricknerb commented Jun 3, 2025

All except toolchain/check/testdata/interop/cpp/function_param_int*.carbon and toolchain/check/testdata/interop/cpp/function_return.carbon.

Don't output SemIR for cases that are intended to fail.

… ranges.

Except `no_prelude/function/struct.carbon`, which is being updated in carbon-language#5540.
@github-actions github-actions bot requested a review from zygoloid June 3, 2025 09:38
@bricknerb bricknerb changed the title Update all toolchain/check/testdata/interop/cpp tests to use sem ir ranges. Update all toolchain/check/testdata/interop/cpp tests to use sem ir ranges Jun 3, 2025
// CHECK:STDOUT: fn @F() {
// CHECK:STDOUT: !entry:
// CHECK:STDOUT: %Cpp.ref: <namespace> = name_ref Cpp, imports.%Cpp [concrete = imports.%Cpp]
// CHECK:STDOUT: %int_16.1: Core.IntLiteral = int_value 16 [concrete = constants.%int_16]
// CHECK:STDOUT: %i16.1: type = class_type @Int, @Int(constants.%int_16) [concrete = constants.%i16]
// CHECK:STDOUT: %foo.decl: %foo.type = fn_decl @foo [concrete = constants.%foo] {} {}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where are now these fn_decl lines? I don't see them anymore, and they contain useful information for the parameters and the return values as fixed in #5468 .

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've tried to expand the range and debugged this a bit and AFAIU, this is because we ignore imported instructions.

// When there are dump ranges, ignore imported instructions.
auto loc_id = sem_ir_->insts().GetCanonicalLocId(inst_id);
if (loc_id.kind() != LocId::Kind::NodeId) {
return false;
}

However, I think we should have a way to format imported C++ instructions.
@jonmeow, WDYT?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two things:

  1. These should be in the imports block instead of the user block -- Move imported C++ entities to the import block #5616. Note, this may also affect the output you get since imports should be printed when a reference is found, and the name_ref should count. (I'd suggest merging in Move imported C++ entities to the import block #5616 and seeing the resulting behavior, I'm not actually checking)

  2. If Move imported C++ entities to the import block #5616 doesn't get you were you want to be, and/or if you also want to see the declaration, e.g. fn @foo() on line 381, you might keep some files with --dump-sem-ir-ranges=if-present and no ranges specifically for that. At least right now we aren't including those based on range.

That said, if there's a mix where some test cases which want no SemIR and want full SemIR, both can only be indicated by an absence of ranges right now; the only way to do that is to have separate test files, one with =only set and the other with =if-present set.

Copy link
Contributor Author

@bricknerb bricknerb Jun 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jonmeow! Merged.
AFAICT, #5616 has removed the fn_decl lines that @ivanaivanovska referred to.

@ivanaivanovska, can you let me know what important parts of the SemIR are missing now, if any?

Copy link
Contributor

@jonmeow jonmeow Jun 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's still there, it's just moved to the imports section. In this PR, see line 342/354:

// CHECK:STDOUT:   %foo.decl: %foo.type = fn_decl @foo [concrete = constants.%foo] {} {}

https://github.com/carbon-language/carbon-lang/pull/5594/files#diff-697388ec3d2472a66b115558398c52229dd253c95f4c02767ff139724e66723eR354

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jonmeow. Missed that part.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fn_decl lines are now there - that is great, thanks!

The only part that is missing and I think is useful are the fn @foo() lines (e.g on line 381 in function_param_int16.carbon). But as @jonmeow mentions above, it looks like we'll need to refactor the files a bit and have files without ranges to have them, or have no ranges for some of the existing files. For now, I'd keep some of the existing files without ranges before we refactor the files in a separate PR, so that we don't lose these lines completely (e.g. in function_param_int16.carbon, function_param_int32.carbon, function_param_refactor.carbon). But any solution is fine with me as long as we get these lines somewhere.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've revert toolchain/check/testdata/interop/cpp/function_param_*.carbon, so we can continue this discussion in a separate PR, to avoid blocking the rest of the changes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the last file is function_return.carbon, sorry for the typo. If you could also revert that, that would be great.

LGTM otherwise.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@@ -15,16 +14,19 @@

library "[[@TEST_NAME]]";

//@dump-sem-ir-begin
// CHECK:STDERR: fail_import_cpp.carbon:[[@LINE+4]]:1: error: `Cpp` import missing library [CppInteropMissingLibrary]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to note, for cases that are intended to fail (trying to avoid commenting on a TODO-should-pass), you might consider not dumping semir at all. Failures often get a bit boilerplate and it might not be worth keeping all the relevant SemIR around.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed the ranges from cases that are intended to fail.

// CHECK:STDOUT: fn @F() {
// CHECK:STDOUT: !entry:
// CHECK:STDOUT: %Cpp.ref: <namespace> = name_ref Cpp, imports.%Cpp [concrete = imports.%Cpp]
// CHECK:STDOUT: %int_16.1: Core.IntLiteral = int_value 16 [concrete = constants.%int_16]
// CHECK:STDOUT: %i16.1: type = class_type @Int, @Int(constants.%int_16) [concrete = constants.%i16]
// CHECK:STDOUT: %foo.decl: %foo.type = fn_decl @foo [concrete = constants.%foo] {} {}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two things:

  1. These should be in the imports block instead of the user block -- Move imported C++ entities to the import block #5616. Note, this may also affect the output you get since imports should be printed when a reference is found, and the name_ref should count. (I'd suggest merging in Move imported C++ entities to the import block #5616 and seeing the resulting behavior, I'm not actually checking)

  2. If Move imported C++ entities to the import block #5616 doesn't get you were you want to be, and/or if you also want to see the declaration, e.g. fn @foo() on line 381, you might keep some files with --dump-sem-ir-ranges=if-present and no ranges specifically for that. At least right now we aren't including those based on range.

That said, if there's a mix where some test cases which want no SemIR and want full SemIR, both can only be indicated by an absence of ranges right now; the only way to do that is to have separate test files, one with =only set and the other with =if-present set.

@bricknerb bricknerb requested a review from ivanaivanovska June 10, 2025 13:23
Copy link
Contributor

@jonmeow jonmeow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To note, approving for clarity (and to avoid blocking) -- I'm fine with this as-is, as long as @ivanaivanovska is okay.

@bricknerb bricknerb enabled auto-merge June 11, 2025 12:23
@bricknerb bricknerb changed the title Update all toolchain/check/testdata/interop/cpp tests to use sem ir ranges Update most toolchain/check/testdata/interop/cpp tests to use sem ir ranges Jun 11, 2025
@bricknerb bricknerb added this pull request to the merge queue Jun 11, 2025
Merged via the queue into carbon-language:trunk with commit 29d4aae Jun 11, 2025
8 checks passed
@bricknerb bricknerb deleted the ranges branch June 11, 2025 12:48
github-merge-queue bot pushed a commit that referenced this pull request Jun 18, 2025
…on` and `toolchain/check/testdata/interop/cpp/function_return.carbon` tests to use sem ir ranges (#5645)

Follow up of #5594.

Trying to compromise SemIR size, having enough information and
complexity of tests, I've duplicated representative tests to a separate
test file with `--dump-sem-ir-ranges=if-present`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants