Add `std::fs::{Home|Media}Dirs` by CAD97 · Pull Request #158936 · rust-lang/rust

CAD97 · 2026-07-08T01:32:28Z

ACP: ACP: std::fs::UserDirs or similar libs-team#830

Replacement for std::os::unix::xdg as suggested by libs-api in #157515 (comment). Exposes media directories common between the three big OSes in addition to the cache/config/data/state directories under a separate feature gate. API summary:

// mod std::fs
pub struct HomeDirs { /* ... */ }
impl HomeDirs {
    fn empty() -> Self;

    pub fn config_home(&self) -> Option<&Path>;
    pub fn data_home(&self) -> Option<&Path>;
    pub fn state_home(&self) -> Option<&Path>;
    pub fn cache_home(&self) -> Option<&Path>;

    pub fn set_config_home(&mut self, path: PathBuf) -> &mut Self;
    pub fn set_data_home(&mut self, path: PathBuf) -> &mut Self;
    pub fn set_state_home(&mut self, path: PathBuf) -> &mut Self;
    pub fn set_cache_home(&mut self, path: PathBuf) -> &mut Self;
}

pub struct MediaDirs { /* ... */ }
impl MediaDirs {
    pub fn empty() -> Self;

    pub fn desktop(&self) -> Option<&Path>;
    pub fn documents(&self) -> Option<&Path>;
    pub fn downloads(&self) -> Option<&Path>;
    pub fn music(&self) -> Option<&Path>;
    pub fn pictures(&self) -> Option<&Path>;
    pub fn videos(&self) -> Option<&Path>;

    pub fn set_desktop(&mut self, path: PathBuf) -> &mut Self;
    pub fn set_documents(&mut self, path: PathBuf) -> &mut Self;
    pub fn set_downloads(&mut self, path: PathBuf) -> &mut Self;
    pub fn set_music(&mut self, path: PathBuf) -> &mut Self;
    pub fn set_pictures(&mut self, path: PathBuf) -> &mut Self;
    pub fn set_videos(&mut self, path: PathBuf) -> &mut Self;
}

// mod std::os::darwin::fs
impl HomeDirsExt for HomeDirs { /* ... */ }
pub impl(self) trait HomeDirsExt {
    fn sysdir() -> io::Result<Self>;
}

impl MediaDirsExt for MediaDirs { /* ... */ }
pub impl(self) trait MediaDirsExt {
    fn sysdir() -> io::Result<Self>;
}

// mod std::os::unix::fs
impl HomeDirsExt for HomeDirs { /* ... */ }
pub impl(self) trait HomeDirsExt {
    fn xdg() -> io::Result<Self>;

    fn runtime_home(&self) -> Option<&Path>;
    fn config_dirs(&self) -> Option<XdgDirs<'_>>;
    fn data_dirs(&self) -> Option<XdgDirs<'_>>;

    fn set_runtime_home(&mut self, path: PathBuf) -> &mut Self;
    fn set_config_dirs(&mut self, paths: OsString) -> &mut Self;
    fn set_data_dirs(&mut self, paths: OsString) -> &mut Self;
}

impl MediaDirsExt for MediaDirs { /* ... */ }
pub impl(self) trait MediaDirsExt {
    fn xdg() -> io::Result<Self>;

    fn templates(&self) -> Option<&Path>;
    fn set_templates(&mut self, path: PathBuf) -> &mut Self;
}

pub struct XdgDirs<'a> { /* ... */ }
impl Iterator for XdgDirs<'a> {
    type Item = &'a Path;
    /* ... */
}

// mod std::os::windows::fs
impl HomeDirsExt for HomeDirs { /* ... */ }
pub impl(self) trait HomeDirsExt {
    fn appdata_env() -> io::Result<Self>;
    fn known_folders() -> io::Result<Self>;
}

impl MediaDirsExt for MediaDirs { /* ... */ }
pub impl(self) trait MediaDirsExt {
    fn known_folders() -> io::Result<Self>;
}

Potentially outdated info

This implementation diverges from the directories crate's mapping in that we set state_dir in the non-unix constructors (to ~/Library/Application Support on Darwin and %APPDATA% on Windows). This mapping is derived from the idea that "state" files are application support files that are not important nor portable enough to the user to be "data" files.

The XDG paths are as described in the XDG Base Directories Specification and the xdg-user-dirs tool. $XDG_CONFIG_DIR/user-dirs.dirs is parsed directly to avoid delegating to potentially arbitrary shell execution.

