mirror of
https://github.com/google/comprehensive-rust.git
synced 2025-03-22 06:51:58 +02:00
build(deps): bump serde_yaml from 0.9.28 to 0.9.29 (#1630)
Bumps [serde_yaml](https://github.com/dtolnay/serde-yaml) from 0.9.28 to 0.9.29. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/dtolnay/serde-yaml/releases">serde_yaml's releases</a>.</em></p> <blockquote> <h2>0.9.29</h2> <ul> <li>Turn on <code>deny(unsafe_op_in_unsafe_fn)</code> lint</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="b957d2b15d
"><code>b957d2b</code></a> Release 0.9.29</li> <li><a href="007fc2d5c1
"><code>007fc2d</code></a> Merge pull request <a href="https://redirect.github.com/dtolnay/serde-yaml/issues/401">#401</a> from dtolnay/unsafeop</li> <li><a href="5bac2475b0
"><code>5bac247</code></a> Fill in unsafe blocks inside unsafe functions</li> <li><a href="0f6dba18ab
"><code>0f6dba1</code></a> Turn on deny(unsafe_op_in_unsafe_fn)</li> <li>See full diff in <a href="https://github.com/dtolnay/serde-yaml/compare/0.9.28...0.9.29">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
This commit is contained in:
parent
f4ad9d9caf
commit
b2db08a014
4
Cargo.lock
generated
4
Cargo.lock
generated
@ -2076,9 +2076,9 @@ dependencies = [
|
||||
|
||||
[[package]]
|
||||
name = "serde_yaml"
|
||||
version = "0.9.28"
|
||||
version = "0.9.29"
|
||||
source = "registry+https://github.com/rust-lang/crates.io-index"
|
||||
checksum = "9269cfafc7e0257ee4a42f3f68a307f458c63d9e7c8ba4b58c5d15f1b7d7e8d3"
|
||||
checksum = "a15e0ef66bf939a7c890a0bf6d5a733c70202225f9888a89ed5c62298b019129"
|
||||
dependencies = [
|
||||
"indexmap",
|
||||
"itoa",
|
||||
|
@ -69,9 +69,9 @@ by the compiler. Note that this is not the case for raw pointers (unsafe), and
|
||||
this is a common source of errors with unsafe Rust.
|
||||
|
||||
Students may ask when to use lifetimes. Rust borrows _always_ have lifetimes.
|
||||
Most of the time, elision and type inference mean these don't need to be
|
||||
written out. In more complicated cases, lifetime annotations can help resolve
|
||||
ambiguity. Often, especially when prototyping, it's easier to just work with
|
||||
owned data by cloning values where necessary.
|
||||
Most of the time, elision and type inference mean these don't need to be written
|
||||
out. In more complicated cases, lifetime annotations can help resolve ambiguity.
|
||||
Often, especially when prototyping, it's easier to just work with owned data by
|
||||
cloning values where necessary.
|
||||
|
||||
</details>
|
||||
|
Loading…
x
Reference in New Issue
Block a user