| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
(We don't need as many of these to be public as I had originally
thought.)
|
| |
|
|
| |
Run maint/add_warning
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
|
| | |
|
| |
|
|
|
|
|
| |
In general, we try to obey the convention that an error's Display
method does not display that error's sources.
Part of #1650.
|
| |
|
|
| |
Closes #1753
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This name change should emphasize that the (module-private)
`ParsedRequestFields` type is only for parsing, and we aren't
supposed to actually construct them for our own requests.
With this change, and the others on the branch, there's no longer a
risk of trying to serialize a ParsedRequestFields (since it doesn't
implement Serialize), or to deserialize a Request (since it doesn't
implement Deserialize).
Closes #1511.
|
| |
|
|
|
|
|
|
| |
As with responses, we previously used a strategy that could have
failed in the future, if we forgot to add an "unexpected_fields"
member to one of our structs.
Closes #1512.
|
| | |
|
| |
|
|
|
|
| |
This lets us make a couple of types module-private,
and prepares the way for using the serde_json::Value trick on
requests too.
|
| | |
|
| |
|
|
|
|
|
|
| |
This approach keeps the property that we still preserve any
unrecognized fields, but takes a different approach. Instead of
using our own `structs` to round-trip the json, we use a
`serde_json::Value`, to ensure that we cannot forget to add the
`unexpected_fields` element to a struct.
|
| |\
| |
| |
| |
| |
| |
| | |
rpc-client-core: Always re-encode requests and responses, and preserve unrecognized struct fields.
Closes #1491
See merge request tpo/core/arti!2312
|
| | |
| |
| |
| | |
This enable a `meta` object to have no `updates` field set.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We want to re-encode responses to avoid possible mismatch between
how arti-rpc-client-core parses messages and how the user application
parses messages. (In theory this shouldn't be necessary so long as
arti-rpc-client-core and arti have the same json implementation,
and arti-rpc-client-core is only used for talking to arti.
But those assumptions might change in the future.)
Closes #1491.
We want to preserve fields so that, if Arti adds any new elements
to response or error in the future, and the client knows about them,
they won't be lost simply because arti-rpc-client-core hasn't heard
of them.
|
| | |
| |
| |
| |
| |
| | |
When writing a request, we want to keep any fields that we don't
recognize, in case the application (and arti) know about some
field that we haven't heard of.
|
| | |
| |
| |
| | |
(They are about to diverge even further.)
|
| |/
|
|
|
| |
This will make error outputs more usable, and will make it possible
to expose OS error codes.
|
| | |
|
| |
|
|
| |
(Internally, it is a boxed CStr that is always UTF-8.)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Per discussion, this field isn't really specified in a way that lets
us fill it sensibly at the moment. So for now, we're going to just
omit it.
Additionally, we said that we'd Report on our errors; this branch
changes the implementation of RpcError to do that.
Question: Will the blanket implementation for Into<RpcError> make
it harder to re-add a Data field later on if we want to do so?
|
| |
|
|
|
| |
We've wanted separate error codes for "no such method exists" and
"this method exists, but this object doesn't have it."
|
| |
|
|
|
|
| |
The "complex" test here is fairly involved, since it tries to detect
deadlocks and race conditions by using multiple threads and
answering requests out of order.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
If we return RpcError by default, we don't give a good way to
actually access the original error string.
(Nonetheless, we still enforce that errors can be decoded as
RpcError.)
|
| | |
|
| | |
|
| | |
|
| |
|