The Darwin paths are loaded via the sysdir(3) API from libSystem.dylib (introduced in macOS 10.12 with a similar timeline for other Darwin OSes, deprecating the earlier NSSystemDirectories.h API). Using the File System Effectively points to preferring the Foundation framework's NSSearchPathForDirectoriesInDomain(_:_:_:) or NSFileManager.URLForDirectory instead, but calling those correctly requires an active Objective C autorelease pool, IIUC. The Library/Application Support directory is used for config_home, data_home, and state_home; the Apple documentation The Library Directory Stores App-Specific Files directly calls out placing data and configuration files in Library/Application Support, and state files are just less user-meaningful data files.

The Windows paths are loaded via the Known Folders API (introduced in Vista). config_home and data_home are placed in AppData\Roaming as files intended to be important and portable to the user, while cache_home and state_home are placed in AppData\Local as files that aren't.

I'm not fully confident about the handling of the XDG base directory paths which don't have good cross-platform analogs, as well as the exact API for the search path dealing functions, but I'm confident that the shape of the rest of the API does match the stdlib API style. Common paths are platform-independent enough of a needed concept to be exposed by std, IMHO, but platform-specific that a struct with public fields (even #[non_exhaustive]) seems incorrect, specifically because of platform-specific paths that we may want to expose like is already done for XDG.

The one API change I could see doing is moving state_dir into the XDG UserDirsExt. I chose not to do this for this initial implementation, though, as getting the ideal choice of fallback for both Darwin and Windows can't be achieved in an OS-agnostic way:

-	Darwin	Windows
cache	`~/Library/Caches`	`~/AppData/Local`
config	`~/Library/Application Support`	`~/AppData/Roaming`
data	`~/Library/Application Support`	`~/AppData/Roaming`
state	`~/Library/Application Support`	`~/AppData/Local`

A more drastic change would be to move all four onto the unix UserDirsExt, adding caches/application_support to the Darwin UserDirsExt and roaming_app_data/local_app_data to the Windows UserDirsExt. This would be more "correct" but seems a bit heavy-handed, as it would mean applications need to pull in OS-specific extension traits just to place their support files in something more appropriate than a ~/.appname directory.

We could also separate the "home" directory API from the "media" directory API. I'm neutral on this with one relevant note: the app-specific cache/config/data/state files need a subdirectory named after the application, so "ProjectDirs" would exclude the media directories; it could make sense to have a type with just those and a push_application_subdir method.

Switching the impl to using a pal imp::UserDirs could be reasonable, but seems at odds with the desire to have the target agnostic way to "build your own" UserDirs. An ExtraUserDirs instead of the #[allow(dead_code)] fields would make sense, I just didn't know how to best set up that in the pal layer.

Disclaimer: This was worked on as part of my employment at Canonical. I initially proposed it independently of my employment, but improving std's functionality is part of my job description, so Canonical told me I should use work time on it.

AI Disclosure: I did not use AI to generate any of the code, with a partial exception for VSCode's AI-assisted smart autocomplete helping with the repetitive parts of the code. All nontrivial code was handwritten. As an experiment, I did use some AI to assist in exploring the problem and API design spaces.

I tested locally on my Ubuntu developer machine, but am relying on CI for Darwin and Windows tests. 🤞

cc @joshtriplett @nia-e

madsmtm

Reviewed the Darwin parts.

calling those correctly requires an active Objective C autorelease pool, IIUC

Not that hard though, you can push and pop it with objc_autoreleasePoolPush/objc_autoreleasePoolPop. The bigger problem is that it requires linking Foundation, which has a startup cost we'd rather avoid.

This implementation diverges from the directories crate's mapping [...]

It seems to me that for something as nuanced as these user dirs (with a lot of platform-specific details that are not readily apparent), it might make sense to implement the desires std API in directories first? And once it stabilizes more there, we could upstream it to std?

View changes since this review

CAD97 · 2026-07-13T17:22:10Z

It seems to me that for something as nuanced as these user dirs (with a lot of platform-specific details that are not readily apparent), it might make sense to implement the desires std API in directories first?

This is mostly already the case. The only API-facing changes from directories here are:

Trimming the less cleanly portable API surface
Returning Option everywhere (requested by T-libs-api)
Setter methods for custom setups (requested by T-libs-api)
Explicit constructors for each convention (requested by T-libs-api)
Making state_dir fall back to what directories calls data_local_dir for non-XDG constructors
Combining UserDirs/BaseDirs (probably going to revert this)

