Migrating Microsoft.Quantum.Core to the modern Stdlib causes strange errors around resolving primitive types
#1911
Assignees
Labels
Comments
|
@swernli is doing a small investigation |
|
Figured this one out, fix coming... |
github-merge-queue bot
pushed a commit
that referenced
this issue
Sep 17, 2024
This PR migrates the standard library into a Q# project structure. Previously, we provided the modern standard library API via re-export, while the "true" stdlib was defined in the old explicit-namespace style. Now, that is inverted: the stdlib's code is housed in a project with implicit namespaces, and the legacy (`Microsoft.Quantum.____`) API is provided via re-exports. Why do this? Well, for one, the standard library should look like a regular library and use the latest features we have. Secondarily, auto-imports and other language dev tools now refer to these items by their `Std.__` name, not their `Microsoft.Quantum.__` name. See the video below for an example of this in completions: https://github.com/user-attachments/assets/fa96e5b7-0cca-4a44-9224-7742d50f8370 Go-to def rendering the new paths: https://github.com/user-attachments/assets/5fea33ec-9478-4c16-9e78-b8f8b1420ed0 Note that `Unstable.*` has not been migrated to the modern API, as we want to explore stabilizing state preparation (#1910) Core is also not included, but for different reasons: #1911. Coming in a Follow Up PR™️ (`alex/1911` if you want to preview the work there)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
To reproduce this, check out my branch
alex/even-newer-stdliband runcargo testinlibrary/.For reasons unknown to me (yet), primitive types fail to resolve when the name of the core library is changed, even when the prelude and other hard-coded references to core are updated in the compiler.
The text was updated successfully, but these errors were encountered: