A bit more explanation, this is the old output:

note: tuple variant defined here
   --> /wrkdirs/usr/ports/lang/rust/work/rustc-1.77.0-src/library/core/src/result.rs:506:5
help: you can convert an `i64` to a `u64` and panic if the converted value doesn't fit

And the new output for the same error:

note: tuple variant defined here
   --> /usr/local/lib/rustlib/src/rust/library/core/src/result.rs:506:5
    |
506 |     Ok(#[stable(feature = "rust1", since = "1.0.0")] T),
    |     ^^
help: you can convert an `i64` to a `u64` and panic if the converted value doesn't fit

In D42432#968666, @rmacklem wrote:

It looks ok to me now. Do you have a commit bit?
(If not, I can commit it.)

Added requested strnvis error checking.

Neat. I should have looked at Phabricator before I created D42432. I think they should be considered together. And the patched version of zfs (I haven't looked, of course), should also consider special characters in mount point names if it doesn't.

Specifically, it caused options to be omitted from entries created after the TPM device option:

Include example export entry with spaces

Updated the exports(5) manual page.

Hm. Missed updating the documentation. I'll update that too.

This looks good to me. It's more clear than my proposal of just force-enabling it, and looks like it's something that can be pushed upstream.

In D37007#907380, @bofh wrote:

When there are two different MAINTAINER you should create two different reviews.

Update to latest main

This is good, but it doesn't match what Linux does. Both systemd and dbus generate 32 character UUID strings, while this creates 36 character ones.

Thanks for taking a look. I don't think the change to the 3.19 port is strictly necessary, but as I said in a private email to @mfechner, I do believe that hiding symbols is good practice for ruby gems.

Also created this pull request.

There are a few more, mostly to do with generated files containing full paths that escape. They're coming too.

This is a large portion of the userland changes to give consistent debug data path data no matter the source or object directories. There are more reviews coming.

Thanks for the review. I'm not a committer, so I can't submit it myself.

Thank you so much for this. I thought of doing it myself.

Update for the one minor change left after 80f31432743446a1e8e4f8cb8268b74ac4e4f2da

In D28596#640302, @jkim wrote:

Please see the following commits.

https://cgit.freebsd.org/src/commit/?id=34e67bb5977049afb3e965b52b86ac12ea4899b4
https://cgit.freebsd.org/src/commit/?id=80f31432743446a1e8e4f8cb8268b74ac4e4f2da
https://cgit.freebsd.org/src/commit/?id=bf80e08ed5ed32bbfd50674c01f8a0e519133e17

Don't update bootstrap version requirement.

In D28596#640192, @jkim wrote:

BTW, initparse.c and initparse.h were generated with yacc. Therefore, it is technically "regen after byacc 20200330 (r363170)".

In D28596#640180, @jkim wrote:

I still don't like to change the bootstrap requirement. Other than that, it looks good to me.

Restore NULL check style.

In D28596#640171, @jkim wrote:

There is no need to change bootstrap requirement because the old lex can build head just fine AFAICT. Although it's nice to update the generated files, I don't see any functional changes between two.

Point Phabricator at the right files..

Commit r314671 is pretty much this change.

It may well be a false positive, though I suspect that this warning is given for any pointer access to a member of a packed structure. This wasn't the only warning of its kind I saw, just the only warning where WARNS wasn't already set to 3 or lower.

Yes, the checking against MK_ZFS and changing the #define to HAVE_ZFS makes this work with WITHOUT_ZFS. Looks good to me.