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

De-duplicate methods in core::path(2) when default trait methods work #3227

Closed
graydon opened this issue Aug 20, 2012 · 4 comments
Closed

De-duplicate methods in core::path(2) when default trait methods work #3227

graydon opened this issue Aug 20, 2012 · 4 comments
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@graydon
Copy link
Contributor

graydon commented Aug 20, 2012

The new path code has a bunch of duplicate code between the posix and windows variants. It should be factored into material in the abstract Path trait, when default methods work.

@ghost ghost assigned graydon Aug 20, 2012
@lkuper
Copy link
Contributor

lkuper commented Aug 20, 2012

Blocked on #2794.

@graydon
Copy link
Contributor Author

graydon commented Jun 13, 2013

Still legit, 2013-06-12.

(Note: #2794 may well be fixed shortly, worth revisiting soon!)

@emberian
Copy link
Member

emberian commented Aug 5, 2013

Default methods work now.

bors added a commit that referenced this issue Sep 6, 2013
…chton

 (cc: #3227)

Parts I'm unsure about and would like a reviewer to look at are:

  * `pub trait GenericPath : Clone + Eq + ToStr` -- is this the done thing?  I've never done trait inheritance before, let alone from multiple traits, but it seemed to be necessary to be able to call all the methods we have to be able to call on `self`.

  * changing the argument of `components` from `self` to `&self`, and having it return `self.components.clone()` instead of `self.components`; this was necessary to avoid move errors, but I'm not sure if it's the right thing.  (The default methods impls now all have to call `self.components()` instead of just referencing the field `self.components`.)
bors added a commit that referenced this issue Sep 6, 2013
…chton

 (cc: #3227)

Parts I'm unsure about and would like a reviewer to look at are:

  * `pub trait GenericPath : Clone + Eq + ToStr` -- is this the done thing?  I've never done trait inheritance before, let alone from multiple traits, but it seemed to be necessary to be able to call all the methods we have to be able to call on `self`.

  * changing the argument of `components` from `self` to `&self`, and having it return `self.components.clone()` instead of `self.components`; this was necessary to avoid move errors, but I'm not sure if it's the right thing.  (The default methods impls now all have to call `self.components()` instead of just referencing the field `self.components`.)
@lkuper
Copy link
Contributor

lkuper commented Sep 6, 2013

#8909 closes this.

@lkuper lkuper closed this as completed Sep 6, 2013
@graydon graydon removed their assignment Jun 16, 2014
RalfJung pushed a commit to RalfJung/rust that referenced this issue Dec 17, 2023
jaisnan added a commit to jaisnan/rust-dev that referenced this issue Jul 29, 2024
While at it, I also added a `--skip-libs` to skip rebuilding the Kani
libraries and standard library at every `cargo build-dev` execution.

We usually only need to rebuild the libraries when we make changes to
them or when we update the Rust toolchain. Rebuilding them can be quite
time consuming when you are making changes to Kani.

Towards rust-lang#3226 rust-lang#3153

Co-authored-by: Jaisurya Nanduri <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

No branches or pull requests

3 participants