rustup: fix nightly

[japaric]

See details in the commits.

[yo-bot]

Thanks for the pull request, and welcome! The team is excited to review your changes, and you should hear from @sru (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[sru]

Hello, and thanks for the pull request! The first commit (d752c17) is good, but other two "not good" (I can't find a word for it right now) because they can be done in several ways.

For missing debug implementations, I think it is best to implement those debug information (see #430).

For deriving Copy for ArgFlags, it does sound reasonable because ArgFlags is only a wrapper for underlying bit flags (which is cheap to copy, AFAIK). I don't know if the Copy trait was intentionally left out though (pinging @kbknapp). Also, adding Copy trait means that those calls to .clone() is unnecessary, as picked up by clippy in the Travis CI build.

The nightly build is still failing because of the unnecessary .clone() I mentioned above and because of useless format emitted by clippy.

[kbknapp]

Copy wasent left out on purpose, just overlooked. Adding copy is a great idea.

I'm also ok with the missing debug implementations, but if we end up needing to add the debug info for thone struts at some point we may add it. At some point in the future I'd like to look at only deriving debug implementations when the debug feature is used...buy that's just me thinking out loud, not set in stone.

The only thing I'm not sure about for this pr is the len->len_ changes. What's the gain?

Also like @sru said, thanks for putting this PR together!

[jedisct1]

Isn't the len() -> len_() change required since len() was added to OsString?

[japaric]

Isn't the len() -> len_() change required since len() was added to OsString?

Yes. OsString just gained unstable inherent len and is_empty methods. Calling str.len() will use the inherent method instead of the method in OsStrExt2 raising an error because the inherent method is unstable.

Renaming OsStrExt2 methods to something different than the inherent methods solves the problem.

[kbknapp]

Ah ok awsome I hadn't seen that! 👍

[japaric]

pushed a new commit fixing the clippy warnings

[sru]

Hmm... I don't know why appveyor is failing now... @Vinatorul?

[kbknapp]

Not sure, I just restarted the build.

[kbknapp]

It seems like an issue with AppVeyor itself, and since this PR passed AppVeyor once already, I'm good merging without it this time.

@japaric Thanks for the contributions! Much appreciated!

[kbknapp]

@homu r+

[homu]

📌 Commit 56d14cb has been approved by kbknapp

[homu]

⌛ Testing commit 56d14cb with merge a5ceee2...

[homu]

☀️ Test successful - status