Arch: https://github.com/archlinux/svntogit-packages/tree/packages...
Alpine: https://git.alpinelinux.org/aports/tree/community/rust?h=mas...
FreeBSD: https://cgit.freebsd.org/ports/tree/lang/rust/files
Arch: https://github.com/archlinux/svntogit-packages/tree/packages...
Alpine: https://git.alpinelinux.org/aports/tree/community/rust?h=mas...
FreeBSD: https://cgit.freebsd.org/ports/tree/lang/rust/files
I don't think anything other than a Mozilla distribution would comply?
* Paths - distro don't need to keep path detection and can simplify it (ex: headers detections)
* Archs that upstream don't care about (ex: m86k).
* Kernel that upstream don't care about (kfreebsd)
* Some old CPU support. example: https://salsa.debian.org/rust-team/rust/-/blob/debian/sid/de...
* simplification of the build system (ex: skipping windows support)
* Use libraries provided by the system (ex: compiler-rt for rustc: https://salsa.debian.org/rust-team/rust/-/blob/debian/sid/de...). This could be forwarded upstream.
* Some minor doc changes - for example, https://salsa.debian.org/rust-team/rust/-/blob/debian/sid/de... will use the local css file and not a remote css file (for offline support)
* Cherry-pick upstream fixes before the next upstream release: https://salsa.debian.org/rust-team/rust/-/blob/debian/sid/de...
* etc
As you can see, these patches do not impact the quality of Rustc itself. Some could be forwarded upstream (it is a pain for packagers to maintain patches - so, we do have strong incentives to contribute upstream).