The ideal API shape inside std and in a crate often differ slightly. This approved impl experiment is to determine if a form of this API that fits std's goals exists.

I'm going to split the base directory discovery and the user/media directories into different types to better represent that the existence of these sets is not strongly correlated and fix the things @madsmtm pointed out w.r.t. docs and the darwin impl, then this should be good for proper libs-api review.

The use of shlex for shell-unquote for the XDG user dirs needs a resolution, but doing the work to give shlex a rustc-dep-of-std feature can wait until we know whether that's the direction we want to take.

madsmtm

r=me on the Darwin impl now (haven't tested it this time around, but pretty sure CI will catch it if it doesn't work), thanks!

Don't have much of an opinion on the API design and the other platforms, I'll leave that to someone else.

View changes since this review

CAD97 · 2026-07-14T01:54:16Z

I consider this fully ready for review now.

r? @rust-lang/libs-api

Add `std::fs::{Home|Media}Dirs` - ACP: rust-lang/libs-team#830 Replacement for `std::os::unix::xdg` as suggested by libs-api in rust-lang#157515 (comment). Exposes media directories common between the three big OSes in addition to the cache/config/data/state directories under a separate feature gate. API summary: ```rust // mod std::fs pub struct HomeDirs { /* ... */ } impl HomeDirs { fn empty() -> Self; pub fn config_home(&self) -> Option<&Path>; pub fn data_home(&self) -> Option<&Path>; pub fn state_home(&self) -> Option<&Path>; pub fn cache_home(&self) -> Option<&Path>; pub fn set_config_home(&mut self, path: PathBuf) -> &mut Self; pub fn set_data_home(&mut self, path: PathBuf) -> &mut Self; pub fn set_state_home(&mut self, path: PathBuf) -> &mut Self; pub fn set_cache_home(&mut self, path: PathBuf) -> &mut Self; } pub struct MediaDirs { /* ... */ } impl MediaDirs { pub fn empty() -> Self; pub fn desktop(&self) -> Option<&Path>; pub fn documents(&self) -> Option<&Path>; pub fn downloads(&self) -> Option<&Path>; pub fn music(&self) -> Option<&Path>; pub fn pictures(&self) -> Option<&Path>; pub fn videos(&self) -> Option<&Path>; pub fn set_desktop(&mut self, path: PathBuf) -> &mut Self; pub fn set_documents(&mut self, path: PathBuf) -> &mut Self; pub fn set_downloads(&mut self, path: PathBuf) -> &mut Self; pub fn set_music(&mut self, path: PathBuf) -> &mut Self; pub fn set_pictures(&mut self, path: PathBuf) -> &mut Self; pub fn set_videos(&mut self, path: PathBuf) -> &mut Self; } // mod std::os::darwin::fs impl HomeDirsExt for HomeDirs { /* ... */ } pub impl(self) trait HomeDirsExt { fn sysdir() -> io::Result<Self>; } impl MediaDirsExt for MediaDirs { /* ... */ } pub impl(self) trait MediaDirsExt { fn sysdir() -> io::Result<Self>; } // mod std::os::unix::fs impl HomeDirsExt for HomeDirs { /* ... */ } pub impl(self) trait HomeDirsExt { fn xdg() -> io::Result<Self>; fn runtime_home(&self) -> Option<&Path>; fn config_dirs(&self) -> Option<XdgDirs<'_>>; fn data_dirs(&self) -> Option<XdgDirs<'_>>; fn set_runtime_home(&mut self, path: PathBuf) -> &mut Self; fn set_config_dirs(&mut self, paths: OsString) -> &mut Self; fn set_data_dirs(&mut self, paths: OsString) -> &mut Self; } impl MediaDirsExt for MediaDirs { /* ... */ } pub impl(self) trait MediaDirsExt { fn xdg() -> io::Result<Self>; fn templates(&self) -> Option<&Path>; fn set_templates(&mut self, path: PathBuf) -> &mut Self; } pub struct XdgDirs<'a> { /* ... */ } impl Iterator for XdgDirs<'a> { type Item = &'a Path; /* ... */ } // mod std::os::windows::fs impl HomeDirsExt for HomeDirs { /* ... */ } pub impl(self) trait HomeDirsExt { fn appdata_env() -> io::Result<Self>; fn known_folders() -> io::Result<Self>; } impl MediaDirsExt for MediaDirs { /* ... */ } pub impl(self) trait MediaDirsExt { fn known_folders() -> io::Result<Self>; } ```

