I've been thinking it'd be simpler to introduce `dyn Trait` via `&dyn
Trait` rather than waiting for the smart pointers section and `Box<dyn
Trait>`. This PR adds a slide to the Generics section that introduces
`&dyn Trait` and compares it to `&impl Trait`, juxtaposing
monomorphization and static dispatch against type-erasure and dynamic
dispatch. I've then updated the existing trait object slide to call back
to the earlier introduction, and call out that using `Box<dyn Trait>`
gives you an owned trait object rather than a borrowed one.
As I mentioned in #1536:
* Break into segments at approximately the places @fw-immunant put
breaks
* Move all of the files into `src/concurrency`
* Add timings and segment/session metadata so course outlines appear
There's room for more work here, including some additional feedback from
@fw-immunant after the session I observed, but let's do one step at a
time :)
I think it'd be helpful to actually demonstrate to students how the
"sharing XOR mutability" rule actually prevents errors in practice,
since right now we explain the rule but don't give much context as to
why the rule is important.
This PR moves the slides for slices and strings into the day 1 section
on references. This seems like the more natural place to introduce
slices since slices are a type of reference. It then also made sense to
me to follow that with the introduction of `&str` and `String`, since
students now have the context to understand what a "string slice" is. I
also removed the strings slide from the types and values section since
it didn't make sense to cover the same topic twice in the same day. I
tested this new organization in my class on Wednesday and it didn't
cause day 1 to take too long.
After #1528 and #1532, we now have actual slides which showcase the
crates in action. So we can reclaim a few minutes by removing the slide
which mentions Mockall and GoogleTest slide.
The slide mentioned [proptest](https://docs.rs/proptest) and
[rstest](https://docs.rs/rstest) as well. While I'm sure the libraries
are useful, we don't have them imported into AOSP and I've never
personally used them. We should therefore not advertise them yet at this
point since they won't be useful to Android engineers.
Of course we can mention things that are not in AOSP (or in Chromium),
but I think we should do it in the speaker notes at most.
The current location for the hello world example is awkward since the
two surrounding pages are both talking about Rust from a high level
without talking about syntax at all. I think starting the second section
(types and values) with the hello world example would help the first
section flow more smoothly.
This breaks the "Traits" slide into three smaller sub-slides. It also
addresses part of #1511 by explicitly addressing associated types.
---------
Co-authored-by: Martin Geisler <martin@geisler.net>
This should be a bit simpler, and notably
* does not require trait objects, which per #1516 should be moved later
in the course
* does not require a lot of futzing with string formatting
But all that hard work developing the GUI exercise is not for naught: it
remains in the "Modules" segment, where students will get a chance to
read some Rust code and reorganize it a little bit.
Fixes#1617.
R=mgeisler as the original author of the GUI exercise.
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.
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).
With the latest version of mdbook-i18n-helpers, we now have support for
formatting in the `SUMMARY.md` file. This allows us to revert the
changes made in #130 when we first introduced the translation support.
This also aligns a few headings to match the heading in the outline.
While this isn’t strictly necessary, it removes a bit of work for the
translators.
As more and more Android teams start using Rust, the question of "How to do mocking?" has come up more frequently. Right now, we don't have a good answer to those teams, AOSP doesn't have any mocking framework available. That will change soon with the import of Mockall and this slide is part of the supporting documentation that we can point teams to.
I've taken some work by @fw-immunant and others on the new organization
of the course and condensed it into a form amenable to a text editor and
some computational analysis. You can see the inputs in `course.py` but
the interesting bits are the output: `outline.md` and `slides.md`.
The idea is to break the course into more, smaller segments with
exercises at the ends and breaks in between. So `outline.md` lists the
segments, their duration, and sums those durations up per-day. It shows
we're about an hour too long right now! There are more details of the
segments in `slides.md`, or you can see mostly the same stuff in
`course.py`.
This now contains all of the content from the v1 course, ensuring both
that we've covered everything and that we'll have somewhere to redirect
every page.
Fixes#1082.
Fixes#1465.
---------
Co-authored-by: Nicole LeGare <dlegare.1001@gmail.com>
Co-authored-by: Martin Geisler <mgeisler@google.com>
This is a contribution of a Chromium section for Comprehensive Rust.
---------
Co-authored-by: Nicole L <dlegare.1001@gmail.com>
Co-authored-by: Martin Geisler <martin@geisler.net>
Add a number of slides that cover most of CXX's functionality and
demonstrate how it can be used.
Fixes#823.
---------
Co-authored-by: Martin Geisler <mgeisler@google.com>
The goal of this is twofold: give translators a place to document how
certain terms are translated as well as giving people a place to quickly
find a definition of a term. The slides might not always give a quick
definition the same way a glossary can.
This example shows what kind of bugs easily slip into C code and are
made impossible via Rust.
I have created this example for the motivation slides of my master
thesis. Since then, the university institute has used it in their
introduction to Rust.
I hereby make this part available to the Comprehensive Rust course and
relicense it under the terms of the Apache 2.0 license.
Thank you @mgeisler for your invitation to contribute to this course!
---------
Co-authored-by: Martin Geisler <martin@geisler.net>
This is a follow-up to #998 and the discussion in #1049. The
comparison page is now gone: like @randomPoison said, it feels
redundant and I also mostly skip over it when teaching the class.
I also took out some duplication in the Rust memory management page. I
would be up for simplifying the whole chapter down to one or two
slides as @djmitche suggests: that would leave us with more time for
covering ownership.
- Morning of Day 1 still introduces the language and its high-level
goals/value proposition, and starts with the built-in data types Rust
provides, and how you define a function.
- Afternoon of Day 1 gets a front loading of the basic control flow
structures in Rust but not the more exotic ones.
- The exercises for day 1 afternoon will be the Luhn algorithm (where we
can match on digits and enums such as `Option`.
- Morning of day 2 still has discussion of memory management.
Fixes#510.
---------
Co-authored-by: Martin Geisler <mgeisler@google.com>
When building the book, mdBook will always generate an `index.html`
page for first page of the book. This meant that we had the same
content available under two different names:
- `welcome.html`: this is what the TOC would link to, and
- `index.html` or simply `/`: this is what search engines link to
Renaming the page and setting up a redirect should fix this confusion.
We still don’t have a good way of avoiding links to the `index.html`
page, but this should fix the first half of the problem.
I tested this for translations as well by building the output in a
subdirectory and serving the parent directory.
Part of #847.
rename 'designing a library' example
library design in Rust is its own topic that this course does not cover; to avoid confusion, let's stick to describing things in terms of books
