-
Notifications
You must be signed in to change notification settings - Fork 183
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
Add icu-locale macros #220
Conversation
f2eb526
to
ac3fd08
Compare
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
ac3fd08
to
81e4597
Compare
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
81e4597
to
c43f9c7
Compare
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
c43f9c7
to
08a41b8
Compare
Hooray! The files in the branch are the same across the force-push. 😃 ~ Your Friendly Jira-GitHub PR Checker Bot |
@echeran I may need your help in getting the actions cache invalidated - the failures are because we use outdated Rust. We should bump to 1.46 which will happen on cache regeneration. The rest is ready for review! I had to wrap The rest is fairly simple I hope :) |
I created an issue to separate out the discussion of the cached artifacts causing conflicts - #225 |
08a41b8
to
c3041d1
Compare
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
I rebased on top of master, added doc comments and improved handling of variants in macro. This PR is pending release of Rust 1.47 on October 8th (https://forge.rust-lang.org/), but I'd like to get it reviewed and ready for landing prior to that. |
c3041d1
to
3d86024
Compare
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
I applied your feedback to docs, except of Locale and LanguageIdentifier I generally believe that cases where anyone cares about some syntax canonicalization but not form are so extremely rare, that I would like to introduce form canonicalization as an implicit "upgrade" to the functionality without changes to the signature and considered non-breaking. Since it requires data, we may end up having it behind a feature, in which case user can in theory use that feature to decide if the canonicalization will be syntax only or also form, but I'd like to treat the public API as "we will do everything we can do give you a good output" and if we see a body of need accruing for more specificity, we can then break the API and add options to flip parts of canonicalization. I updated the docs but I'd like to remove the specifier "syntax" once we land the form canonicalization. Either way, that's a conversation we can have when we work on form canonicalization and I hope this update unblocks this PR. |
e801300
to
e6d58e9
Compare
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
e6d58e9
to
a2c699e
Compare
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
a2c699e
to
6aaefa5
Compare
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
use proc_macro::TokenStream; | ||
use token_stream::IntoTokenStream; | ||
|
||
fn get_value_from_token_stream(input: TokenStream) -> String { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking for literal "
is also what you do in tinystr. We need to fix this, but it shouldn't block this PR. zbraniecki/tinystr#24
Fixes #75.