RFC 2145 is in beta now, deprecating the public_in_private lint.
https://rust-lang.github.io/rfcs/2145-type-privacy.html
public_in_private has been superceded by three new lints. The first two
are warn-by-default and the third is allow-by-default. See the excerpt
below for some details.
This change skips this lint in nightly and beta in favor of the new
warn-by-default lints.
This change revealed a bug in the toolchain config option for
color-spantrace -- it doesn't exist! The lint it was guarding was never
turned on. This adds a minimal build script to check for toolchain to
color-spantrace. Its functionality is tested in the eyre crate, which
seems sufficient to me.
After this change there are only two more build warnings for eyre and
color-spantrace, the future-incompat dependency warning and the more
serious filename collision.
<quote>
Lint private_interfaces is reported when a type with visibility x is
used in primary interface of an item with effective visibility y and
x < y. This lint is warn-by-default.
Lint private_bounds is reported when a type or trait with visibility
x is used in secondary interface of an item with effective
visibility y and x < y. This lint is warn-by-default.
Lint unnameable_types is reported when effective visibility of a
type is larger than module in which it can be named, either
directly, or through reexports, or through trivial type aliases
(type X = Y;, no generics on both sides). This lint is
allow-by-default.
Compatibility lint private_in_public is never reported and removed.
</quote>
pyo3 v0.13.2 is tripping future-incompat. This change updates it to the newest 0.20.
pyo3 v0.16.0 renamed pvalue -> value.
The other future-incompat dependency, nom, is an indirect dependency through ansi-parser.
See issue 116
Warning: output filename collision appears in both stable and nightly builds.
It's slightly more impactful than just a warning. Running cargo +nightly
test, cargo test, cargo +nightly test in windows produces a linker error
where color-spantrace tries to use eyre's usage.exe, see error 2 below.
It's worked around pretty easily with cargo clean, but it's a problem
that might get worse as the monorepo effort expands!
This patch renames `usage.rs` to `CRATENAME-usage.rs`.
Issue #115
no_std support was removed in 2020 with PR #29. This change updates the documentation to reflect that as suggested in PR #89. It still mentions no_std, which will hopefully keep it on our minds enough to check sometimes and see if the upstream problem has been resolved.
Co-authored-by: Jane Losare-Lusby <jlusby@yaah.dev>
The rustdoc_missing_doc_code_examples lint has been sending
warnings and causing CI issues due to being an unstable feature.
This change introduces a small build script that detects whether
the current toolchain is nightly and, if so, sets the config option
"nightly_features". This config option then sets the feature gate
for missing_doc_code_examples and turns on 'warn'.
It expands the existing code for parsing minor version
to parse the rest of the rust --version.
This change also introduces a toolchain test that uses
rust_version to double-check that the config option was enabled
IFF the nightly toolchain is being used.
* fix(miri): box transmute and invalid references
The general causes for the miri invalidation is the prevelant use of
`Box` and its references to `ErrorImpl<()>`.
`mem::transmute` does not preserve the tag stack for transmuting the
boxes.
Additionally, having references to `ErrorImpl<()>` which has a different
layout than the allocation or `ErrorImpl<E>` for some unknown `E`. This
causes the new "untyped" reference to now have a provenance that
includes the size of E and thus is outside the provenance.
* fix(miri): downcast_mut using `&mut _ => *const _ => *mut`
* fix(miri): stub file reading
* fix(miri): don't construct temp references of shunk provenance
* ci: miri
* fix: `unsafe_op_in_unsafe_fn`
* chore!: bump MSRV
* chore: address PR comments
* fix: ci workflow names
* chore: raise msrv to 1.65 (addr2line)
* chore: revert distinctive CI names due to branch protection rules
The new names, such as `Test Platform Matrix` which do make it easier to
see which jobs failed, rather than msrv, test, and miri all being called
`Test Suite`, the in-place branch protection rules wait forever until
the now non-existent `Test Suite` passes
Not using the error type after construction is a common mistake. This can also easily happen with the provided macros, when using `eyre!` instead of `eyre::bail!`. By marking the type as `#[must_use]`, the compiler warns us in such cases.
* Add must-install feature, so that a non-default handler can be the only handler consuming .text.
* Provide a better panic message if `must-install` feature is enabled.
Co-authored-by: Jane Lusby <jlusby42@gmail.com>
* Bump version because new feature was added.
* Convert must-install feature to auto-install to avoid negative features.
* Add ability to manually install DefaultHandler (for when auto-install is disabled).
* Ensure doctests pass when auto-install feature is disabled.
* Integration tests now succeed without auto-install feature.
* Add integration test for when auto-install feature is disabled.
* Add auto-install feature testing to CI.
* cargo fmt.
Co-authored-by: Jane Lusby <jlusby42@gmail.com>
Co-authored-by: Jane Lusby <jlusby@yaah.dev>
* update changelog
* mention new format args capture in docs
* cfg doctest to compile on all versions of rustc
* update field for newer versions of cargo release
* (cargo-release) version 0.6.6
