This is failing in CI. I have no idea what the rules are and AFAICT
no-one is alleging that there is an actual bug in the attributes.
Empirically this suppression causes the script to pass.
This is a perf issue, only. If tests are too slow, we will notice and
ca speed them up. We should optimise for clarity and convenience,
rather than speed.
Forbidding this can result in churn between vec![] and [] as tests are
updated and changed.
Rationale: no-one writes these by default without thinkinh. If they
are unnecessary, then either the string must have had " in it
before (in which case it might do again), or it is near other strings
which *do* need it.
And having it does no harm; indeed IMO it can increase clarity.
Alternative to !1388's
Fix new "needless_raw_string_hashes" lint from clippy +nightly
Now with cargo semver-checks >= 0.22.1, we no longer need to
jump through hoops in order to only look at the `full` features.
This, combined with our work on `fixup-features`, lets us be
confident that we're only looking at semver breakage in experimental
code.
These are available in our MSRV now, so we don't need to handle
specially. We can just add them to the standard lint block.
(Lint block in every crate will be updated automatically in the next
commit.)
The options are rather complicated; because we do not want to
subject our experimental features to semver, we need to run generate
JSON rustdoc on our own and then pass that JSON to
cargo-semver-checks. This in turn requires us to use the same
options that cargo-semver-checks uses, including "RUSTC_BOOTSTRAP".
I've left some TODOs here in places where we will likely want to
improve our code in the future.
See #711.
Previously we allowed this license unconditionally. But because of its
non-self-enacting nature, we need the actual notice from its "exhibit A"
to appear somewhere that says that it applies to all the relevant code.
Therefore, we shouldn't take new MPL-2.0 dependencies without
hand-checking them. (I am tentatively allowing option-ext, though,
since we already have an indirect dependency on that crate via
`directories`.)
For more info, see https://gitlab.torproject.org/tpo/core/arti/-/issues/845
When building our list of acknowledgments, previously we would only
include author and committer names.
Now we also include anybody listed in the "Reported-by",
"Co-authored-by", and "Thanks" trailers.
The generational-arena crate is distributed under MPL-2.0,
so we need to allow it.
I believe that this license is fine and does not interfere with
our code or our users; the reviewer should double-check.
This commit adds a script that checks the environment for it's suitable
as an Arti development environment.
It follows an idea pitched by Ian Jackson and me in !1025.
Ian Jackson
Ian Jackson
Nick Mathewson
Gabriela Moldovan
trinity-1686a
Dimitris Apostolou
Emil Engler