Implement normalize_lexically#134696
Conversation
|
rustbot has assigned @workingjubilee. Use |
rustbot
added
S-waiting-on-review
ChrisDenton
force-pushed
the
normalize-lexically
branch
2 times, most recently
from
c08079c to
8a3fb66
Compare
library/std/src/path.rs
Outdated
| Component::RootDir | Component::Prefix(_) => return Err(NormalizeError), | ||
| Component::CurDir => continue, | ||
| Component::ParentDir => { | ||
| if lexical.as_os_str().len() == root { | ||
| return Err(NormalizeError); |
There was a problem hiding this comment.
This is also a "should never happen" case, isn't it?
There was a problem hiding this comment.
Ah, I remember now. As per the RFC, we need to guard against popping from the path when there's nothing to pop. So a/../.. must error which is simple enough. But the complicating factor here is that base paths like C:\ are split by components as (Prefix, RootDir) whereas in reality you almost always want to treat C:\ as one unit. So it checks if popping would go above the root by just doing a length check. This handles whatever the "root" may be, e.g. C: (without the \) or whatever.
workingjubilee
added
S-waiting-on-author
|
☔ The latest upstream changes (presumably #136533) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Hmm. This wasn't supposed to get frozen on those two questions, so I'm just going to rebase this and approve it. If I think we maybe should call |
workingjubilee
force-pushed
the
normalize-lexically
branch
from
8a3fb66 to
2955213
Compare
This comment has been minimized.
This comment has been minimized.
|
ugh, the move of the tests breaks them because they relied on a struct expr |
ChrisDenton
force-pushed
the
normalize-lexically
branch
from
2955213 to
138d7ef
Compare
|
Sorry for the delay here, I've kept getting distracted by other things. I've rebased, fixed the tests and squished. |
ChrisDenton
force-pushed
the
normalize-lexically
branch
from
138d7ef to
79a1ef4
Compare
This comment has been minimized.
This comment has been minimized.
ChrisDenton
force-pushed
the
normalize-lexically
branch
2 times, most recently
from
6efb929 to
8788da1
Compare
|
☔ The latest upstream changes (presumably #141518) made this pull request unmergeable. Please resolve the merge conflicts. |
ChrisDenton
force-pushed
the
normalize-lexically
branch
from
8788da1 to
c299e29
Compare
|
@bors r+ |
bors
added
S-waiting-on-bors
|
@bors rollup |
…=workingjubilee Implement `normalize_lexically` Implements rust-lang#134694 This is, I think, the most straightforward implementation I could do, which will hopefully more easily allow experimentation if we decide to change the design here.
Rollup of 9 pull requests Successful merges: - #134696 (Implement `normalize_lexically`) - #138744 (Add methods to TCP and UDP sockets to modify hop limit (refresh of #94678)) - #140539 (Simplify `attribute_groups`) - #140863 ([rustdoc] Unify type aliases rendering with other ADT) - #140936 (Clarify WTF-8 safety docs) - #140952 (Specify that split_ascii_whitespace uses the same definition as is_ascii_whitespace) - #141472 (Attempt to improve the `std::fs::create_dir_all` docs related to atomicity) - #141502 (ci: move PR job x86_64-gnu-tools to codebuild) - #141559 (const-check: stop recommending the use of rustc_allow_const_fn_unstable) r? `@ghost` `@rustbot` modify labels: rollup
Rollup of 8 pull requests Successful merges: - #134696 (Implement `normalize_lexically`) - #140539 (Simplify `attribute_groups`) - #140863 ([rustdoc] Unify type aliases rendering with other ADT) - #140936 (Clarify WTF-8 safety docs) - #140952 (Specify that split_ascii_whitespace uses the same definition as is_ascii_whitespace) - #141472 (Attempt to improve the `std::fs::create_dir_all` docs related to atomicity) - #141502 (ci: move PR job x86_64-gnu-tools to codebuild) - #141559 (const-check: stop recommending the use of rustc_allow_const_fn_unstable) r? `@ghost` `@rustbot` modify labels: rollup
…=workingjubilee Implement `normalize_lexically` Implements rust-lang#134694 This is, I think, the most straightforward implementation I could do, which will hopefully more easily allow experimentation if we decide to change the design here.
6 participants
Implements #134694
This is, I think, the most straightforward implementation I could do, which will hopefully more easily allow experimentation if we decide to change the design here.