Restoring the num_def_ids function in the CStore API
#85889
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
|
r? @estebank (rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
bjorn3
reviewed
Jun 1, 2021
jyn514
added
the
T-compiler
jyn514
reviewed
Jun 1, 2021
Why does it do that? |
It was a architectural choice I made one year ago when I started to dev on it. I could change it on my side, requiring a diff that I estimate at ~1000 lines of code or more and one month of work (at least). The balance between this and the 6 lines of code in the Rust compiler made me decide that I should at least try this PR :) |
petrochenkov
reviewed
Jun 1, 2021
|
r=me after adding the comment (#85889 (comment)) and squashing commits. |
petrochenkov
added
S-waiting-on-author
jyn514
added
S-waiting-on-review
|
@bors r+ rollup |
petrochenkov
added
S-waiting-on-bors
|
📌 Commit 3844570 has been approved by |
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this pull request
Jun 3, 2021
Restoring the `num_def_ids` function in the CStore API ## The context I am the maintainer of https://github.com/hacspec/hacspec, an embedded Rust DSL aimed at cryptographic specifications. As it is normal for an embedded DSL, Hacspec's compiler relies on being plugged to the internal API of the Rust compiler, which is unstable and subject to changes. ## The problem The Hacspec compiler features its own typechecker, that performs an additional, more restrictive typechecking pass over the Rust code of a crate. To complete this typechecking, the Hacspec compiler needs to retrieve the signature of functions defined in non-local imported crates. Rather than retrieving these signatures on-demand, the Hacspec compiler pre-populates its typechecking context with all the Hacspec-compatible symbols defined in non-local crates first. This requires having a way to iterate over all the definitions in a non-local crate. I used to do this with `CrateMetadata::all_def_path_hashes_and_def_ids`, but this function was deleted in 908bf5a. Then, I fellback on `CStore::num_def_ids`, exploiting the fact that all the `DefIds` for a crate have the same `krate_num` and range from `0` to `num_def_ids(krate_num)`. But `num_def_ids` was deleted in b6120bf. I looked to the `Cstore::item_children_untracked` function to replicate the feature of traversing through all the `DefId` for a crate, using `CRATE_DEF_INDEX` as the root, but this does not work as recursive `Cstore::item_children_untracked` calls do not reach all the symbols I was able to reach using the two previous methods. ## Description of this PR This PR simply restores in the public API of `CStore` the `num_def_ids` function, giving the size of the definition table for a given crate.
|
Failed in rollup: #85949 (comment) |
bors
added
S-waiting-on-author
…mber of exported symbols for each crate Restored underlying num_def_ids_method Update compiler/rustc_metadata/src/rmeta/decoder/cstore_impl.rs Changed name to fit with naming convention Co-authored-by: bjorn3 <bjorn3@users.noreply.github.com> Update compiler/rustc_metadata/src/rmeta/decoder/cstore_impl.rs Replace regular doc with Rustdoc comment Co-authored-by: Joshua Nelson <jyn514@gmail.com> Clarifies third-party use of num_def_ids_untracked
|
Sorry for the missing hyperlink markup. BTW as this is my first Rust compiler PR I'm REALLY impressed by the bors tooling, rollup system, error message finding, automatic PR labeling system, etc. Thanks so much to everyone involved for creating and running such a great org. |
|
@bors r=petrochenkov |
|
📌 Commit d4ea9fa has been approved by |
bors
added
S-waiting-on-bors
|
@bors rollup |
JohnTitor
added a commit
to JohnTitor/rust
that referenced
this pull request
Jun 3, 2021
Restoring the `num_def_ids` function in the CStore API ## The context I am the maintainer of https://github.com/hacspec/hacspec, an embedded Rust DSL aimed at cryptographic specifications. As it is normal for an embedded DSL, Hacspec's compiler relies on being plugged to the internal API of the Rust compiler, which is unstable and subject to changes. ## The problem The Hacspec compiler features its own typechecker, that performs an additional, more restrictive typechecking pass over the Rust code of a crate. To complete this typechecking, the Hacspec compiler needs to retrieve the signature of functions defined in non-local imported crates. Rather than retrieving these signatures on-demand, the Hacspec compiler pre-populates its typechecking context with all the Hacspec-compatible symbols defined in non-local crates first. This requires having a way to iterate over all the definitions in a non-local crate. I used to do this with `CrateMetadata::all_def_path_hashes_and_def_ids`, but this function was deleted in 908bf5a. Then, I fellback on `CStore::num_def_ids`, exploiting the fact that all the `DefIds` for a crate have the same `krate_num` and range from `0` to `num_def_ids(krate_num)`. But `num_def_ids` was deleted in b6120bf. I looked to the `Cstore::item_children_untracked` function to replicate the feature of traversing through all the `DefId` for a crate, using `CRATE_DEF_INDEX` as the root, but this does not work as recursive `Cstore::item_children_untracked` calls do not reach all the symbols I was able to reach using the two previous methods. ## Description of this PR This PR simply restores in the public API of `CStore` the `num_def_ids` function, giving the size of the definition table for a given crate.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jun 4, 2021
Rollup of 8 pull requests Successful merges: - rust-lang#85717 (Document `From` impls for cow.rs) - rust-lang#85850 (Remove unused feature gates) - rust-lang#85888 (Fix typo in internal documentation for `TrustedRandomAccess`) - rust-lang#85889 (Restoring the `num_def_ids` function in the CStore API ) - rust-lang#85899 (jsondocck small cleanup) - rust-lang#85937 (Fix bad suggestions for code from proc_macro) - rust-lang#85963 (Show `::{{constructor}}` in std::any::type_name().) - rust-lang#85977 (Fix linkcheck script from getting out of sync.) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
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.
The context
I am the maintainer of https://github.com/hacspec/hacspec, an embedded Rust DSL aimed at cryptographic specifications. As it is normal for an embedded DSL, Hacspec's compiler relies on being plugged to the internal API of the Rust compiler, which is unstable and subject to changes.
The problem
The Hacspec compiler features its own typechecker, that performs an additional, more restrictive typechecking pass over the Rust code of a crate. To complete this typechecking, the Hacspec compiler needs to retrieve the signature of functions defined in non-local imported crates. Rather than retrieving these signatures on-demand, the Hacspec compiler pre-populates its typechecking context with all the Hacspec-compatible symbols defined in non-local crates first. This requires having a way to iterate over all the definitions in a non-local crate.
I used to do this with
CrateMetadata::all_def_path_hashes_and_def_ids, but this function was deleted in 908bf5a. Then, I fellback onCStore::num_def_ids, exploiting the fact that all theDefIdsfor a crate have the samekrate_numand range from0tonum_def_ids(krate_num). Butnum_def_idswas deleted in b6120bf.I looked to the
Cstore::item_children_untrackedfunction to replicate the feature of traversing through all theDefIdfor a crate, usingCRATE_DEF_INDEXas the root, but this does not work as recursiveCstore::item_children_untrackedcalls do not reach all the symbols I was able to reach using the two previous methods.Description of this PR
This PR simply restores in the public API of
CStorethenum_def_idsfunction, giving the size of the definition table for a given crate.