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)
|
Closed in #1919 |
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: