Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integer trait divides is backwards. #15710

Closed
treeman opened this issue Jul 16, 2014 · 4 comments
Closed

Integer trait divides is backwards. #15710

treeman opened this issue Jul 16, 2014 · 4 comments

Comments

@treeman
Copy link
Contributor

treeman commented Jul 16, 2014

9i.divides(&3) == true but 3i.divides(&9) == false.

It should be the other way around.

@blaxill
Copy link

blaxill commented Jul 16, 2014

Note that the trait comment agrees with the current definition/result. However, I agree with @treeman that the function name implies that we are testing if self.divides(other).

libnum/integer.rs#L75

    /// Returns `true` if `other` divides evenly into `self`
    fn divides(&self, other: &Self) -> bool;

@sneves
Copy link
Contributor

sneves commented Jul 16, 2014

I suggest renaming the function to is_multiple_of. I think that makes its meaning clearer and unambiguous.

@treeman
Copy link
Contributor Author

treeman commented Sep 3, 2014

Closed by #16045.

@alexcrichton
Copy link
Member

Thanks!

lnicola pushed a commit to lnicola/rust that referenced this issue Sep 25, 2024
…rsky

internal: Add preliminary `SyntaxEditor` functionality

Related to rust-lang#15710

Implements a `SyntaxEditor` interface to abstract over the details of modifying syntax trees, to both simplify creating new code fixes and code actions, as well as start on the path of getting rid of mutable syntax nodes.

`SyntaxEditor` relies on `SyntaxMappingBuilder`s to feed in the correct information to map AST nodes created by `make` constructors, as `make` constructors do not guarantee that node identity is preserved. This is to paper over the fact that `make` constructors simply re-parse text input instead of building AST nodes from the ground up and re-using the provided syntax nodes.

`SyntaxAnnotation`s are used to find where syntax elements have ended up after edits are applied. This is primarily useful for the `add_{placeholder,tabstop}` set of methods on `SourceChangeBuilder`, as that currently relies on the nodes provided being in the final syntax tree.

Eventually, the goal should be to move this into the `rowan` crate when we move away from mutable syntax nodes, but for now it'll stay in the `syntax` crate.

---

Closes rust-lang#14921 as `SyntaxEditor` ensures that all replace changes are disjoint
Closes rust-lang#9649 by implementing `SyntaxAnnotation`s
lnicola pushed a commit to lnicola/rust that referenced this issue Sep 25, 2024
internal: Extend SourceChangeBuilder to make make working with `SyntaxEditor`s easier

Part of rust-lang#15710

Adds additional `SourceChangeBuilder` methods to make it easier to migrate assists to `SyntaxEditor`.

As `SyntaxEditor`s are composable before they're completed, each created `SyntaxEditor` can represent logical groups of changes (e.g. independently performing renames of uses in a file from inserting the new item). Once a group of changes is considered "done", `SourceChangeBuilder::add_file_edits` is used to submit a set of changes to be part of the source change.

`SyntaxAnnotation`s are used to indicate where snippets are attached to, and using `SyntaxAnnotation`s also means that we can attach snippets at any time, rather than being required to be after all edits.
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

No branches or pull requests

4 participants