Handle special types correctly #287
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
CreepySkeleton
force-pushed
the
handle_paths_correctly
branch
4 times, most recently
from
8e6621e
to
65d1773
Compare
CreepySkeleton
force-pushed
the
handle_paths_correctly
branch
from
65d1773
to
171a2c1
Compare
|
There is some cases when it could be used: to have something collectable that is not a vec, one can declare something that ends with Vec to trick structopt. I don't think neither that someone rely on that, so let's merge it. At worst, we will revert it if we have some bug reports. |
TeXitoi
approved these changes
Nov 29, 2019
|
We forgot the changelog for this one. |
|
I'll remember to make sure it'll end up being put in changelog one way or another, don't you worry :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While thinking on #285 I suggested to use
::vec::Vecinstead ofVecto prevent special casing, but a simple test proved me wrong. In fact, any path that ends withVec<T>will be considered asVec<T>which is wrong. The same goes forOptionandbool.I believe this is a bug and it should be fixed. This PR handles paths correctly, checking not only the last segment but also verifying that the said segment is the only one segment present, no leading
::.Technically, this is a breaking change but I believe this is a bug and, furthermore, I really doubt someone out there has been relying on this behavior.