Rollup of 7 pull requests #110331
Merged
Rollup of 7 pull requests #110331
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
The interaction between the environment variable methods can be confusing. Specifically `env_clear` and `remove_env` have a side effects not mentioned: they disable inheriting environment variables from the parent process. I wanted to fully document this behavior as well as explain relevant edge cases in each of the `Command` env methods. This is further confused by the return of `get_envs` which will return key/None if `remove_env` has been used, but an empty iterator if `env_clear` has been called. Or a non-empty iterator if `env_clear` was called and later explicit mappings are added. Currently there is no way (that I'm able to find) of observing whether or not the internal `env_clear=true` been toggled on the `Command` struct via its public API. Ultimately environment variable mappings can be in one of several states: - Explicitly set value (via `envs` / `env`) will take precedence over parent mapping - Not explicitly set, will inherit mapping from parent - Explicitly removed via `remove_env`, this single mapping will not inherit from parent - Implicitly removed via `env_clear`, no mappings will inherit from parent I tried to represent this in the relevant sections of the docs. This is my second ever doc PR (whoop!). I'm happy to take specific or general doc feedback. Also happy to explain the logic behind any changes or additions I made.
Fixes documentation. I wrote `env_clear` when I meant `env_remove`. Good catch. Co-authored-by: Josh Stone <cuviper@gmail.com>
…solved to a proc-macro and a trait at the same time
…at_expr_source_of_inferred_type, r=oli-obk Reformulate `point_at_expr_source_of_inferred_type` to be more accurate Be more accurate when deducing where along the several usages of a binding it is constrained to be some type that is incompatible with an expectation. This also renames the method to `note_source_of_type_mismatch_constraint` because I prefer that name, though I guess I can revert that. (Also drive-by rename `note_result_coercion` -> `suggest_coercing_result_via_try_operator`, because it's suggesting, not noting!) This PR is (probably?) best reviewed per commit, but it does regress a bit only to fix it later on, so it could also be reviewed as a whole if that makes the final results more clear. r? `@estebank`
…and-env-methods, r=Amanieu Add Command environment variable inheritance docs The interaction between the environment variable methods can be confusing. Specifically `env_clear` and `remove_env` have a side effects not mentioned: they disable inheriting environment variables from the parent process. I wanted to fully document this behavior as well as explain relevant edge cases in each of the `Command` env methods. This is further confused by the return of `get_envs` which will return key/None if `remove_env` has been used, but an empty iterator if `env_clear` has been called. Or a non-empty iterator if `env_clear` was called and later explicit mappings are added. Currently there is no way (that I'm able to find) of observing whether or not the internal `env_clear=true` been toggled on the `Command` struct via its public API. Ultimately environment variable mappings can be in one of several states: - Explicitly set value (via `envs` / `env`) will take precedence over parent mapping - Not explicitly set, will inherit mapping from parent - Explicitly removed via `remove_env`, this single mapping will not inherit from parent - Implicitly removed via `env_clear`, no mappings will inherit from parent I tried to represent this in the relevant sections of the docs. This is my second-ever doc PR (whoop!). I'm happy to take specific or general doc feedback. Also happy to explain the logic behind any changes or additions I made.
…ohnTitor Add links from `core::cmp` derives to their traits Fixes rust-lang#109946 Adds intra-doc links from the `core::cmp` derives to their respective traits, and a link to their derive behaviour `@rustbot` label +A-docs
…ohnTitor Use `Display` in top-level example for `PanicInfo` Addresses rust-lang#110098. This confused me as well, when I was writing a `no_std` panic handler for the first time, so here's a better top-level example. `Display` is stable, prints the `.message()` if available, and falls back to `.payload().downcast_ref<&str>()` if the message is not available. So this example should provide strictly more information and also work for formatted panics. The old example still exists on the `payload` method.
Fix typos in library I ran [`typos -w library`](https://github.com/crate-ci/typos) to fix typos in the `library` directory. Refs rust-lang#110150
…nTitor Remove some unneeded imports / qualified paths Continuation of rust-lang#105537.
…-proc-trait, r=notriddle [rustdoc] Add explanations for auto-disambiguation when an intra doc link is resolved to a proc-macro and a trait at the same time Part of rust-lang#110111. r? `@notriddle`
rustbot
added
A-rustdoc-json
|
@bors r+ rollup=never p=7 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR: previous master: 276fa29480 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Apr 14, 2023
|
Finished benchmarking commit (84dd17b): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. |
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.
Successful merges:
point_at_expr_source_of_inferred_typeto be more accurate #108687 (Reformulatepoint_at_expr_source_of_inferred_typeto be more accurate)core::cmpderives to their traits #109947 (Add links fromcore::cmpderives to their traits)Displayin top-level example forPanicInfo#110110 (UseDisplayin top-level example forPanicInfo)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup