Quake: add verification tests for nested QPU calls and static variables

[rajv79]

Description

This pull request adds new negative test coverage for Quake verification errors under both supported dialects (quake1 and quake2).

Two new verification test cases were added under `test/AST-error/ to validate compiler diagnostics for the following scenarios:

• Calling a QPU kernel from within another QPU kernel
• Declaring and using static variables inside a QPU kernel

Each test is executed with --verify and explicitly run against both dialects to ensure consistent verification behavior and improve test coverage.

Checklist:

• [x ] I have added tests to cover my changes.
• I have updated the documentation accordingly.
• [ x ] I have read the CONTRIBUTING document.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[khalatepradnya]

Q: Can you elaborate what is quake1 and quake2 in this context?

[rajv79]

Q: Can you elaborate what is quake1 and quake2 in this context?

@khalatepradnya
From my understanding as a first-time contributor working on this issue,
quake1 and quake2 are the two supported Quake dialect modes in CUDA-Q,
selected via the --std flag.

They represent different versions or interpretations of the Quake language,
primarily to support backward compatibility alongside newer or evolving rules.
The intent of running the tests under both dialects is to ensure that existing
and newly added AST verification errors are consistently exercised across both
modes, as requested by this issue, to improve verification coverage across
dialects.

[rajv79]

Hi @tabo @hartsock @aaronp24 @khalatepradnya

Just a gentle follow-up on this PR. It’s been about 10 days, so I wanted to check if you had a chance to review it or if there’s anything I can help clarify or update.

Thanks a lot for your time!

Vivek

[khalatepradnya]

Q: Can you elaborate what is quake1 and quake2 in this context?

@khalatepradnya From my understanding as a first-time contributor working on this issue, quake1 and quake2 are the two supported Quake dialect modes in CUDA-Q, selected via the --std flag.

They represent different versions or interpretations of the Quake language, primarily to support backward compatibility alongside newer or evolving rules. The intent of running the tests under both dialects is to ensure that existing and newly added AST verification errors are consistently exercised across both modes, as requested by this issue, to improve verification coverage across dialects.

The command line argument std in cudaq-quake is for C++ standard.

cuda-quantum/tools/cudaq-quake/cudaq-quake.cpp

Lines 109 to 112 in 28841e5

	static cl::opt<std::string> stdCpp(
	"std",
	cl::desc("Specify the C++ standard (c++20, c++23). The default is c++20."),
	cl::init("c++20"));

Can you point to which issue is being addressed by this PR?

[rajv79]

Q: Can you elaborate what is quake1 and quake2 in this context?

@khalatepradnya From my understanding as a first-time contributor working on this issue, quake1 and quake2 are the two supported Quake dialect modes in CUDA-Q, selected via the --std flag.
They represent different versions or interpretations of the Quake language, primarily to support backward compatibility alongside newer or evolving rules. The intent of running the tests under both dialects is to ensure that existing and newly added AST verification errors are consistently exercised across both modes, as requested by this issue, to improve verification coverage across dialects.

The command line argument std in cudaq-quake is for C++ standard.

cuda-quantum/tools/cudaq-quake/cudaq-quake.cpp

Lines 109 to 112 in 28841e5

	static cl::opt<std::string> stdCpp(
	"std",
	cl::desc("Specify the C++ standard (c++20, c++23). The default is c++20."),
	cl::init("c++20"));

Can you point to which issue is being addressed by this PR?

@khalatepradny This PR addresses the Good First Issue reported in NVIDIA/cuda-quantum Issue #2251.
It fixes the same class of problems described in that issue and adds additional test cases in a dedicated test folder to ensure the behavior is verified across both supported dialects.

[khalatepradnya]

Requesting review from @schweitzpgi

[rajv79]

Requesting review from @schweitzpgi

@khalatepradnya @schweitzpgi Thank you, waiting for your review.

[schweitzpgi]

I haven't looked at the changes, but there does seem to be a bit of misunderstanding from the way the issue was written right from the onset.

There is no such thing as quake1 and quake2. There are two dialects: quake and cc. "Both dialects" meant to refer to those two dialects.

What is desired are cudaq-opt based tests that try to test the limits of the ops, types, etc. defined in these dialects. So a completely hypothetical:

   %1 = cc.bogon %0 : (i8) -> !cc.struct<{}>

might be an input that triggers a failure because the bogon Op doesn't have any arguments or will only return an integer and not a struct type or doesn't return a empty struct. The overall agenda would be to audit the Ops in these two dialects, particularly any verify methods, and write tests to cover that the code in the verifiers (both manual and auto-generateed) is doing the correct thing and emitting the expected diagnostics.

[schweitzpgi]

Apologies for sending you down the wrong rabbit hole here. Would you like to try adding cudaq-opt tests to address the cited issue?

[rajv79]

Apologies for sending you down the wrong rabbit hole here. Would you like to try adding cudaq-opt tests to address the cited issue?

@schweitzpgi

Sure, I’d be happy to work on that. Could you please confirm whether the above changes will be merged if they are correct? That will help me align my work accordingly.

Also, for adding the cudaq-opt test, could you please share what exactly you are looking for? I’d like to make sure I’m proceeding in the right direction this time