chore(deps): update rust crate handlebars to `v4.5.0`
In the latest version of `handlebars`, rules for whitespace auto elimination is to check if the directive `{{# xxx}}`` and ``{{/ xxx}}` is holding a whole line, with leading and trailing whitespaces counted, and then remove the trailing NEWLINE (See [`template.rs`](9d7d555628/src/template.rs (L568-L889))).
```md
{{#options}}
<--- this newline will be removed after a standalone block
{{#option "`-o` _outdir_"}}
<--- this newline will be removed
Some content
{{/option}}
<--- this newline will be removed
{{/options}}
<--- this newline will be removed
```
This PR changes includes (fixes#13162):
1. update `handlebars` crate to `v4.5.0`.
2. add extra NEWLINE to helper blocks `options`, `option` to align with the new strip rules, preserving the original behavior.
3. update doc(the rest handlebars expression) to align with the new strip rules..
Like PR 12352 but for homepage and repository
Versions for
* `cargo-credential-1password`
* `cargo-util-schemas`
* `home`
are bumped along with the change.
Avoid writing CACHEDIR.TAG if it already exists
Cargo currently unconditionally writes `CACHEDIR.TAG` files even if they already exist.
This practice causes problems for build systems that disallow multiple writes to the same file.
To implement rust-lang/rfcs#3516, we need to decouple the resolver's
behavior from the unstable flag. Since the code path is now dead, I
went ahead and removed it.
review and remove ignored tests in rustfix
### What does this PR try to resolve?
review ignored tests in rustfix crate per #13034.
### How should we test and review this PR?
CI testing
### Additional information
* Removed unproductive test in `parse_and_replace`
* un-ignore proptests, and reduce runtime from ~2s to ~<.25s
Migrate rustfix to the cargo repo
This migrates the `rustfix` crate from https://github.com/rust-lang/rustfix/ to the cargo repo. The cargo team has been responsible for the client-side of `cargo fix`, and it can make it easier to maintain with all our tooling and tracking here. This crate is used by some external parties (like the compiler), so it will need to be maintained like an "ecosystem" package, but hopefully there shouldn't be any outside requirements (I haven't seen any in several years).
After merging, I'll follow up with some things to address in the future, such as:
- Migrating issues from the other repo.
- Opening new issues for some cleanup tasks, such as adding documentation, fixing the `#[ignore]` annotations, fixing testing on windows, maybe migrating the test code to use different dependencies, various code cleanup.
- Archiving the repo.
