Remove unsupported PassManager for scheduling stage #10623
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In optimization level 3's preset pass manager there was handling for a PassManager object coming in via the `scheduling_method` argument. This is not a valid type for the scheduling method argument and would result in an error higher up in the call stack and also would not work for any other optimization level. This was a leftover from Qiskit#8648 which added the option for backends to set alternate defaults for the scheduling stage. An earlier iteration of that PR was using a PassManager returned by the backend instead of the plugin interface. The handling for the PassManager input was not removed when that PR was updated to use the plugin interface. This commit corrects the oversight and removes the stray condition that would never work.
|
One or more of the the following people are requested to review this:
|
Pull Request Test Coverage Report for Build 5858421279
💛 - Coveralls |
jakelishman
approved these changes
Aug 21, 2023
SamD-1998
pushed a commit
to SamD-1998/qiskit-terra
that referenced
this pull request
Sep 7, 2023
In optimization level 3's preset pass manager there was handling for a PassManager object coming in via the `scheduling_method` argument. This is not a valid type for the scheduling method argument and would result in an error higher up in the call stack and also would not work for any other optimization level. This was a leftover from Qiskit#8648 which added the option for backends to set alternate defaults for the scheduling stage. An earlier iteration of that PR was using a PassManager returned by the backend instead of the plugin interface. The handling for the PassManager input was not removed when that PR was updated to use the plugin interface. This commit corrects the oversight and removes the stray condition that would never work.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
In optimization level 3's preset pass manager there was handling for a PassManager object coming in via the
scheduling_methodargument. This is not a valid type for the scheduling method argument and would result in an error higher up in the call stack and also would not work for any other optimization level. This was a leftover from #8648 which added the option for backends to set alternate defaults for the scheduling stage. An earlier iteration of that PR was using a PassManager returned by the backend instead of the plugin interface. The handling for the PassManager input was not removed when that PR was updated to use the plugin interface. This commit corrects the oversight and removes the stray condition that would never work.Details and comments