Skip to content

Commit

Permalink
Merge pull request #213 from FFY00/update-org-name
Browse files Browse the repository at this point in the history
Update repository name
  • Loading branch information
myrrlyn committed Apr 12, 2023
2 parents 0e8cdf6 + 86f27d5 commit f0ad5e5
Show file tree
Hide file tree
Showing 24 changed files with 58 additions and 58 deletions.
40 changes: 20 additions & 20 deletions CHANGELOG.md
Expand Up @@ -373,32 +373,32 @@ from crates.io in the future.

<!-- Issues -->

[Issue #6]: https://github.com/bitvecto-rs/bitvec/issues/6
[Issue #17]: https://github.com/bitvecto-rs/bitvec/issues/17
[Issue #32]: https://github.com/bitvecto-rs/bitvec/issues/32
[Issue #50]: https://github.com/bitvecto-rs/bitvec/issues/50
[Issue #69]: https://github.com/bitvecto-rs/bitvec/issues/69
[Issue #75]: https://github.com/bitvecto-rs/bitvec/issues/75
[Issue #83]: https://github.com/bitvecto-rs/bitvec/issues/83
[Issue #103]: https://github.com/bitvecto-rs/bitvec/issues/103
[Issue #114]: https://github.com/bitvecto-rs/bitvec/issues/114
[Issue #136]: https://github.com/bitvecto-rs/bitvec/issues/136
[Issue #156]: https://github.com/bitvecto-rs/bitvec/issues/156
[Issue #167]: https://github.com/bitvecto-rs/bitvec/issues/167
[Issue #169]: https://github.com/bitvecto-rs/bitvec/issues/169
[Issue #6]: https://github.com/ferrilab/bitvec/issues/6
[Issue #17]: https://github.com/ferrilab/bitvec/issues/17
[Issue #32]: https://github.com/ferrilab/bitvec/issues/32
[Issue #50]: https://github.com/ferrilab/bitvec/issues/50
[Issue #69]: https://github.com/ferrilab/bitvec/issues/69
[Issue #75]: https://github.com/ferrilab/bitvec/issues/75
[Issue #83]: https://github.com/ferrilab/bitvec/issues/83
[Issue #103]: https://github.com/ferrilab/bitvec/issues/103
[Issue #114]: https://github.com/ferrilab/bitvec/issues/114
[Issue #136]: https://github.com/ferrilab/bitvec/issues/136
[Issue #156]: https://github.com/ferrilab/bitvec/issues/156
[Issue #167]: https://github.com/ferrilab/bitvec/issues/167
[Issue #169]: https://github.com/ferrilab/bitvec/issues/169

<!-- Pull Requests -->

[Pull Request #34]: https://github.com/bitvecto-rs/bitvec/pull/34
[Pull Request #68]: https://github.com/bitvecto-rs/bitvec/pull/68
[Pull Request #104]: https://github.com/bitvecto-rs/bitvec/pull/104
[Pull Request #160]: https://github.com/bitvecto-rs/bitvec/pull/160
[Pull Request #162]: https://github.com/bitvecto-rs/bitvec/pull/162
[Pull Request #185]: https://github.com/bitvecto-rs/bitvec/pull/185
[Pull Request #34]: https://github.com/ferrilab/bitvec/pull/34
[Pull Request #68]: https://github.com/ferrilab/bitvec/pull/68
[Pull Request #104]: https://github.com/ferrilab/bitvec/pull/104
[Pull Request #160]: https://github.com/ferrilab/bitvec/pull/160
[Pull Request #162]: https://github.com/ferrilab/bitvec/pull/162
[Pull Request #185]: https://github.com/ferrilab/bitvec/pull/185

<!-- Other -->

[`bit-set`]: https://crates.io/crates/bit-set
[`sharksforarms/deku#246`]: https://github.com/sharksforarms/deku/pull/246
[kac]: https://keepachangelog.com/en/1.0.0/
[user guide]: https://bitvecto-rs.github.io/bitvec/
[user guide]: https://ferrilab.github.io/bitvec/
2 changes: 1 addition & 1 deletion CODE_OF_CONDUCT.md
Expand Up @@ -8,4 +8,4 @@ me, over any medium, about the project.

[Twitter account]: https://twitter.com/bitvec_rs
[coc]: https://www.rust-lang.org/policies/code-of-conduct
[repository]: https://github.com/myrrlyn/bitvec
[repository]: https://github.com/ferrilab/bitvec
10 changes: 5 additions & 5 deletions Cargo.toml
Expand Up @@ -17,7 +17,7 @@ categories = [
]
description = "Addresses memory by bits, for packed collections and bitfields"
documentation = "https://docs.rs/bitvec/latest/bitvec"
homepage = "https://bitvecto-rs.github.io/bitvec"
homepage = "https://ferrilab.github.io/bitvec"
include = [
"Cargo.toml",
"LICENSE.txt",
Expand All @@ -35,7 +35,7 @@ keywords = [
]
license = "MIT"
readme = "README.md"
repository = "https://github.com/bitvecto-rs/bitvec"
repository = "https://github.com/ferrilab/bitvec"
rust-version = "1.56"

[features]
Expand Down Expand Up @@ -95,15 +95,15 @@ features = [
]

[badges.codecov]
repository = "bitvecto-rs/bitvec"
repository = "ferrilab/bitvec"
branch = "main"
service = "github"

[badges.is-it-maintained-issue-resolution]
repository = "bitvecto-rs/bitvec"
repository = "ferrilab/bitvec"

[badges.is-it-maintained-open-issues]
repository = "bitvecto-rs/bitvec"
repository = "ferrilab/bitvec"

[badges.maintenance]
status = "passively-maintained"
6 changes: 3 additions & 3 deletions README.md
Expand Up @@ -395,7 +395,7 @@ does, how it works, and how it can be useful to you.
[docs_link]: https://docs.rs/bitvec/latest/bitvec "Crate documentation"
[docs_img]: https://img.shields.io/docsrs/bitvec/latest.svg?style=for-the-badge "Documentation badge"
[downloads_img]: https://img.shields.io/crates/dv/bitvec.svg?style=for-the-badge "Crate downloads"
[license_file]: https://github.com/bitvecto-rs/bitvec/blob/main/LICENSE.txt "Project license"
[license_file]: https://github.com/ferrilab/bitvec/blob/main/LICENSE.txt "Project license"
[license_img]: https://img.shields.io/crates/l/bitvec.svg?style=for-the-badge "License badge"
[msrv_img]: https://img.shields.io/badge/MSRV-1.56-f46623?style=for-the-badge&logo=rust "Minimum Supported Rust Version: 1.56"

Expand All @@ -414,8 +414,8 @@ does, how it works, and how it can be useful to you.
[`deku`]: https://crates.io/crates/deku
[docsrs]: https://docs.rs/bitvec/latest/bitvec
[erl_bit]: https://www.erlang.org/doc/programming_examples/bit_syntax.html
[guide]: https://bitvecto-rs.github.io/bitvec/
[issue]: https://github.com/bitvecto-rs/bitvec/issues/new
[guide]: https://ferrilab.github.io/bitvec/
[issue]: https://github.com/ferrilab/bitvec/issues/new
[moz]: https://hacks.mozilla.org/2021/04/eliminating-data-races-in-firefox-a-technical-report/ "Mozilla Hacks article describing various concurrency bugs in FireFox"
[`radium`]: https://crates.io/crates/radium
[`std::bitset<N>`]: https://en.cppreference.com/w/cpp/utility/bitset
Expand Down
2 changes: 1 addition & 1 deletion benches/macros.rs
Expand Up @@ -10,7 +10,7 @@ compare the macros against `vec!`. While `vec!` will always be faster, because
Original performance was 10,000x slower. Performance after the fix for #28 was
within 20ns.
[issue #28]: https://github.com/myrrlyn/bitvec/issues/28
[issue #28]: https://github.com/ferrilab/bitvec/issues/28
!*/

#![feature(test)]
Expand Down
2 changes: 1 addition & 1 deletion book/afterword.md
Expand Up @@ -15,4 +15,4 @@ Thank you for using `bitvec`. I am delighted that other people have found my
work both interesting and useful, and I’m glad that I’ve been able to help
people like you write better programs.

[0]: https://github.com/bitvecto-rs/bitvec/issues/new
[0]: https://github.com/ferrilab/bitvec/issues/new
2 changes: 1 addition & 1 deletion book/introduction.md
Expand Up @@ -38,5 +38,5 @@ document, and throughout the book I will periodically remind you that if a
section is unclear, it is an error on my part, and I would appreciate an issue
or other contact so that I can improve it.

[CONTRIBUTING]: https://github.com/myrrlyn/bitvec/blob/HEAD/CONTRIBUTING.md "project contribution guide"
[CONTRIBUTING]: https://github.com/ferrilab/bitvec/blob/HEAD/CONTRIBUTING.md "project contribution guide"
[docs.rs]: https://docs.rs/bitvec "bitvec API documentation"
2 changes: 1 addition & 1 deletion doc/domain/Domain.md
Expand Up @@ -58,6 +58,6 @@ stored value (with all ungoverned bits cleared to 0), and a `.store_value()`
that writes into its governed bits. If present, the fully-occupied slice can be
used as normal.

[0]: https://github.com/bitvecto-rs/bitvec/issues/new
[0]: https://github.com/ferrilab/bitvec/issues/new
[`PartialElement`]: crate::domain::PartialElement
[`PartialElement::load_value`]: crate::domain::PartialElement::load_value
2 changes: 1 addition & 1 deletion doc/field/BitField_Lsb0_load_be.md
Expand Up @@ -74,4 +74,4 @@ for each combination of `<T: BitStore, O: BitOrder>`, and may be of additional
use when choosing a combination of type parameters and load functions.

[orig]: crate::field::BitField::load_le
[user guide]: https://bitvecto-rs.github.io/bitvec/memory-layout
[user guide]: https://ferrilab.github.io/bitvec/memory-layout
2 changes: 1 addition & 1 deletion doc/field/BitField_Lsb0_load_le.md
Expand Up @@ -74,4 +74,4 @@ for each combination of `<T: BitStore, O: BitOrder>`, and may be of additional
use when choosing a combination of type parameters and load functions.

[orig]: crate::field::BitField::load_le
[user guide]: https://bitvecto-rs.github.io/bitvec/memory-layout
[user guide]: https://ferrilab.github.io/bitvec/memory-layout
2 changes: 1 addition & 1 deletion doc/field/BitField_Lsb0_store_be.md
Expand Up @@ -66,4 +66,4 @@ for each combination of `<T: BitStore, O: BitOrder>`, and may be of additional
use when choosing a combination of type parameters and store functions.

[orig]: crate::field::BitField::store_be
[user guide]: https://bitvecto-rs.github.io/bitvec/memory-layout
[user guide]: https://ferrilab.github.io/bitvec/memory-layout
2 changes: 1 addition & 1 deletion doc/field/BitField_Lsb0_store_le.md
Expand Up @@ -66,4 +66,4 @@ for each combination of `<T: BitStore, O: BitOrder>`, and may be of additional
use when choosing a combination of type parameters and store functions.

[orig]: crate::field::BitField::store_le
[user guide]: https://bitvecto-rs.github.io/bitvec/memory-layout
[user guide]: https://ferrilab.github.io/bitvec/memory-layout
2 changes: 1 addition & 1 deletion doc/field/BitField_Msb0_load_be.md
Expand Up @@ -74,4 +74,4 @@ for each combination of `<T: BitStore, O: BitOrder>`, and may be of additional
use when choosing a combination of type parameters and load functions.

[orig]: crate::field::BitField::load_le
[user guide]: https://bitvecto-rs.github.io/bitvec/memory-layout
[user guide]: https://ferrilab.github.io/bitvec/memory-layout
2 changes: 1 addition & 1 deletion doc/field/BitField_Msb0_load_le.md
Expand Up @@ -74,4 +74,4 @@ for each combination of `<T: BitStore, O: BitOrder>`, and may be of additional
use when choosing a combination of type parameters and load functions.

[orig]: crate::field::BitField::load_le
[user guide]: https://bitvecto-rs.github.io/bitvec/memory-layout
[user guide]: https://ferrilab.github.io/bitvec/memory-layout
2 changes: 1 addition & 1 deletion doc/field/BitField_Msb0_store_be.md
Expand Up @@ -66,4 +66,4 @@ for each combination of `<T: BitStore, O: BitOrder>`, and may be of additional
use when choosing a combination of type parameters and store functions.

[orig]: crate::field::BitField::store_be
[user guide]: https://bitvecto-rs.github.io/bitvec/memory-layout
[user guide]: https://ferrilab.github.io/bitvec/memory-layout
2 changes: 1 addition & 1 deletion doc/field/BitField_Msb0_store_le.md
Expand Up @@ -66,4 +66,4 @@ for each combination of `<T: BitStore, O: BitOrder>`, and may be of additional
use when choosing a combination of type parameters and store functions.

[orig]: crate::field::BitField::store_le
[user guide]: https://bitvecto-rs.github.io/bitvec/memory-layout
[user guide]: https://ferrilab.github.io/bitvec/memory-layout
2 changes: 1 addition & 1 deletion doc/order/LocalBits.md
Expand Up @@ -20,4 +20,4 @@ match GCC’s `std::bitset<N>`. It makes no guarantee about what C compilers for
your target actually do, and you will need to do your own investigation if you
are exchanging a single buffer across FFI in this manner.

[0]: https://bitvecto-rs.github.io/bitvec/memory-representation
[0]: https://ferrilab.github.io/bitvec/memory-representation
2 changes: 1 addition & 1 deletion doc/order/Lsb0.md
Expand Up @@ -10,4 +10,4 @@ This is the default type parameter used throughout the crate. If you do not have
a desired memory representation, you should continue to use it, as it provides
the best codegen for bit manipulation.

[0]: https://bitvecto-rs.github.io/bitvec/memory-representation
[0]: https://ferrilab.github.io/bitvec/memory-representation
2 changes: 1 addition & 1 deletion doc/order/Msb0.md
Expand Up @@ -10,4 +10,4 @@ This type likely matches the ordering of bits you would expect to see in a
debugger, but has worse codegen than `Lsb0`, and is not encouraged if you are
not doing direct memory inspection.

[0]: https://bitvecto-rs.github.io/bitvec/memory-representation
[0]: https://ferrilab.github.io/bitvec/memory-representation
2 changes: 1 addition & 1 deletion doc/vec/BitVec.md
Expand Up @@ -161,7 +161,7 @@ to view its contents. You can accomplish this through safe APIs such as
initialize the memory elements underlying the `BitVec` buffer without incurring
undefined behavior in their operation.

[book]: https://bitvecto-rs.github.io/bitvec/type-parameters.html
[book]: https://ferrilab.github.io/bitvec/type-parameters.html
[`BitAccess`]: crate::access::BitAccess
[`BitArray`]: crate::array::BitArray
[`BitField`]: crate::field::BitField
Expand Down
2 changes: 1 addition & 1 deletion src/ptr/span.rs
Expand Up @@ -211,7 +211,7 @@ where
let len_head = head & Self::LEN_HEAD_MASK;
let len_bits = bits << Self::LEN_HEAD_BITS;

/* See <https://github.com/bitvecto-rs/bitvec/issues/135#issuecomment-986357842>.
/* See <https://github.com/ferrilab/bitvec/issues/135#issuecomment-986357842>.
* This attempts to retain inbound provenance information and may help
* Miri better understand pointer operations this module performs.
*
Expand Down
4 changes: 2 additions & 2 deletions src/slice/api.rs
Expand Up @@ -2289,7 +2289,7 @@ where
/// assert!(sfx.len() <= 8);
/// ```
///
/// [layout]: https://bitvecto-rs.github.io/bitvec/memory-layout.html
/// [layout]: https://ferrilab.github.io/bitvec/memory-layout.html
#[inline]
pub unsafe fn align_to<U>(&self) -> (&Self, &BitSlice<U, O>, &Self)
where U: BitStore {
Expand Down Expand Up @@ -2341,7 +2341,7 @@ where
/// assert!(sfx.len() <= 8);
/// ```
///
/// [layout]: https://bitvecto-rs.github.io/bitvec/memory-layout.html
/// [layout]: https://ferrilab.github.io/bitvec/memory-layout.html
#[inline]
pub unsafe fn align_to_mut<U>(
&mut self,
Expand Down
2 changes: 1 addition & 1 deletion tests/bincode.rs
Expand Up @@ -15,7 +15,7 @@ format, but only if its data buffer can be reconstituted from the slice model.
`bitvec` does not guarantee cross-version serialization format compatibility.
[Issue #96]: https://github.com/bitvecto-rs/bitvec/issues/96
[Issue #96]: https://github.com/ferrilab/bitvec/issues/96
!*/

#![cfg(feature = "serde")]
Expand Down
18 changes: 9 additions & 9 deletions tests/issues.rs
Expand Up @@ -20,7 +20,7 @@ In the future, it may be possible to revert to the original
`<[T] as ToOwned>::to_owned` implementation, if `BitVec` becomes capable of
partial heads without loss of pointer information.
[Issue #10]: https://github.com/bitvecto-rs/bitvec/issues/10
[Issue #10]: https://github.com/ferrilab/bitvec/issues/10
[@overminder]: https://github.com/overminder
**/
#[test]
Expand Down Expand Up @@ -68,7 +68,7 @@ and `Vec::reserve` did not see the request amount as requiring a reällocation.
length, which produces the correct reservation request for `Vec::reserve`,
fixing the error.
[Issue #33]: https://github.com/bitvecto-rs/bitvec/issues/33
[Issue #33]: https://github.com/ferrilab/bitvec/issues/33
[@jonas-schievink]: https://github.com/jonas-schievink
**/
#[test]
Expand Down Expand Up @@ -104,7 +104,7 @@ class in `bitvec`. This is the same bug class that occurred in #65, and has the
same solution: uninitialized memory in the `BitVec` buffer is not required to be
zeroed.
[Issue #62]: https://github.com/bitvecto-rs/bitvec/issues/62
[Issue #62]: https://github.com/ferrilab/bitvec/issues/62
[@sharksforarms]: https://github.com/sharksforarms
**/
#[test]
Expand Down Expand Up @@ -200,7 +200,7 @@ fn issue_62() {
This issue found the use of uninitialized memory in
`BitVec::extend_from_bitslice` causing non-deterministic behavior.
[Issue #65]: https://github.com/bitvecto-rs/bitvec/issues/65
[Issue #65]: https://github.com/ferrilab/bitvec/issues/65
[@inikulin]: https://github.com/inikulin
**/
#[test]
Expand All @@ -221,7 +221,7 @@ alarms.
This test is only useful when run under `cargo +nightly miri test`. It asserts
that the allocation pointer is correctly managed during drop.
[Issue #10]: https://github.com/bitvecto-rs/bitvec/issues/69
[Issue #10]: https://github.com/ferrilab/bitvec/issues/69
[@YoshikiTakashima]: https://github.com/YoshikiTakashima
**/
#[test]
Expand All @@ -247,7 +247,7 @@ The overly-large scaling in computation of `.len()` caused `Rev<>`, which relies
on a correct implementation of `.len()`, to attempt to access memory out of
bounds inside `Iter::nth`.
[Issue #77]: https://github.com/bitvecto-rs/bitvec/issues/77
[Issue #77]: https://github.com/ferrilab/bitvec/issues/77
[@Cryptjar]: https://github.com/Cryptjar
**/
#[test]
Expand Down Expand Up @@ -295,7 +295,7 @@ the galloping searches, but for now, this is an improvement over the existing
behavior, so I am going to call it sufficient for the bug as reported, publish
patches, and await further reports.
[Issue #114]: https://github.com/bitvecto-rs/bitvec/issues/114
[Issue #114]: https://github.com/ferrilab/bitvec/issues/114
[@VilleHallivuori]: https://github.com/VilleHallivuori
**/
#[test]
Expand Down Expand Up @@ -325,7 +325,7 @@ The logic for `{leading, trailing}_{zeros, ones}` works by finding the index
of the opposite bit. If the opposite bit does not exist, the correct behavior
is to return the whole length of the slice, rather than 0.
[Issue #120]: https://github.com/bitvecto-rs/bitvec/issues/120
[Issue #120]: https://github.com/ferrilab/bitvec/issues/120
[@hzuo]: https://github.com/hzuo
**/
#[test]
Expand All @@ -346,7 +346,7 @@ I incorrectly implemented parts of `ChunksExact`, subtracting more than was
correct. I have repaired this by directly transcribing from the standard library
implementation.
[Issue #142]: https://github.com/bitvecto-rs/bitvec/issues/142
[Issue #142]: https://github.com/ferrilab/bitvec/issues/142
[@jmmaloney4]: https://github.com/jmmaloney4
**/
#[test]
Expand Down

0 comments on commit f0ad5e5

Please sign in to comment.