| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/4223#note_3438341
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
I find this names confusing. To my mind "is" implies a function
returning `bool`.
|
| |
|
|
|
|
|
| |
I find these names confusing. To my mind "check" implies a function
returning `Result<(), _>`.
Some other APIs use `unwrap` here but I think `if` is good.
|
| | |
|
| | |
|
| |
|
|
|
| |
It wouldn't make much sense for one concrete type to be unwrappable
variously as different inner types.
|
| | |
|
| |
|
|
|
| |
It is better to return a more cooked type. `TimeRange` aka
`TimeRangeBound<()>` is perfect for this.
|
| |
|
|
|
|
|
|
|
|
|
| |
Now that we have `bounds()`, we can centralise this implementation and
delete the implementations.
I don't think it's necessary to provide an engineered safeguard
against downstreams overriding this method. Any existing implementors
of this trait will break because they must provide `.bounds()` now,
which is an opportunity to notice that the `is_valid_at` can be
deleted. But, if it is not deleted, nothing goes wrong.
|
| |
|
|
|
| |
This was always TimeValidityError. And we want to rely on that so we
can do the validity checking more centrally.
|
| |
|
|
|
|
|
| |
This makes a `TimeBound` much more convenient to work with, will allow
more centralisation.
This replaces temporary `bound` inherent method on `TimeRangeBound`.
|
| | |
|
| |
|
|
|
| |
This is our time range type, so it wants a bunch of useful methods and
conversions.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
It was confusing that one of these functions had "which bound"
mentioned in its name, but the other didn't. So add `end` and switch
from `tolerance` to `bound` (see previous commit message).
*This* commit should deal only in `extend_tolerance` and `end` and
shouldn't touch `extend_start_bound` or `extend_pre_tolerance`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Although it is often used to apply a tolerance, it doesn't make sense
to say that this is extending the "tolerance" of a `TimeRangeBound`.
A `TimeRangeBound` doesn't have a tolerance, only bounds.
Also we should be consistent in our terminology, and use `start`
rather than `pre`.
We'll rename the other method too. Doing them one at a time will
makes it easier to spot any "pre/start" vs "<nothing>/end" slips:
*this* commit should deal only in `pre` and `start` and shouldn't
touch `extend_tolerance`.
|
| |
|
|
|
| |
This puts the start bounds extension function before the end one.
That makes sense because starts are before ends.
|
| |
|
|
|
|
|
|
|
|
| |
This just returns a tuple.
We're going to introduce a new method that returns a `TimeRagne` and
will want to be called `bounds`.
That method will want to be in the `TimeBound` trait, but for now we
add it here. Various call sites will be added in forthcoming commits.
|
| | |
|
| |
|
|
|
|
| |
This module has only few public items - currently, only one. And it
has the word "time" in it. It doesn't make sense to expect callers to
write `timed::`.
|
| |
|
|
|
| |
I noticed this clumsiness while passing. We can't do the same
for SystemTime because we have the wasm SystemTime thing too :-/.
|
| | |
|
| | |
|
| |
|
|
| |
For consistency with the TimeBound trait.
|
| | |
|
| |
|
|
| |
For consistency with TimeRangeBounds (currently TimerangeBounds).
|
| | |
|
| |
|
|
| |
Removed unnecessary lint
|
| | |
|
| |
|
|
|
| |
This commit updates Timebound's rustdoc to require inclusiveness when
checking the timeliness of a given object.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes more sense because:
* `start_bound` and `end_bound` return `Bound::Included`
* It doesn't make sense to say that a document isn't valid at
the very start of its validity period. (And we don't want a half-open range.)
* NotYetValid(0ns) and Expired(0ns) are rather nonsensical errors.
In real timeliness tests it will make no difference since the current
time is only equal to the bound for a nanosecond. But tests that like
to test corner cases might be affected, and possibly some synthetic
situations (where the document's own validity time start is used
somehow) might change.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit executes maint/add_warning with the just added change to
deny string slices except in tests.
I recommend auditing this by checking out the previous commit followed
by running the script yourself and then verifying that the diff is
identical to this commit.
This commit makes cargo clippy fail. We will add exceptions in the next
commit.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
`clippy::collapsible_if` started triggering after bumping the MSRV to
1.88.
Since this triggers from a lot of places, and since there even are a
couple of instances where we explicitly allow `clippy::collapsible_ifs`,
I've opened #2342 for deciding what to do about it.
|
| |
|
|
| |
This adds the lint to all our crates.
|
| |
|
|
| |
Run maint/add_warning
|
| |
|
|
| |
This feature has been removed from nightly, in favor of doc_cfg.
|
| |
|
|
| |
See #2060.
|
| |
|
|
|
|
| |
Denies 'mod.rs' files for consistency.
https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files
|
| |
|
|
|
|
|
|
| |
In 1.83, this warning triggers on many of our crates.
We're thinking of fixing them all, but for now,
we're going to disable the warning.
This is part of #1765.
|
| |
|
|
| |
Fixes: #1691
|
| |
|
|
| |
This commit is automatically generated.
|
