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

allow any string-like value #177

Merged
merged 1 commit into from
Feb 19, 2022
Merged

Conversation

cortopy
Copy link
Contributor

@cortopy cortopy commented Nov 24, 2021

As per #176, I've tried to relax the validation a bit. It does work for prost Strings. Would this be acceptable?

@Keats
Copy link
Owner

Keats commented Nov 24, 2021

It's not really going to cover your usecase if you have an Option for example. Maybe we just look if str or String are in it?

@cortopy cortopy force-pushed the less-strict-string-validation branch from c8e44c2 to e8253db Compare November 25, 2021 15:25
@cortopy
Copy link
Contributor Author

cortopy commented Nov 25, 2021

@Keats you were totally right. As I carried on adding validation I stumbled upon more cases.

I've added changes for Option<*String> and it's working for me

While doing this I realised that the main issue is that prost supports no_std and this impacts both String and Option (prost uses core::option::Option), but the latter is a different story altogether I think

I hope this PR helps with widening compatibility

@@ -113,7 +113,7 @@ pub fn assert_has_len(field_name: String, type_name: &str, field_type: &syn::Typ
return;
}

if type_name != "String"
if !type_name.ends_with("String")
&& !type_name.starts_with("Vec<")
&& !type_name.starts_with("Option<Vec<")
&& !type_name.starts_with("Option<Option<Vec<")
Copy link
Owner

Choose a reason for hiding this comment

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

should we just search for String and str rather than this ever-expanding list of possibilities? Worst case, it will be a compile time error if they tried to use it on a type it can't be used but that can be documented in the README.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

it does sound like a sensible approach to me. The validation error feels like a very nice message for easier development, but if it's getting too much on the way then relaxing it would help too.

I've made the change to simplify this as much as possible. There are still Option<Option< checks for other types but they don't affect the case of strings

Copy link
Owner

Choose a reason for hiding this comment

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

We should keep the same logic for the length validator below though

Copy link
Contributor Author

Choose a reason for hiding this comment

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

(apologies for the delayed response. I was caught with a few things and this slipped through! )

Thanks for that. I just pushed the recommended changes

@cortopy cortopy force-pushed the less-strict-string-validation branch from e8253db to 5d13af7 Compare December 1, 2021 22:04
@cortopy cortopy force-pushed the less-strict-string-validation branch from 5d13af7 to 0380ae7 Compare December 14, 2021 13:02
@Keats Keats merged commit 47908fe into Keats:master Feb 19, 2022
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

Successfully merging this pull request may close these issues.

2 participants