build(deps): bump bitvec from 1.0.0 to 1.0.1

[dependabot]

Bumps bitvec from 1.0.0 to 1.0.1.

Changelog

Sourced from bitvec's changelog.

1.0.1

Notes

Performance regressions have been reported between the development series 0.20 onwards and 1.0. It appears at least some of these regressions are due to the removal of the #[inline] attribute on bitvec public functions.

This attribute has been applied to all bitvec functions. You may see regressions in size of your final artifact, but you should also see improvements in your runtime speed. This is being tracked in [sharksforarms/deku#246].

Changes

• The bits![static mut …] invocation has been made unsafe at the invocation site, in response to [Issue #156] filed by GitHub user [@​SimonSapin].

  This is technically an API break (formerly safe code now requires an unsafe block) but as no run-time behavior or compile-time types have changed except for this, and Rust considers breaking incorrect code to be acceptable within SemVer patches, I am publishing it as a patch.

• GitHub user [@​dtolnay] fixed incorrect serde behaviors in [Pull Request #185]. This behavior was first reported in [Issue #167] by GitHub user [@​Nelarius].

• Compilation no longer depends on environment variables set by Cargo, as requested in [Pull Request #162] by GitHub user [@​rocallahan].

• The bitvec![val; len] macro can again take len as a runtime value as well as a compile-time constant. [Pull Request #160] was provided by GitHub user [@​coolreader18].

• The return types of slice::Iter::by_{refs,vals} are restored to named types, rather than impl Iterator... opaque types. This allows them to be used directly in other sites. This defect was reported in [Issue #169] by GitHub user [@​dignifiedquire].

Commits

• See full diff in compare view

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 commands and options

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 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)

[codecov]

Codecov Report

Merging #4769 (327b54e) into main (f7889ac) will decrease coverage by 0.05%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #4769      +/-   ##
==========================================
- Coverage   78.91%   78.86%   -0.06%     
==========================================
  Files         306      306              
  Lines       37664    37664              
==========================================
- Hits        29722    29702      -20     
- Misses       7942     7962      +20     

[conradoplg]

We want to use the same version as our dependencies unless there's a good reason not to

@dependabot ignore this minor version

[dependabot]

OK, I won't notify you about version 1.0.x again, unless you re-open this PR or update to a 1.0.x release yourself.

[str4d]

There's a good reason to use this dependency: it allegedly fixes significant performance regressions from 0.20 (which we did indeed observe when we migrated ff to bitvec 1). I haven't had time to check whether the changes fix our regression, but we should try it.

[teor2345]

@dependabot reopen

[teor2345]

We might not want to wait for our dependencies on this.
(And if they haven't pinned their versions, they will automatically update when we do.)

[conradoplg]

Looks good, compared with ferrilab/bitvec@072705d...440f4e6

[str4d]

Tested the bellman benchmarks against bitvec 1.0.1 and it looks like it does fix the performance regression we had when moving from bitvec 0.20 to bitvec 1.0.0:

multiexp/65536          time:   [118.45 ms 118.97 ms 119.49 ms]                           
                        change: [-14.833% -14.283% -13.768%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 11 outliers among 100 measurements (11.00%)
  8 (8.00%) low mild
  3 (3.00%) high mild

[teor2345]

I'm admin-merging this because it fixes a performance issue.