Load crates.io dependencies of the standard library #7637
Labels
C-Architecture
Big architectural things which we need to figure up-front (or suggestions for rewrites :0) )
S-unactionable
Issue requires feedback, design decisions or is blocked on other work
Comments
jonas-schievink
added
the
C-Architecture
Why does this require mutating rustup directories? Why doesn't cargo metadata --locked work? |
|
Because the lockfile is in |
|
Would it help if rust-src shipped with a symlink from Cargo.lock to library/std/Cargo.lock? That would be a lot easier than separating the standard library into its own workspace. |
flodiebold
added
the
S-unactionable
|
The lockfile is currently shipped as part of the |
This was referenced Jun 20, 2021
|
@jonas-schievink What's the current status of this issue? Setting |
|
That only works for rustc-src, not rust-src as most people will have. |
DorianListens
added a commit
to DorianListens/rust-analyzer
that referenced
this issue
Jun 16, 2022
This change attempts to resolve issue rust-lang#7637: Extract into Function does not create a generic function with constraints when extracting generic code. In `FunctionBody::analyze_container`, when the ancestor matches `ast::Fn`, we can perserve both the `generic_param_list` and the `where_clause`. These can then be included in the newly extracted function output via `format_function`. From what I can tell, the only other ancestor type that could potentially have a generic param list would be `ast::ClosureExpr`. In this case, we perserve the `generic_param_list`, but no where clause is ever present. In this inital implementation, all the generic params and where clauses from the parent function will be copied to the newly extracted function. An obvious improvement would be to filter this output in some way to only include generic parameters that are actually used in the function body. fixes rust-lang#7636
DorianListens
added a commit
to DorianListens/rust-analyzer
that referenced
this issue
Jun 16, 2022
This change attempts to resolve issue rust-lang#7637: Extract into Function does not create a generic function with constraints when extracting generic code. In `FunctionBody::analyze_container`, when the ancestor matches `ast::Fn`, we can perserve both the `generic_param_list` and the `where_clause`. These can then be included in the newly extracted function output via `format_function`. From what I can tell, the only other ancestor type that could potentially have a generic param list would be `ast::ClosureExpr`. In this case, we perserve the `generic_param_list`, but no where clause is ever present. In this inital implementation, all the generic params and where clauses from the parent function will be copied to the newly extracted function. An obvious improvement would be to filter this output in some way to only include generic parameters that are actually used in the function body. fixes rust-lang#7636
DorianListens
added a commit
to DorianListens/rust-analyzer
that referenced
this issue
Jun 16, 2022
This change attempts to resolve issue rust-lang#7637: Extract into Function does not create a generic function with constraints when extracting generic code. In `FunctionBody::analyze_container`, when the ancestor matches `ast::Fn`, we can perserve both the `generic_param_list` and the `where_clause`. These can then be included in the newly extracted function output via `format_function`. From what I can tell, the only other ancestor type that could potentially have a generic param list would be `ast::ClosureExpr`. In this case, we perserve the `generic_param_list`, but no where clause is ever present. In this inital implementation, all the generic params and where clauses from the parent function will be copied to the newly extracted function. An obvious improvement would be to filter this output in some way to only include generic parameters that are actually used in the function body. fixes rust-lang#7636
DorianListens
added a commit
to DorianListens/rust-analyzer
that referenced
this issue
Jun 16, 2022
This change attempts to resolve issue rust-lang#7637: Extract into Function does not create a generic function with constraints when extracting generic code. In `FunctionBody::analyze_container`, when the ancestor matches `ast::Fn`, we can perserve both the `generic_param_list` and the `where_clause`. These can then be included in the newly extracted function output via `format_function`. From what I can tell, the only other ancestor type that could potentially have a generic param list would be `ast::ClosureExpr`. In this case, we perserve the `generic_param_list`, but no where clause is ever present. In this inital implementation, all the generic params and where clauses from the parent function will be copied to the newly extracted function. An obvious improvement would be to filter this output in some way to only include generic parameters that are actually used in the function body. I'm not experienced enough with this codebase to know how challenging doing this kind of filtration would be. I don't believe this implementation will work in contexts where the generic parameters and where clauses are defined multiple layers above the function being extracted, such as with nested function declarations. Resolving this seems like another obvious improvement, but one that will potentially require more significant changes to the strucutre of `analyze_container` that I wasn't comfortable trying to make as a first change.
DorianListens
added a commit
to DorianListens/rust-analyzer
that referenced
this issue
Jun 16, 2022
This change attempts to resolve issue rust-lang#7637: Extract into Function does not create a generic function with constraints when extracting generic code. In `FunctionBody::analyze_container`, when the ancestor matches `ast::Fn`, we can perserve both the `generic_param_list` and the `where_clause`. These can then be included in the newly extracted function output via `format_function`. From what I can tell, the only other ancestor type that could potentially have a generic param list would be `ast::ClosureExpr`. In this case, we perserve the `generic_param_list`, but no where clause is ever present. In this inital implementation, all the generic params and where clauses from the parent function will be copied to the newly extracted function. An obvious improvement would be to filter this output in some way to only include generic parameters that are actually used in the function body. I'm not experienced enough with this codebase to know how challenging doing this kind of filtration would be. I don't believe this implementation will work in contexts where the generic parameters and where clauses are defined multiple layers above the function being extracted, such as with nested function declarations. Resolving this seems like another obvious improvement, but one that will potentially require more significant changes to the structure of `analyze_container` that I wasn't comfortable trying to make as a first change.
DorianListens
added a commit
to DorianListens/rust-analyzer
that referenced
this issue
Jun 16, 2022
This change attempts to resolve issue rust-lang#7637: Extract into Function does not create a generic function with constraints when extracting generic code. In `FunctionBody::analyze_container`, when the ancestor matches `ast::Fn`, we can perserve both the `generic_param_list` and the `where_clause`. These can then be included in the newly extracted function output via `format_function`. From what I can tell, the only other ancestor type that could potentially have a generic param list would be `ast::ClosureExpr`. In this case, we perserve the `generic_param_list`, but no where clause is ever present. In this inital implementation, all the generic params and where clauses from the parent function will be copied to the newly extracted function. An obvious improvement would be to filter this output in some way to only include generic parameters that are actually used in the function body. I'm not experienced enough with this codebase to know how challenging doing this kind of filtration would be. I don't believe this implementation will work in contexts where the generic parameters and where clauses are defined multiple layers above the function being extracted, such as with nested function declarations. Resolving this seems like another obvious improvement, but one that will potentially require more significant changes to the structure of `analyze_container` that I wasn't comfortable trying to make as a first change.
DorianListens
added a commit
to DorianListens/rust-analyzer
that referenced
this issue
Jun 23, 2022
This change attempts to resolve issue rust-lang#7637: Extract into Function does not create a generic function with constraints when extracting generic code. In `FunctionBody::analyze_container`, when the ancestor matches `ast::Fn`, we can perserve both the `generic_param_list` and the `where_clause`. These can then be included in the newly extracted function output via `format_function`. From what I can tell, the only other ancestor type that could potentially have a generic param list would be `ast::ClosureExpr`. In this case, we perserve the `generic_param_list`, but no where clause is ever present. In this inital implementation, all the generic params and where clauses from the parent function will be copied to the newly extracted function. An obvious improvement would be to filter this output in some way to only include generic parameters that are actually used in the function body. I'm not experienced enough with this codebase to know how challenging doing this kind of filtration would be. I don't believe this implementation will work in contexts where the generic parameters and where clauses are defined multiple layers above the function being extracted, such as with nested function declarations. Resolving this seems like another obvious improvement, but one that will potentially require more significant changes to the structure of `analyze_container` that I wasn't comfortable trying to make as a first change.
DorianListens
added a commit
to DorianListens/rust-analyzer
that referenced
this issue
Jun 30, 2022
This change attempts to resolve issue rust-lang#7637: Extract into Function does not create a generic function with constraints when extracting generic code. In `FunctionBody::analyze_container`, when the ancestor matches `ast::Fn`, we can perserve both the `generic_param_list` and the `where_clause`. These can then be included in the newly extracted function output via `format_function`. From what I can tell, the only other ancestor type that could potentially have a generic param list would be `ast::ClosureExpr`. In this case, we perserve the `generic_param_list`, but no where clause is ever present. In this inital implementation, all the generic params and where clauses from the parent function will be copied to the newly extracted function. An obvious improvement would be to filter this output in some way to only include generic parameters that are actually used in the function body. I'm not experienced enough with this codebase to know how challenging doing this kind of filtration would be. I don't believe this implementation will work in contexts where the generic parameters and where clauses are defined multiple layers above the function being extracted, such as with nested function declarations. Resolving this seems like another obvious improvement, but one that will potentially require more significant changes to the structure of `analyze_container` that I wasn't comfortable trying to make as a first change.
DorianListens
added a commit
to DorianListens/rust-analyzer
that referenced
this issue
Jun 30, 2022
This change attempts to resolve issue rust-lang#7637: Extract into Function does not create a generic function with constraints when extracting generic code. In `FunctionBody::analyze_container`, when the ancestor matches `ast::Fn`, we can perserve both the `generic_param_list` and the `where_clause`. These can then be included in the newly extracted function output via `format_function`. From what I can tell, the only other ancestor type that could potentially have a generic param list would be `ast::ClosureExpr`. In this case, we perserve the `generic_param_list`, but no where clause is ever present. In this initial implementation, only generic type parameters (and their associated where clauses) which are referenced in the extracted function body are copied to the new function signature. Const and Lifetime params are ignored for now. I don't believe this implementation will work in contexts where the generic parameters and where clauses are defined multiple layers above the function being extracted, such as with nested function declarations. Resolving this seems like another obvious improvement, but one that will potentially require more significant changes to the structure of `analyze_container` that I wasn't comfortable trying to make as a first change.
DorianListens
added a commit
to DorianListens/rust-analyzer
that referenced
this issue
Jul 2, 2022
This change attempts to resolve issue rust-lang#7637: Extract into Function does not create a generic function with constraints when extracting generic code. In `FunctionBody::analyze_container`, when the ancestor matches `ast::Fn`, we can perserve both the `generic_param_list` and the `where_clause`. These can then be included in the newly extracted function output via `format_function`. From what I can tell, the only other ancestor type that could potentially have a generic param list would be `ast::ClosureExpr`. In this case, we perserve the `generic_param_list`, but no where clause is ever present. In this initial implementation, only generic type parameters (and their associated where clauses) which are referenced in the extracted function body are copied to the new function signature. Const and Lifetime params are ignored for now. I don't believe this implementation will work in contexts where the generic parameters and where clauses are defined multiple layers above the function being extracted, such as with nested function declarations. Resolving this seems like another obvious improvement, but one that will potentially require more significant changes to the structure of `analyze_container` that I wasn't comfortable trying to make as a first change.
DorianListens
added a commit
to DorianListens/rust-analyzer
that referenced
this issue
Jul 6, 2022
This change attempts to resolve issue rust-lang#7637: Extract into Function does not create a generic function with constraints when extracting generic code. In `FunctionBody::analyze_container`, when the ancestor matches `ast::Fn`, we can perserve both the `generic_param_list` and the `where_clause`. These can then be included in the newly extracted function output via `format_function`. From what I can tell, the only other ancestor type that could potentially have a generic param list would be `ast::ClosureExpr`. In this case, we perserve the `generic_param_list`, but no where clause is ever present. In this initial implementation, only generic type parameters (and their associated where clauses) which are referenced in the extracted function body are copied to the new function signature. Const and Lifetime params are ignored for now. I don't believe this implementation will work in contexts where the generic parameters and where clauses are defined multiple layers above the function being extracted, such as with nested function declarations. Resolving this seems like another obvious improvement, but one that will potentially require more significant changes to the structure of `analyze_container` that I wasn't comfortable trying to make as a first change.
DorianListens
added a commit
to DorianListens/rust-analyzer
that referenced
this issue
Jul 8, 2022
This change attempts to resolve issue rust-lang#7637: Extract into Function does not create a generic function with constraints when extracting generic code. In `FunctionBody::analyze_container`, when the ancestor matches `ast::Fn`, we can perserve both the `generic_param_list` and the `where_clause`. These can then be included in the newly extracted function output via `format_function`. From what I can tell, the only other ancestor type that could potentially have a generic param list would be `ast::ClosureExpr`. In this case, we perserve the `generic_param_list`, but no where clause is ever present. In this initial implementation, only generic type parameters (and their associated where clauses) which are referenced in the extracted function body are copied to the new function signature. Const and Lifetime params are ignored for now. I don't believe this implementation will work in contexts where the generic parameters and where clauses are defined multiple layers above the function being extracted, such as with nested function declarations. Resolving this seems like another obvious improvement, but one that will potentially require more significant changes to the structure of `analyze_container` that I wasn't comfortable trying to make as a first change.
DorianListens
added a commit
to DorianListens/rust-analyzer
that referenced
this issue
Jul 8, 2022
This change attempts to resolve issue rust-lang#7637: Extract into Function does not create a generic function with constraints when extracting generic code. In `FunctionBody::analyze_container`, when the ancestor matches `ast::Fn`, we can perserve both the `generic_param_list` and the `where_clause`. These can then be included in the newly extracted function output via `format_function`. From what I can tell, the only other ancestor type that could potentially have a generic param list would be `ast::ClosureExpr`. In this case, we perserve the `generic_param_list`, but no where clause is ever present. In this initial implementation, only generic type parameters (and their associated where clauses) which are referenced in the extracted function body are copied to the new function signature. Const and Lifetime params are ignored for now. I don't believe this implementation will work in contexts where the generic parameters and where clauses are defined multiple layers above the function being extracted, such as with nested function declarations. Resolving this seems like another obvious improvement, but one that will potentially require more significant changes to the structure of `analyze_container` that I wasn't comfortable trying to make as a first change.
DorianListens
added a commit
to DorianListens/rust-analyzer
that referenced
this issue
Jul 8, 2022
This change attempts to resolve issue rust-lang#7637: Extract into Function does not create a generic function with constraints when extracting generic code. In `FunctionBody::analyze_container`, we now traverse the `ancestors` in search of `AnyHasGenericParams`, and attach any `GenericParamList`s and `WhereClause`s we find to the `ContainerInfo`. Later, in `format_function`, we collect all the `GenericParam`s and `WherePred`s from the container, and filter them to keep only types matching `TypeParam`s used within the newly extracted function body or param list. We can then include the new `GenericParamList` and `WhereClause` in the new function definition. This change only impacts `TypeParam`s. `LifetimeParam`s and `ConstParam`s are out of scope for this change.
DorianListens
added a commit
to DorianListens/rust-analyzer
that referenced
this issue
Jul 13, 2022
This change attempts to resolve issue rust-lang#7637: Extract into Function does not create a generic function with constraints when extracting generic code. In `FunctionBody::analyze_container`, we now traverse the `ancestors` in search of `AnyHasGenericParams`, and attach any `GenericParamList`s and `WhereClause`s we find to the `ContainerInfo`. Later, in `format_function`, we collect all the `GenericParam`s and `WherePred`s from the container, and filter them to keep only types matching `TypeParam`s used within the newly extracted function body or param list. We can then include the new `GenericParamList` and `WhereClause` in the new function definition. This change only impacts `TypeParam`s. `LifetimeParam`s and `ConstParam`s are out of scope for this change.
Closed
|
Opened a zulip stream for discussion: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/rust-lang.2Frust.2Flibrary.20workspace |
|
A previous attempt at this (with corresponding discussion) can be found here rust-lang/rust#76533 |
Closed
How bad it is? I can guess that mutating rustup-installed directories is very bad, and temporary directory per each project can consume disk space and make start time worse, but what is the problem with a global directory which contains one std source and it dependencies for each toolchain? |
|
Mutating the rustup install directory is a no-go. Dropping things in the target dir would be okay, but I looked into that at some point and the way cargo works I couldn't make it work.
I'm not sure I understand what you mean with this |
I copied my [workspace]
members = [
"library/alloc",
"library/core",
"library/panic_unwind",
"library/proc_macro",
# "library/rtstartup",
"library/rustc-std-workspace-core",
"library/std",
"library/test",
# "library/backtrace",
"library/panic_abort",
# "library/portable-simd",
"library/profiler_builtins",
"library/rustc-std-workspace-alloc",
"library/rustc-std-workspace-std",
# "library/stdarch",
"library/unwind",
](backtrace and portable-simd are workspace themselves, and rtstartup and stdarch didn't have a Then
It was just a suggestion to improve performance, by sharing those temp directories. We can go with per project local temp directory at first if it is acceptable. |
|
Ah, I only tried to synthesize the Cargo.toml but keeping the source in the sysroot which unfortunately does not work because cargo expects certain filesystem hierarchies. I am not sure I like copying around the entire sysroot source on every project load (nor synthesizing a custom sysroot with proper cargo setups globally somewhere as this will be tricky to handle properly) |
|
Maybe we could make some symlinks to the sources instead of making a copy? |
|
Using symlinks instead of copy also work for me on linux. For the record, I created a symlink to the |
bors
added a commit
that referenced
this issue
Apr 20, 2023
Detect sysroot dependencies using symlink copy cc #7637 It is currently in a proof of concept stage, and it doesn't generates a copy. You need to provide your own sysroot copy in `/tmp/ra-sysroot-hack` in a way that `/tmp/ra-sysroot-hack/library/std/lib.rs` exists and `/tmp/ra-sysroot-hack/Cargo.toml` is [the one from this comment](#7637 (comment)). I will add the symlink code if we decide that this approach is not a dead end. It seems to somehow work on my system. Go to definition into std dependencies works, type checking can look through fields if I make them public and `cfg_if` appears to work (I tested it by hovering both sides and seeing that the correct one is enabled). Though finding layout of `HashMap` didn't work. Please try it and let me know if I should go forward in this direction or not.
|
Turns out rust-lang/rust#108865 added a sysroot crate which brings us closer to supporting this as we can run cargo metadata against that file (meaning we only get the std library dependencies). We still have the problem of no lock file being present though which means we can't run metadata as there is no |
bors
added a commit
that referenced
this issue
Jan 15, 2024
internal: Add unstable config for loading the sysroot sources via `cargo metadata` cc #7637 This takes the approach of having `cargo metadata` generate a lock file that we then delete again, hence why this is behind a flag. If people need this for their workflow they can just enable it, if not, they are probably better off keeping it disabled. [example](https://dreampuf.github.io/GraphvizOnline/#digraph%20rust_analyzer_crate_graph%20%7B%0A%20%20%20%20_0%5Blabel%3D%22core%22%5D%5Bshape%3D%22box%22%5D%3B%0A%20%20%20%20_17%5Blabel%3D%22ra_playground%22%5D%5Bshape%3D%22box%22%5D%3B%0A%20%20%20%20_14%5Blabel%3D%22getopts%22%5D%5Bshape%3D%22box%22%5D%3B%0A%20%20%20%20_11%5Blabel%3D%22std_detect%22%5D%5Bshape%3D%22box%22%5D%3B%0A%20%20%20%20_8%5Blabel%3D%22unwind%22%5D%5Bshape%3D%22box%22%5D%3B%0A%20%20%20%20_5%5Blabel%3D%22hashbrown%22%5D%5Bshape%3D%22box%22%5D%3B%0A%20%20%20%20_2%5Blabel%3D%22alloc%22%5D%5Bshape%3D%22box%22%5D%3B%0A%20%20%20%20_16%5Blabel%3D%22test%22%5D%5Bshape%3D%22box%22%5D%3B%0A%20%20%20%20_13%5Blabel%3D%22unicode_width%22%5D%5Bshape%3D%22box%22%5D%3B%0A%20%20%20%20_10%5Blabel%3D%22rustc_demangle%22%5D%5Bshape%3D%22box%22%5D%3B%0A%20%20%20%20_7%5Blabel%3D%22panic_abort%22%5D%5Bshape%3D%22box%22%5D%3B%0A%20%20%20%20_4%5Blabel%3D%22cfg_if%22%5D%5Bshape%3D%22box%22%5D%3B%0A%20%20%20%20_1%5Blabel%3D%22compiler_builtins%22%5D%5Bshape%3D%22box%22%5D%3B%0A%20%20%20%20_18%5Blabel%3D%22build_script_build%22%5D%5Bshape%3D%22box%22%5D%3B%0A%20%20%20%20_15%5Blabel%3D%22proc_macro%22%5D%5Bshape%3D%22box%22%5D%3B%0A%20%20%20%20_12%5Blabel%3D%22std%22%5D%5Bshape%3D%22box%22%5D%3B%0A%20%20%20%20_9%5Blabel%3D%22panic_unwind%22%5D%5Bshape%3D%22box%22%5D%3B%0A%20%20%20%20_6%5Blabel%3D%22libc%22%5D%5Bshape%3D%22box%22%5D%3B%0A%20%20%20%20_3%5Blabel%3D%22allocator_api2%22%5D%5Bshape%3D%22box%22%5D%3B%0A%20%20%20%20_17%20-%3E%20_0%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_17%20-%3E%20_2%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_17%20-%3E%20_12%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_17%20-%3E%20_15%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_17%20-%3E%20_16%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_14%20-%3E%20_0%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_14%20-%3E%20_12%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_14%20-%3E%20_13%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_11%20-%3E%20_0%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_11%20-%3E%20_1%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_11%20-%3E%20_2%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_11%20-%3E%20_4%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_11%20-%3E%20_6%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_8%20-%3E%20_0%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_8%20-%3E%20_1%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_8%20-%3E%20_4%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_8%20-%3E%20_6%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_5%20-%3E%20_0%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_5%20-%3E%20_1%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_5%20-%3E%20_2%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_5%20-%3E%20_3%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_2%20-%3E%20_0%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_2%20-%3E%20_1%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_16%20-%3E%20_0%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_16%20-%3E%20_7%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_16%20-%3E%20_9%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_16%20-%3E%20_12%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_16%20-%3E%20_14%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_13%20-%3E%20_0%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_13%20-%3E%20_1%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_13%20-%3E%20_12%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_10%20-%3E%20_0%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_10%20-%3E%20_1%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_7%20-%3E%20_0%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_7%20-%3E%20_1%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_7%20-%3E%20_2%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_7%20-%3E%20_4%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_7%20-%3E%20_6%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_1%20-%3E%20_0%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_18%20-%3E%20_0%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_18%20-%3E%20_2%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_18%20-%3E%20_12%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_18%20-%3E%20_15%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_18%20-%3E%20_16%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_15%20-%3E%20_0%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_15%20-%3E%20_12%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_12%20-%3E%20_0%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_12%20-%3E%20_1%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_12%20-%3E%20_2%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_12%20-%3E%20_4%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_12%20-%3E%20_4%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_12%20-%3E%20_5%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_12%20-%3E%20_6%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_12%20-%3E%20_7%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_12%20-%3E%20_8%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_12%20-%3E%20_9%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_12%20-%3E%20_10%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_12%20-%3E%20_11%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_9%20-%3E%20_0%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_9%20-%3E%20_1%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_9%20-%3E%20_2%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_9%20-%3E%20_4%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_9%20-%3E%20_6%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_9%20-%3E%20_8%5Blabel%3D%22%22%5D%3B%0A%20%20%20%20_6%20-%3E%20_0%5Blabel%3D%22%22%5D%3B%0A%7D%0A)  hashbrown resolves as a dependency now
|
Forgive my incompetence and ignorance on this, I'm guessing that the source in I'm thinking maybe it would also need to do something to ensure the cargo-managed sources were pulled into Then the file mapping that @HKalbasi mentioned above plus the Cargo.lock file could be applied, and |
|
@j-h-a if that lockfile existed, it would already be installed in the sysroot, so |
bors
added a commit
that referenced
this issue
Feb 19, 2024
Setup infra for handling auto trait bounds disabled due to perf problems This patch updates some of the partially-implemented functions of `ChalkContext as RustIrDatabase`, namely `adt_datum()` and `impl_provided_for()`. With those, we can now correctly work with auto trait bounds and distinguish methods based on them. Resolves #7856 (the second code; the first one is resolved by #13074) **IMPORTANT**: I don't think we want to merge this until #7637 is resolved. Currently this patch introduces A LOT of unknown types and type mismtaches as shown below. This is because we cannot resolve items like `hashbrown::HashMap` in `std` modules, leading to auto trait bounds on them and their dependents unprovable. |crate (from `rustc-perf@c52ee6` except for r-a)|e3dc5a588f07d6f1d3a0f33051d4af26190abe9e|HEAD of this branch| |---|---|---| |rust-analyzer @ e3dc5a5 |exprs: 417528, ??ty: 907 (0%), ?ty: 114 (0%), !ty: 1|exprs: 417528, ??ty: 1704 (0%), ?ty: 403 (0%), !ty: 20| |ripgrep|exprs: 62120, ??ty: 2 (0%), ?ty: 0 (0%), !ty: 0|exprs: 62120, ??ty: 132 (0%), ?ty: 58 (0%), !ty: 11| |webrender/webrender|exprs: 94355, ??ty: 49 (0%), ?ty: 16 (0%), !ty: 2|exprs: 94355, ??ty: 429 (0%), ?ty: 130 (0%), !ty: 7| |diesel|exprs: 132591, ??ty: 401 (0%), ?ty: 5129 (3%), !ty: 31|exprs: 132591, ??ty: 401 (0%), ?ty: 5129 (3%), !ty: 31|
bors
added a commit
that referenced
this issue
Feb 19, 2024
Setup infra for handling auto trait bounds disabled due to perf problems This patch updates some of the partially-implemented functions of `ChalkContext as RustIrDatabase`, namely `adt_datum()` and `impl_provided_for()`. With those, we can now correctly work with auto trait bounds and distinguish methods based on them. Resolves #7856 (the second code; the first one is resolved by #13074) **IMPORTANT**: I don't think we want to merge this until #7637 is resolved. Currently this patch introduces A LOT of unknown types and type mismtaches as shown below. This is because we cannot resolve items like `hashbrown::HashMap` in `std` modules, leading to auto trait bounds on them and their dependents unprovable. |crate (from `rustc-perf@c52ee6` except for r-a)|e3dc5a588f07d6f1d3a0f33051d4af26190abe9e|HEAD of this branch| |---|---|---| |rust-analyzer @ e3dc5a5 |exprs: 417528, ??ty: 907 (0%), ?ty: 114 (0%), !ty: 1|exprs: 417528, ??ty: 1704 (0%), ?ty: 403 (0%), !ty: 20| |ripgrep|exprs: 62120, ??ty: 2 (0%), ?ty: 0 (0%), !ty: 0|exprs: 62120, ??ty: 132 (0%), ?ty: 58 (0%), !ty: 11| |webrender/webrender|exprs: 94355, ??ty: 49 (0%), ?ty: 16 (0%), !ty: 2|exprs: 94355, ??ty: 429 (0%), ?ty: 130 (0%), !ty: 7| |diesel|exprs: 132591, ??ty: 401 (0%), ?ty: 5129 (3%), !ty: 31|exprs: 132591, ??ty: 401 (0%), ?ty: 5129 (3%), !ty: 31|
github-project-automation
bot
moved this to Done
in Issues that completely disrupt the mir interpreter in running unit tests
lnicola
pushed a commit
to lnicola/rust
that referenced
this issue
Aug 13, 2024
feat: Load sysroot library via cargo metadata See rust-lang#128534, fixes rust-lang/rust-analyzer#7637 Requires a toolchain from 176e545 2024-08-04 or later to work.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The standard library may depend on crates from crates.io, and some of them can be required to properly analyze libstd, like
cfg_if, which caused #6038 in the past. We currently use a hard-coded dependency graph for the sysroot, but have no mechanism to detect or obtain the sources of crates.io dependencies.We should figure out a way to properly solve this. There are a few options:
rust-srccomponent could vendor the sources of crates.io dependencies (this seems insufficient though, we might still need to address one of the points below).cargo metadata, but this requires creating a temporary directory or mutating rustup-installed directories, which is a bad idea.Cargo.lock. Then we could runcargo metadata --lockedwithout requiring any disk operations besides index and crate downloads.The text was updated successfully, but these errors were encountered: