Skip to content

Implement bitwise operator traits for ints and uints - #5935

Closed
brendanzab wants to merge 3 commits into
rust-lang:incomingfrom
brendanzab:master
Closed

Implement bitwise operator traits for ints and uints#5935
brendanzab wants to merge 3 commits into
rust-lang:incomingfrom
brendanzab:master

Conversation

@brendanzab

Copy link
Copy Markdown
Contributor

No description provided.

Comment threadsrc/libcore/num/int-template.rs Outdated

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

these could be assert_eq! now

bors added a commit that referenced this pull request Apr 18, 2013
@borsbors closed this Apr 18, 2013
flip1995 pushed a commit to flip1995/rust that referenced this pull request Aug 28, 2020
…flip1995
stable_sort_primitive: print the type that is being sorted in the lint message
changelog: stable_sort_primitive: print the type that is being sorted in the lint message
U007D pushed a commit to U007D/rust-mos that referenced this pull request Aug 21, 2026
5935: Rewrite import insertion r=matklad a=Veykril
This is my attempt at refactoring the import insertion rust-lang#3947. I hope what I created here is somewhat in line with what was requested, it wouldn't surprise me .
`common_prefix` is a copy from `merge_imports.rs` so those should be unified somewhere, `try_merge_trees` is also copied from there but slighly modified to take the `MergeBehaviour` enum into account.
`MergeBehaviour` should in the end become a configuration option, and the order if `ImportGroup` probably as well?
I'm not too familiar with the assist stuff and the like which is why I dont know what i have to do with `insert_use_statement` and `find_insert_use_container` for now.
I will most likely add more test cases in the end as well as I currently only tried to hit every path in `find_insert_position`. Some of the merge tests also fail atm due to them not sorting what they insert. There is also this test case I'm not sure if we want to support it. I would assume we want to? https://github.com/rust-analyzer/rust-analyzer/pull/5935/files#diff-6923916dd8bdd2f1ab4b984adacd265fR540-R547
The entire module was rewritten so looking at the the file itself is probably better than looking at the diff.
Regarding the sub issues of rust-lang#3947:
- rust-lang#3301: This is fixed with the rewrite, what this implementation does is that it scans through the first occurence of groupings and picks the appropriate one out. This means the user can actually rearrange the groupings on a per file basis to their liking. If a group isnt being found it is inserted according to the `ImportGroup` variant order(Would be nice if this was configurable I imagine).
- rust-lang#3831: This should be fixed with the introduced `MergeBehaviour` enum and it's `Last` variant.
- rust-lang#3946: This should also be [fixed](https://github.com/rust-analyzer/rust-analyzer/pull/5935/files#diff-6923916dd8bdd2f1ab4b984adacd265fR87)
- rust-lang#5795: This is fixed in the sense that the grouping search picks the first group that is of the same kind as the import that is being added. So if there is a random import in the middle of the program it should only be considered if there is no group of the same kind in the file already present.
- the last point in the list I havent checked yet, tho I got the feeling that it's not gonna be too simple as that will require knowledge of whether in this example `ast` is a crate or the module that is already imported.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
U007D pushed a commit to U007D/rust-mos that referenced this pull request Aug 21, 2026
5955: Remove merge import code duplication r=jonas-schievink a=Veykril
This removes the code duplication caused by rust-lang#5935, this also allows the assist to merge imports that have equal visibility and prevents merges of unequal visibility. This PR also fixes an iteration mistake in the mentioned PR:
Turns out I made a mistake when writing the `segment_iter` function, I was assuming that the `children` of a path will just be the segments, which is obviously not the case. This also brings insertion order of shorter paths in line with how `rustfmt` orders them.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Sign up for freeto 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.

3 participants

@brendanzab@thestinger@bors