…uwer Rollup of 5 pull requests Successful merges: - #158102 (When compiling without a specified `--edition`, emit a message) - #158936 (Add `std::fs::{Home|Media}Dirs`) - #163414 (Add support for span context to `derive(Diagnostic)` and use it) - #163405 (Remove some #[linkage] options) - #163498 (Revert "Rollup merge of #120589 - devnexen:cpuaff_fbsd_upd, r=clarfonthey")

Add `std::fs::{Home|Media}Dirs` - ACP: rust-lang/libs-team#830 Replacement for `std::os::unix::xdg` as suggested by libs-api in rust-lang#157515 (comment). Exposes media directories common between the three big OSes in addition to the cache/config/data/state directories under a separate feature gate. API summary: ```rust // mod std::fs pub struct HomeDirs { /* ... */ } impl HomeDirs { fn empty() -> Self; pub fn config_home(&self) -> Option<&Path>; pub fn data_home(&self) -> Option<&Path>; pub fn state_home(&self) -> Option<&Path>; pub fn cache_home(&self) -> Option<&Path>; pub fn set_config_home(&mut self, path: PathBuf) -> &mut Self; pub fn set_data_home(&mut self, path: PathBuf) -> &mut Self; pub fn set_state_home(&mut self, path: PathBuf) -> &mut Self; pub fn set_cache_home(&mut self, path: PathBuf) -> &mut Self; } pub struct MediaDirs { /* ... */ } impl MediaDirs { pub fn empty() -> Self; pub fn desktop(&self) -> Option<&Path>; pub fn documents(&self) -> Option<&Path>; pub fn downloads(&self) -> Option<&Path>; pub fn music(&self) -> Option<&Path>; pub fn pictures(&self) -> Option<&Path>; pub fn videos(&self) -> Option<&Path>; pub fn set_desktop(&mut self, path: PathBuf) -> &mut Self; pub fn set_documents(&mut self, path: PathBuf) -> &mut Self; pub fn set_downloads(&mut self, path: PathBuf) -> &mut Self; pub fn set_music(&mut self, path: PathBuf) -> &mut Self; pub fn set_pictures(&mut self, path: PathBuf) -> &mut Self; pub fn set_videos(&mut self, path: PathBuf) -> &mut Self; } // mod std::os::darwin::fs impl HomeDirsExt for HomeDirs { /* ... */ } pub impl(self) trait HomeDirsExt { fn sysdir() -> io::Result<Self>; } impl MediaDirsExt for MediaDirs { /* ... */ } pub impl(self) trait MediaDirsExt { fn sysdir() -> io::Result<Self>; } // mod std::os::unix::fs impl HomeDirsExt for HomeDirs { /* ... */ } pub impl(self) trait HomeDirsExt { fn xdg() -> io::Result<Self>; fn runtime_home(&self) -> Option<&Path>; fn config_dirs(&self) -> Option<XdgDirs<'_>>; fn data_dirs(&self) -> Option<XdgDirs<'_>>; fn set_runtime_home(&mut self, path: PathBuf) -> &mut Self; fn set_config_dirs(&mut self, paths: OsString) -> &mut Self; fn set_data_dirs(&mut self, paths: OsString) -> &mut Self; } impl MediaDirsExt for MediaDirs { /* ... */ } pub impl(self) trait MediaDirsExt { fn xdg() -> io::Result<Self>; fn templates(&self) -> Option<&Path>; fn set_templates(&mut self, path: PathBuf) -> &mut Self; } pub struct XdgDirs<'a> { /* ... */ } impl Iterator for XdgDirs<'a> { type Item = &'a Path; /* ... */ } // mod std::os::windows::fs impl HomeDirsExt for HomeDirs { /* ... */ } pub impl(self) trait HomeDirsExt { fn appdata_env() -> io::Result<Self>; fn known_folders() -> io::Result<Self>; } impl MediaDirsExt for MediaDirs { /* ... */ } pub impl(self) trait MediaDirsExt { fn known_folders() -> io::Result<Self>; } ```

