Skip to content

Document std::libc::c_void. - #7690

Merged
bors merged 1 commit into
rust-lang:masterfrom
kevinmehall:document-c_void
Jul 11, 2013
Merged

Document std::libc::c_void.#7690
bors merged 1 commit into
rust-lang:masterfrom
kevinmehall:document-c_void

Conversation

@kevinmehall

Copy link
Copy Markdown
Contributor

I added documentation for when to use and not to use c_void, since it tripped me up when I started. (See issue #7627)

bors added a commit that referenced this pull request Jul 11, 2013
I added documentation for when to use and not to use `c_void`, since it tripped me up when I started. (See issue #7627)
@borsbors closed this Jul 11, 2013
@bors
bors merged commit 663a959 into rust-lang:masterJul 11, 2013
@kevinmehall
kevinmehall deleted the document-c_void branch July 11, 2013 12:32
flip1995 pushed a commit to flip1995/rust that referenced this pull request Sep 28, 2021
Change `while_let_on_iterator` suggestion to use `by_ref()`
It came up in the discussion rust-lang#7659 that suggesting `iter.by_ref()` is a clearer suggestion than `&mut iter`. I personally think they're equivalent, but if `by_ref()` is clearer to people then that should be the suggestion.
changelog: Change `while_let_on_iterator` suggestion when using `&mut` to use `by_ref()`
U007D pushed a commit to U007D/rust-mos that referenced this pull request Aug 21, 2026
7690: Extract `fn load_workspace(…)` from `fn load_cargo(…)` r=matklad a=regexident
Unfortunately in rust-lang/rust-analyzer#7595 I forgot to `pub use` (rather than just `use`) the newly introduced `LoadCargoConfig`.
So this PR fixes this now.
It also:
- splits up `fn load_cargo` into a "workspace loading" and a "project loading" phase
- adds a `progress: &dyn Fn(String)` to allow third-parties to provide CLI progress updates, too
The motivation behind both of these is the fact that rust-analyzer currently does not support caching.
As such any third-party making use of `ra_ap_…` needs to providing a caching layer itself.
Unlike for rust-analyzer itself however a common use-pattern of third-parties is to analyze a specific target (`--lib`/`--bin <BIN>`/…) from a specific package (`--package`). The targets/packages of a crate can be obtained via `ProjectWorkspace::load(…)`, which currently is performed inside of `fn load_cargo`, effectively making the returned `ProjectWorkspace` inaccessible to the outer caller. With this information one can then provide early error handling via CLI (in case of ambiguities or invalid arguments, etc), instead of `fn load_cargo` failing with a possibly obscure error message. It also allows for annotating the persisted caches with its specific associated package/target selector and short-circuit quickly if a matching cache is found on disk, significantly cutting load times.
Before:
```rust
pub struct LoadCargoConfig {
pub cargo_config: &CargoConfig,
pub load_out_dirs_from_check: bool,
pub with_proc_macro: bool,
}
pub fn load_cargo(
root: &Path,
config: &LoadCargoConfig
) -> Result<(AnalysisHost, vfs::Vfs)> {
// ...
}
```
After:
```rust
pub fn load_workspace(
root: &Path,
config: &CargoConfig,
progress: &dyn Fn(String),
) -> Result<ProjectWorkspace> {
// ...
}
pub struct LoadCargoConfig {
pub load_out_dirs_from_check: bool,
pub with_proc_macro: bool,
}
pub fn load_cargo(
ws: ProjectWorkspace,
config: &LoadCargoConfig,
progress: &dyn Fn(String),
) -> Result<(AnalysisHost, vfs::Vfs)> {
// ...
}
```
Co-authored-by: Vincent Esche <regexident@gmail.com>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@kevinmehall@huonw@bors