This is the result of running `dprint fmt` after removing `src/` from
the list of excluded directories.
This also reformats the Rust code: we might want to tweak this a bit in
the future since some of the changes removes the hand-formatting. Of
course, this formatting can be seen as a mis-feature, so maybe this is
good overall.
Thanks to mdbook-i18n-helpers 0.2, the POT file is nearly unchanged
after this, meaning that all existing translations remain valid! A few
messages were changed because of stray whitespace characters:
msgid ""
"Slices always borrow from another object. In this example, `a` has to remain "
-"'alive' (in scope) for at least as long as our slice. "
+"'alive' (in scope) for at least as long as our slice."
msgstr ""
The formatting is enforced in CI and we will have to see how annoying
this is in practice for the many contributors. If it becomes annoying,
we should look into fixing dprint/check#11 so that `dprint` can annotate
the lines that need fixing directly, then I think we can consider more
strict formatting checks.
I added more customization to `rustfmt.toml`. This is to better emulate
the dense style used in the course:
- `max_width = 85` allows lines to take up the full width available in
our code blocks (when taking margins and the line numbers into account).
- `wrap_comments = true` ensures that we don't show very long comments
in the code examples. I edited some comments to shorten them and avoid
unnecessary line breaks — please trim other unnecessarily long comments
when you see them! Remember we're writing code for slides 😄
- `use_small_heuristics = "Max"` allows for things like struct literals
and if-statements to take up the full line width configured above.
The formatting settings apply to all our Rust code right now — I think
we could improve this with https://github.com/dprint/dprint/issues/711
which lets us add per-directory `dprint` configuration files. However,
the `inherit: true` setting is not yet implemented (as far as I can
tell), so a nested configuration file will have to copy most or all of
the top-level file.
```
$ adb shell /data/local/tmp/hello_rust_with_dep
CANNOT LINK EXECUTABLE "/data/local/tmp/hello_rust_with_dep": library "libtextwrap.dylib.so" not found: needed by main executable
```
```
error: unsafe block missing a safety comment
--> interoperability/bindgen/main.rs:11:5
|
11 | unsafe {
| ^^^^^^^^
|
= help: consider adding a safety comment on the preceding line
= help: for further information visit https://rust-lang.github.io/rust-clippy
/master/index.html#undocumented_unsafe_blocks
= note: requested on the command line with `-D clippy::undocumented-unsafe-bl
ocks`
```
It's clear from the above text and example that the error type returned
by the outer function (`Err` in this case) must implement the `From`
trait to accept the error returned by the inner function (`OtherErr` in
this case).
Currently, `BinaryTree::has` takes its argument by value. This is a
pretty unrealistic API for a Rust library. Let's fix this and take the
argument by reference instead.
In https://github.com/google/comprehensive-rust/pull/1591, I changed the
implementation of the protobuf example significantly. However, I forgot
to update a comment which is referred to the old style of
implementation. I'll this slip here.
The solution to the modules exercise comes with a bunch of files. I
think it would help the students to get a quick overview of the
directory structure we've chosen first.
Explain what traits `thiserror::Error` derives.
Explain how `.context()` and `.with_context()` operate on types that are
not aware of `anyhow`.
Resolves#1597.
`let Some(x) = E else { return None; }` is equivalent to
`let Some(x) = E?`. That latter is shorter and more idiomatic, so let's
use that.
A pattern of the form `c @ P1 | c @ P1` has the disadvantage that the
name `c` is repeated. Let's replace it with `c @ (P1 | P2)`.
An `x: Option<Result<T, E>>` can be handled more succinctly with
`x.ok_or(...)??`.
This is a suggestion for how we could make the protobuf exercise at the
end of day 3 better.
Generally speaking, the idea is to parse the protbuf bytes into data
types instead of only printing the parsing outcome to the console. To
make this a little more realistic, we also introduce a trait
`ProtoMessage` for message types.
I think this is more instructive than the current example. In
particular, we get to mess around with lifetimes. This might be a little
more complicated but can be a great opportunity for the students to tie
together different things they've learnt in the course so far.
What do you all think?
This modifies the exercise to lean more into interesting `match`
statements. It also uses the standard `Result` type, based on feedback
that students could understand it sufficiently at this point in the
course.
Addresses #1565.
`Ok(x?)` has the same outcome as `x` and save an unpacking/repacking
cycle.
`x as usize` has no effect when `x` already has type `usize`.
In `x < 4usize` the `usize` is unnecessary when `x` already has type
`usize`.
Currently, the implementation uses if-then-else chains and `<` and `>`.
This is not the most idiomatic Rust. Instead, we can use `cmp` and
`match` to make the code easier to read.
---------
Co-authored-by: Dustin J. Mitchell <djmitche@google.com>
People are often confused by this: the fact that we can remove the `*`
in the `println!()` is not because the compiler auto-derefs here (it
does not), but because `Display` is implemented for `&T where T:
Display` (a blanket implementation).
Speaker notes for Chromium's third-party crate exercise list the
transitive dependencies that will be downloaded during the exercise.
Before this commit the list was missing the `redox_syscall` crate.
Additionally, the commit sorts the crates to make it easier to compare
with the output of `git status` or `ls`.
---------
Co-authored-by: Martin Geisler <martin@geisler.net>
I don't like shortening words, so I prefer "Documentation" over "Docs".
I find this less jargony and thus easier to read (and potentially also
easier to translate).
This takes out the huge example with lots of macro magic. I don't think
we need it for an introductory course.
I also cleaned up the formatting a little and made sure to distinguish
between types and values.
---------
Co-authored-by: Dustin J. Mitchell <djmitche@google.com>
If we use a type annotation, we get around explaining the turbo fish,
which isn't trivial without having introduced generics. Type
annotations on the other hand are known already.