Rollup of 8 pull requests Successful merges: - #158102 (When compiling without a specified `--edition`, emit a message) - #158936 (Add `std::fs::{Home|Media}Dirs`) - #163414 (Add support for span context to `derive(Diagnostic)` and use it) - #163481 (triagebot: use r-l/r zulip linkifier for r-l/r rustfmt backport nominations) - #163502 (arch::breakpoint: update docs) - #163505 (Sync cg_gcc subtree 2026-09-29) - #163405 (Remove some #[linkage] options) - #163498 (Revert "Rollup merge of #120589 - devnexen:cpuaff_fbsd_upd, r=clarfonthey")

Add `std::fs::{Home|Media}Dirs` - ACP: rust-lang/libs-team#830 Replacement for `std::os::unix::xdg` as suggested by libs-api in rust-lang#157515 (comment). Exposes media directories common between the three big OSes in addition to the cache/config/data/state directories under a separate feature gate. API summary: ```rust // mod std::fs pub struct HomeDirs { /* ... */ } impl HomeDirs { fn empty() -> Self; pub fn config_home(&self) -> Option<&Path>; pub fn data_home(&self) -> Option<&Path>; pub fn state_home(&self) -> Option<&Path>; pub fn cache_home(&self) -> Option<&Path>; pub fn set_config_home(&mut self, path: PathBuf) -> &mut Self; pub fn set_data_home(&mut self, path: PathBuf) -> &mut Self; pub fn set_state_home(&mut self, path: PathBuf) -> &mut Self; pub fn set_cache_home(&mut self, path: PathBuf) -> &mut Self; } pub struct MediaDirs { /* ... */ } impl MediaDirs { pub fn empty() -> Self; pub fn desktop(&self) -> Option<&Path>; pub fn documents(&self) -> Option<&Path>; pub fn downloads(&self) -> Option<&Path>; pub fn music(&self) -> Option<&Path>; pub fn pictures(&self) -> Option<&Path>; pub fn videos(&self) -> Option<&Path>; pub fn set_desktop(&mut self, path: PathBuf) -> &mut Self; pub fn set_documents(&mut self, path: PathBuf) -> &mut Self; pub fn set_downloads(&mut self, path: PathBuf) -> &mut Self; pub fn set_music(&mut self, path: PathBuf) -> &mut Self; pub fn set_pictures(&mut self, path: PathBuf) -> &mut Self; pub fn set_videos(&mut self, path: PathBuf) -> &mut Self; } // mod std::os::darwin::fs impl HomeDirsExt for HomeDirs { /* ... */ } pub impl(self) trait HomeDirsExt { fn sysdir() -> io::Result<Self>; } impl MediaDirsExt for MediaDirs { /* ... */ } pub impl(self) trait MediaDirsExt { fn sysdir() -> io::Result<Self>; } // mod std::os::unix::fs impl HomeDirsExt for HomeDirs { /* ... */ } pub impl(self) trait HomeDirsExt { fn xdg() -> io::Result<Self>; fn runtime_home(&self) -> Option<&Path>; fn config_dirs(&self) -> Option<XdgDirs<'_>>; fn data_dirs(&self) -> Option<XdgDirs<'_>>; fn set_runtime_home(&mut self, path: PathBuf) -> &mut Self; fn set_config_dirs(&mut self, paths: OsString) -> &mut Self; fn set_data_dirs(&mut self, paths: OsString) -> &mut Self; } impl MediaDirsExt for MediaDirs { /* ... */ } pub impl(self) trait MediaDirsExt { fn xdg() -> io::Result<Self>; fn templates(&self) -> Option<&Path>; fn set_templates(&mut self, path: PathBuf) -> &mut Self; } pub struct XdgDirs<'a> { /* ... */ } impl Iterator for XdgDirs<'a> { type Item = &'a Path; /* ... */ } // mod std::os::windows::fs impl HomeDirsExt for HomeDirs { /* ... */ } pub impl(self) trait HomeDirsExt { fn appdata_env() -> io::Result<Self>; fn known_folders() -> io::Result<Self>; } impl MediaDirsExt for MediaDirs { /* ... */ } pub impl(self) trait MediaDirsExt { fn known_folders() -> io::Result<Self>; } ```

Rollup of 7 pull requests Successful merges: - #158936 (Add `std::fs::{Home|Media}Dirs`) - #163414 (Add support for span context to `derive(Diagnostic)` and use it) - #163481 (triagebot: use r-l/r zulip linkifier for r-l/r rustfmt backport nominations) - #163502 (arch::breakpoint: update docs) - #163505 (Sync cg_gcc subtree 2026-09-29) - #163405 (Remove some #[linkage] options) - #163498 (Revert "Rollup merge of #120589 - devnexen:cpuaff_fbsd_upd, r=clarfonthey")

