Skip to content

Conversation

salemtalha
Copy link
Contributor

this introduces a new field to the filestat struct which accounts for platform differences in time fields.

@emberian
Copy link
Contributor

r? @alexcrichton how are we handling platform differences such as this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think there's a "changed" field in the FileStat structure, does this compile?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wups, will fix.

@salemtalha
Copy link
Contributor Author

just tested on my machine, build was successful. the errors in the travis build are not due to me i believe. care to give it another look @alexcrichton?

@thestinger
Copy link
Contributor

There are Linux file systems with support for birth time, so it's not correct to stub it out like that.

@salemtalha
Copy link
Contributor Author

@thestinger can you point me to any? I've researched this fairly thorougly and it doesn't seem that there's a syscall that exposes birthtime as omasanori also pointed out here:

#15168 (comment)

I have, however, targetted bsd and mac os separately, as those do in fact support it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this field should be added just yet because windows doesn't support it and the structure of FileStat is that the top levels are "officially supported"

@alexcrichton
Copy link
Member

If neither created nor changed can be acquired in a platform-independent fashion at this time, then I don't think either field should make its way into the FileStat structure. The current created field should be removed as a [breaking-change] because it's not doing its job currently.

@alexcrichton
Copy link
Member

Closing due to inactivity, but feel free to reopen with my comments addressed!

lnicola pushed a commit to lnicola/rust that referenced this pull request Jun 23, 2024
…r=Veykril

Feat: hide double underscored symbols from symbol search

Fixes rust-lang#17272 by changing the default behavior of query to skip results that start with `__` (two underscores).

Not sure if this has any far reaching implications - a review would help to understand if this is the right place to do the filtering, and if it's fine to do it by default on the query.

If you type `__` as your search, then we'll show the matching double unders, just in case you actually need the symbol.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants