This commit implements a workaround for an [issue within rustc]. The
problem showed itself when using e.g. a `Vec<&str>` argument in an async
route handler (but not `&str`), which resulted in a "implementation of
`FromForm` is not general enough" error. The workaround itself works by
gathering all invocations of `FromForm`'s methods inside a block without
any `.await` points [ref].
[issue within rustc]: https://github.com/rust-lang/rust/issues/69663
[ref]: https://github.com/rust-lang/rust/issues/57478#issuecomment-501186084
The primary aim of this commit is to reduce confusion between
'content::Json' and 'rocket::serde::json::Json' be renaming the former
to 'content::RawJson'. The complete changes in this PR are:
* All responders in the 'content' module are prefixed with 'Raw'.
* The 'content::Custom' responder was removed entirely.
* The 'Plain' responder is now 'RawText'.
* The 'content' API docs point to the 'serde' responders.
* The docs and examples were updated accordingly.
Previously, TLS, via 'Config::tls', was configurable even if the 'tls'
feature was disabled. This commit changes this so that the 'Config::tls'
field and TLS config structures are only available if 'tls' is enabled.
Instead of a constructor, 'MediaType::with_params()' and
'ContentType::with_params()' are now both builder methods. This allow
chaining the method to associated constants.
As 'FromForm' doesn't provide access to the raw, undecoded string,
'MsgPack' cannot implement 'FromForm::from_value()'. This means that it
is not presently possible to parse a MessagePack form from a query
string. As such, the 'UriDisplay<Query>' implementation was removed.
The 'UriDisplay<Query>' for JSON was fixed such that a round-trip of a
'Json<T>' as a form works as expected.
The 'FromFrom' derive now allows type generics in all positions using
the same automatic discovery technique as with 'Responder'. (In fact,
the technique was created for this derive.) Furthermore, 'FromForm' can
now be derived for unit structs.
Also adds a new 'try_with' form field validator.
Resolves#1695.
This commit presents and applies a new technique for bounding type
generics in derives. In short, for a generic `T` used in a field type of
`Field<T>`, where an eventual bound of `Responder` required, the derive
generates a bound of `Field<T>: Responder`. This removes the need for
any manually provided bounds while simultaneously allowing more
structures to typecheck. For example, generics in header components are
now fully supported.
The 'Json' type now implements:
* Clone
* PartialEq
* Eq
* PartialOrd
* Ord
* Hash
* UriDisplay<Query>
Method calls that resolve to a method in the set of traits above
previously resolved to the `Deref` target. For example, `foo.clone()`,
where `foo: Json<T>`, previously resolved to `<T as Clone>::clone()` but
now resolves to `<Json<T> as Clone>::clone()`.
'Missing' allows constructing a 'FileServer' even if the supplied path
does not exist. 'IndexFile' allows serving a single file as the index of
the mount path.
The syntax 'TypedStream![T + '_]' expands to:
impl TypedStream<Item = T> + '_
This allows seamlessly borrowing in typed streams.
Also adds 'Event::empty()', for convenience.
The improvements are:
* Point directly and immediately to the 'Responder' derive.
* Provide more discussion on lifetimes.
* Format documentation for easier scanning.
Previously, recursion into rewriting 'self' in field validations would
cease after the first function call. This meant that internal uses of
'self' were not properly rewritten. This commit ameliorates the
situation.
This allows responses to be sent to the client even when data is only
partially read, significantly improving the experience for the client
from one with a "connection closed" error to one with a proper response.
The consequence is a lifetime in 'Data'.
Though other non-lifetime-introducing solutions exist, the introduction
of a lifetime to 'Data' is a longstanding desire as it prevents
smuggling 'Data' into a longer-lived context. Use of 'Data' in that
context was unspecified with various runtime consequences. The addition
of a lifetime bound by the request prevents this error statically.
In summary, the changes are:
* Clients receive responses even when data isn't fully read.
* 'Data' becomes 'Data<'r>'. 'FromData' changes accordingly.
* Route 'Outcome's are strictly tied to the request lifetime.
Tangentially, the invalid length form field validation error message has
improved to format length in byte units if it exceeds 1024.
If stars aligned properly, we might imagine writing this:
#[non_exhaustive]
struct Config {
pub field: Foo,
pub other: Bar,
}
...with semantics that would allow the defining crate (here, Rocket), to
construct the structure directly while consumers would need to use
public constructors or struct update syntax:
Config {
field: Foo,
other: Bar,
..Default::default()
}
Alas, this is not the way `non_exhaustive` works on structs. You cannot
use field-update syntax to construct `Config` above. You must use public
constructors. This means builder methods or mutating an already built
struct. This is not what we want.
I don't know why it works this way. I don't see why it must. Something
something Drop.
So we have this hack from the pre-non_exhaustive era.