Rollup of 6 pull requests Successful merges: - #158936 (Add `std::fs::{Home|Media}Dirs`) - #163414 (Add support for span context to `derive(Diagnostic)` and use it) - #163481 (triagebot: use r-l/r zulip linkifier for r-l/r rustfmt backport nominations) - #163502 (arch::breakpoint: update docs) - #163505 (Sync cg_gcc subtree 2026-09-29) - #163498 (Revert "Rollup merge of #120589 - devnexen:cpuaff_fbsd_upd, r=clarfonthey")

rust-timer · 2026-09-30T17:47:58Z

Note

This PR was benchmarked as part of triage of its containing rollup: triage URL.

Finished benchmarking commit (f58b305): comparison URL.

Overall result: ❌ regressions - please read:

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

If the regression was expected or you think it can be justified,
please write a comment with sufficient written justification, and add
@rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
If you think that you know of a way to resolve the regression, try to create
a new PR with a fix for the regression.
If you do not understand the regression or you think that it is just noise,
you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.7%	[0.3%, 1.0%]	6
Regressions ❌ (secondary)	0.5%	[0.2%, 0.9%]	20
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.7%	[0.3%, 1.0%]	6

Max RSS (memory usage)

Results (secondary -2.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.2%	[-2.2%, -2.2%]	1
All ❌✅ (primary)	-	-	0

Cycles

This perf run didn't have relevant results for this metric.

Binary size

Results (primary 1.2%, secondary 1.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	1.2%	[0.4%, 2.0%]	8
Regressions ❌ (secondary)	1.2%	[0.4%, 2.0%]	32
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.2%	[0.4%, 2.0%]	8

Bootstrap: missing data
Artifact size: 406.44 MiB -> 406.55 MiB (0.03%)

JonathanBrouwer · 2026-09-30T19:28:45Z

This PR caused a significant perf regression, this seems to be unexpected.
Any idea what caused this?

CAD97 · 2026-09-30T19:29:41Z

If the regressions aren't spurious, it's probably due to the new #[define_opaque] in sys::paths::unix. I suspect this to be just code movement noise, however; no existing code was changed, only new code added to std.

JonathanBrouwer · 2026-09-30T19:33:33Z

From looking at the profiling results, the extra cost seems to be concentrated in run_linker.
It is mostly the smaller benchmarks that changed.
Did this PR increase the size of std so much that linking it became slower?

CAD97 · 2026-09-30T19:40:16Z

I'm completely lost as to how this could have caused the regression; I'll leave figuring that out to the perf WG. Though I will submit a quick PR to remove that spurious cfg_select! arm.

JonathanBrouwer · 2026-09-30T20:23:36Z

Before this PR, libstd.rlib (for x86_64-unknown-linux-gnu) was 11.7MiB, after this PR it is now 12.1MiB.
This is a 3.4% increase, I think that is most likely the cause of the regression since profiling shows the extra cost to be in run_linker.
This PR doesn't add that much code, I wonder what caused std to grow so much.

CAD97 · 2026-09-30T20:26:45Z

Opened #163569 to test the hypothesis of #[define_opaque] contributing.

Random thought: on Windows, this newly links to LoadLibraryExA from kernel32.dll. Might the linker have to do more work when dynamic linking symbols are linked in?

tgross35 · 2026-09-30T20:26:35Z

+#[cfg(test)]
+mod tests {


Isn't tidy supposed to reject same-file mod tests?

JonathanBrouwer · 2026-09-30T20:29:25Z

on Windows, this newly links to LoadLibraryExA from kernel32.dll. Might the linker have to do more work when dynamic linking symbols are linked in?

rust-timer only shows x86_64-unknown-linux-gnu results atm, so that should not be relevant
(though it also benchmarks aarch64-unknown-linux-gnu now, yay)

panstromek · 2026-10-01T09:01:51Z

This is a 3.4% increase, I think that is most likely the cause of the regression

This definitely looks like std size problem. Apart from linking, there are other clues as well: More time/count in metadata decoding, more query key hashing, larger query cache and the binary sizes are bigger, too.

serde doc regression is a bit surprising, that doesn't fit the pattern.

lqd · 2026-10-05T12:48:11Z

This PR doesn't add that much code, I wonder what caused std to grow so much.

Did you see if it was the docs? (the doc comments should still be stored in the rmeta, I don't believe we managed to remove them yet).