The old slice was doing several things at the same time: demonstrating
both external functions as well as unsafe Rust functions.
We now treat those two topics separately. In addition, the “Calling
Unsafe Functions” heading has become its own slide with a non-crashing
example that shows what can go wrong if an argument is misunderstood
in a call to an unsafe function. The old example didn’t actually
illustrate the danger clearly: it would produce mangled UTF-8 output,
which the Playground server refuses to print.
Part of #2445.
---------
Co-authored-by: Dustin J. Mitchell <djmitche@google.com>
Co-authored-by: Andrew Walbran <qwandor@google.com>
It's generally more idiomatic in Rust to not have trait bounds on the
data type itself. I think we better demonstrate how trait bounds are
used in impl blocks with generic data types in the impl block below the
struct definition. I've also added a speaker note to call this out if
students ask.
Bumps the minor group in /src/exercises/bare-metal/rtc with 1 update:
[bitflags](https://github.com/bitflags/bitflags).
Updates `bitflags` from 2.6.0 to 2.8.0
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps the minor group in /src/bare-metal/aps/examples with 1 update:
[bitflags](https://github.com/bitflags/bitflags).
Updates `bitflags` from 2.6.0 to 2.8.0
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
The "Generic Data Types" slide now uses trait bounds, which makes it
very confusing to explain. (e.g., "ignore this trait bound stuff while I
explain why we need to stutter to describe the generic args on an impl
block").
Also in the "Generic Functions" slide, the speaker notes talks about how
we essentially need to treat the generic args as black boxes - this is
probably more important to address then talking about all the ways you
can make things generic.
I suppose my `svgbob` skills leave a bit to be desired, but I think the
meaning is clear:
Now that I look through the `Rc` implementation, there's a weak count
for every strong count, so the `weak: 0` here is inaccurate. But, maybe
this is too much of an implementation detail? Should I just concentrate
on strong refs? I suppose I could put a `...` in that upper-right box,
to suggest there's more going on here?
This slide had two code samples, neither of which had a `main` and thus
neither of which would run. This removes the first (which is redundant
to one a few slides earlier), adds a `main`, and expands the second to
use a 3-tuple.
When teaching the course, I got a little tripped up thinking students
would need to make the `VerbosityFilter` generic over `Logger`. Let's be
clearer that this is not required, and will be described later.
This also updates the generic-types slide to repeat the exercise,
completing that thought.
In teaching the course, the verbal distinction between "doc" and "dog"
was not clear, so this PR moves away from those symbols.
This also makes the Highlight struct a little more substantial, and
replaces `erase` with a simple call to `drop` to keep the example short.
In teaching the course last week, we broke here, partly due to time
constraints, but partly because this is a pretty mind-bending topic to
tackle at the end of an information-dense day. A break helps, and
spreading the content over a few slides helps as well.
By the timings in the course, this leaves day 2 looking like
*Fundamentals // Day 2 Morning*
_1 hour and 55 minutes: (1 hour and 10 minutes short)_
* Welcome - _3 minutes_
* Pattern Matching - _45 minutes_
* Methods and Traits - _50 minutes_
*Fundamentals // Day 2 Afternoon*
_3 hours and 30 minutes (⏰ *30 minutes too long*)_
* Welcome - _0 minutes_
* Generics - _45 minutes_
* Standard Library Types - _1 hour_
* Standard Library Traits - _1 hour_
* Closures - _20 minutes_
Maybe we should move generics to the morning session?
This is done in the speaker notes as it's a relatively minor point, but
one that students should have in the back of their mind when they
wonder, "hey, how does a `&Foo` match against `Foo` patterns??"
These sort of warnings can be distracting when commenting out a few
lines of code or demonstrating some other concept. They can be
re-enabled for a code block with `warnunused`.
I filed https://github.com/rust-lang/mdBook/issues/2527 to get behavior
like this upstream.
These are some minor updates from walking through the session myself.
* Add some context to the `entry.S` slide, which is otherwise a bit
terrifying for someone who does not speak ARM assembly.
* Include a simple, fake example of MMIO.
* Add a "Using It" section to the minimal UART segment, parallel to the
better UART
* Better explanation of the `unwrap` calls in the logging example.
Unwrap is never "unsafe", so remove that word.
* Allow dead code in some `.rs` files.
* Remove redundant warning about use of memory before MMU setup.
* Rephase text about buddy-system
* Fix lint warning in spin slide.
The custom function `cap` does the same as `Ord::clamp`, which was
introduced in Rust 1.50. Let's use the latter instead.
I've flashed the new program onto my microbit and can confirm it still
works as intended.
Bumps the patch group in /src/bare-metal/aps/examples with 1 update:
[cc](https://github.com/rust-lang/cc-rs).
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
The current example demonstrating how rustc prevents dangling references
is really gross and hard to read (my own fault lol, I wrote that
example). I finally realized that there's a much simpler, easier to read
way of expressing the same thing. I also moved this to its own slide
after the reference slides so that we can call it out as an early
example of the borrow checker. I then call back to this example in the
borrow checker slide to remind students that the aliasing rule isn't the
only thing the borrow checker is enforcing.
The side bar is out of date, and also the the unit testing docs are
talking about integration tests. These tests are discussed on the next
slide in "Other Types of Tests".
