-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Stabilize the "approximate suggestion" flag, use for the epoch #50168
Labels
T-dev-tools
Relevant to the dev-tools subteam, which will review and decide on the PR/issue.
Comments
Manishearth
added
I-nominated
T-dev-tools
Relevant to the dev-tools subteam, which will review and decide on the PR/issue.
labels
Apr 22, 2018
I'm mostly in favour. I wonder if the flag is future proof enough - should we upgrade it to an enum? |
Like a suggestion kind field that currently only allows "approximate" and "automatic"? |
Interesting, I’m kinda in favor of using an enum. Even if it probably doesn’t
matter much for now and we can always add other fields and either deprecate
this or specialize it’s meaning with new fields if we care about backward
compat even though it’s not as nice.
What are other options besides approx and auto? Something like “template”
with placeholders for editors to put cursors in (like classical textmate
snippets)?
Oliver Schneider <notifications@github.com> schrieb am Mo. 23. Apr. 2018 um
11:17:
… Like a suggestion kind field that currently only allows "approximate" and
"automatic"?
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
<#50168 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABOX8fi3tRMz3Of-Chx7aKUSIED7Judks5trZwXgaJpZM4TfAO4>
.
|
There's also a difference between those which _may_ work and those which
_definitrly won't work_. Macros fall within the former, but placeholders
fall within the latter.
…On Mon, Apr 23, 2018, 2:24 AM Pascal Hertleif ***@***.***> wrote:
Interesting, I’m kinda in favor of using an enum. It probably doesn’t
matter much for now and we can always add other fields and either deprecate
this or specialize it’s meaning with new fields if we care about backward
compat even though it’s not as nice.
What are other options besides approx and auto? Something like “template”
with placeholders for editors to put cursors in (like classical textmate
snippets)?
Oliver Schneider ***@***.***> schrieb am Mo. 23. Apr. 2018
um
11:17:
> Like a suggestion kind field that currently only allows "approximate" and
> "automatic"?
>
> —
> You are receiving this because you are on a team that was mentioned.
> Reply to this email directly, view it on GitHub
> <#50168 (comment)>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/AABOX8fi3tRMz3Of-Chx7aKUSIED7Judks5trZwXgaJpZM4TfAO4
>
> .
>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#50168 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABivSFkDrg9OLKyoBspOGevOGUHUojU7ks5trZ3BgaJpZM4TfAO4>
.
|
Dev tools meeting: Let's use an enum with these variants at first (represented as string in JSON output):
Will implement, then do a FCP on this issue |
impl in #50486 |
This landed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We're going to be using rustfix for epoch upgrades, and we need a way to signal to the tool that a suggestion may not apply (and instead to prompt with it).
We have an unstable "approximate suggestion" flag. I propose stabilizing this. We should also start using it everywhere.
cc @rust-lang/dev-tools
The text was updated successfully, but these errors were encountered: