Docs: Clarify lack of adjoint/MCM support in default.qubit

[KaranSinghDev]

Context:
While testing device capabilities using default.qubit (with a recent dev version installed via pip), I observed through the device.capabilities property and test execution that adjoint differentiation and native mid-circuit measurements are not supported. This information wasn't immediately obvious in the main docstring for the device.

Description of the Change:
This PR adds two small .. note:: blocks to the class docstring of pennylane.devices.DefaultQubit (in pennylane/devices/default_qubit.py).

• The first note clarifies that diff_method="adjoint" is not supported.
• The second note clarifies the limitations of mid-circuit measurement support on this device.

(Note: The PR template requests adding an entry to doc/releases/changelog-dev.md, but this file does not currently exist in the master branch. No changelog entry has been added as the correct location is unclear.)

Benefits:
Improves documentation clarity for default.qubit users, helping them quickly understand the device's limitations regarding adjoint differentiation and mid-circuit measurements without needing to run tests or dig deep into code/capabilities dictionaries. This prevents potential confusion.

Possible Drawbacks:
None anticipated for this documentation clarification.

Related GitHub Issues:
None.

[albi3ro]

Thanks for opening this PR @KaranSinghDev .

Mind sharing what workflows you were trying that were getting errors? It might even be worth opening a bug report issue.

[KaranSinghDev]

Hi @albi3ro , thanks for the review and your response!

No specific complex workflow errored out unexpectedly. This change came about during general testing where I specifically checked the capabilities of default.qubit.

After verifying via device.capabilities that Adjoint Differentiation and Mid-Circuit Measurements were reported as unsupported, I thought it would be helpful to add explicit notes about these limitations to the main docstring for better user clarity upfront.

It didn't seem like a bug in the features themselves, just an opportunity to improve the documentation based on the device's reported capabilities. Let me know if you need more info!

[albi3ro]

DefaultQubit relies on its own implementations for preprocess, rather than relying on a default implementation created from a capabilities spec, as that gives us greater control and flexibility over what is supported when.

It should be able to support adjoint and native mid circuit measurements, so if that's not the case, that is a bug we need to fix.

But I would agree that the docstring for DefaultQubit could use a major rewrite to make it more user facing, rather than what it is right now.

[KaranSinghDev]

Thanks for the clarification regarding DefaultQubit's custom preprocess implementation – that makes sense!

It's interesting that it should support Adjoint and native MCM. In the testing I ran (using the 0.42.0-dev18 version installed via pip install pennylane), the device.capabilities check returned False for both supports_adjoint_differentiation and supports_mid_measure after I corrected how the dictionary was accessed.

Given your confirmation that these should be supported, this discrepancy definitely sounds like something worth investigating further – potentially a bug or perhaps an issue specific to the development version.

I'm happy to open a new bug report issue detailing the test environment (Kaggle notebook, Python 3.11, PL 0.42.0-dev18), the test script used, and the output showing the capabilities check results.

Does that sound like the best way forward? If so, I agree it probably makes sense to close this documentation PR (#7365 ) for now, as the notes are based on the currently observed (but potentially incorrect) capability reporting.

I agree the docstring could use a rewrite eventually, and I'd be happy to help anyway with that once the Adjoint/MCM status is confirmed/fixed.

[Alex-Preciado]

Thanks so much for the detailed follow-up here @KaranSinghDev, and yes, opening a bug report with the test environment and output would be really helpful. We’ll be happy to take a closer look with that information.

And agreed on closing this PR for now given the uncertainty. Really appreciate your offer to revisit the docstring later. We can come back to that once we’ve clarified the device’s status around Adjoint and MCM. Thanks again!

[KaranSinghDev]

Sure, I have raised the issues and will close the request.