-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't distribute stage1 artifacts #14662
Comments
cc #14650 |
This will also cut down our distribution size by 60MB |
The FHS says:
Also observed by gcc, clang, ghc, mono, ocaml, and probably everyone else. Another way would be to rename the base libraries to |
cc @brson, maybe a good thing to tackle when dealing with the rust/cargo combined installer as well. |
cc #16029, this would fix that issue as well. |
Cc me |
cc #17289, also to be fixed by this. |
@alexcrichton Putting them in FWIW, I expect this to be solved as part of #11145, but restructuring the bootstrap seems pretty far out of scope at the moment. @alexcrichton are you thinking that we would sort of reorganize the artifacts on installation, but not for the bootstrap? |
Yeah I do think that #11145 would solve this if we tackled it. I suppose my worry now about I suppose we could reorganize for installation but not for bootstrap, but I do agree that it would be a little confusing. If we were to do this near-term, I would propose something like:
This would allow us to deduplicate our distribution strategy (only distributing one set of artifacts) and would be roughly equivalent to what the bootstrap process looks like today, just not exactly so. |
Traige: as far as I know, this is still an issue today. |
cc #16029 |
We've changed enough about our distribution that I don't believe this is relevant any more, so closing. |
…atin_instead_of_docs_dot_rs, r=Ddystopia Provide links to locally built documentation for `experimental/externalDocs` This pull request addresses issue rust-lang#12867, which requested the ability to provide links to locally built documentation when using the "Open docs for symbol" feature. Previously, rust-analyzer always used docs.rs for this purpose. With these changes, the feature will provide both web (docs.rs) and local documentation links without verifying their existence. Changes in this PR: - Added support for local documentation links alongside web documentation links. - Added `target_dir` path argument for external_docs and other related methods. - Added `sysroot` argument for external_docs. - Added `target_directory` path to `CargoWorkspace`. API Changes: - Added an experimental client capability `{ "localDocs": boolean }`. If this capability is set, the `Open External Documentation` request returned from the server will include both web and local documentation links in the `ExternalDocsResponse` object. Here's the `ExternalDocsResponse` interface: ```typescript interface ExternalDocsResponse { web?: string; local?: string; } ``` By providing links to both web-based and locally built documentation, this update improves the developer experience for those using different versions of crates, git dependencies, or local crates not available on docs.rs. Rust-analyzer will now provide both web (docs.rs) and local documentation links, leaving it to the client to open the desired link. Please note that this update does not perform any checks to ensure the validity of the provided links.
…tion_vscode, r=Veykril feat: vscode: Support opening local documentation if available This PR implements the VS code support for opening local documentation (server side support was already implemented in rust-lang#14662). [local_docs.webm](https://github.com/rust-lang/rust-analyzer/assets/9659253/715b84dd-4f14-4ba0-a904-749b847eb3d5) Displaying local instead of web docs can have many benefits: - the web version may have different features enabled than locally selected - the standard library may be a different version than is available online - the user may not be online and therefore cannot access the web documentation - the documentation may not be available online at all, for example because it is for a new feature in a library the user is currently developing If the documentation is not available locally, the extension still falls back to the web version. Closes rust-lang#12867. ----- If my implementation isn't really idiomatic TypeScript: Sorry, I'm not much of a TypeScript developer. I am open to feedback, however.
For what I mean by "stage1 artifact", see this comment. The gist of it is that we don't need to distribute things built by the stage1 compiler, only things built by the stage2 compiler.
The tricky part will be figuring out where the host stage2 artifacts go. We could place them in
$prefix/lib
, but there's a danger of pollution. We could also only place them in$prefix/lib/rustlib/$host/lib
, but then there's a danger of therustc
executable not being able to load these libraries seamlessly via rpath.Solving this should deal with #13421, #11195, and #13733
The text was updated successfully, but these errors were encountered: