-
Notifications
You must be signed in to change notification settings - Fork 71
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
Refine mode: production
diagnostic output
#2236
base: main
Are you sure you want to change the base?
Conversation
{ | ||
Severity: diag.Error, | ||
Summary: "target with 'mode: production' must " + advice, | ||
Detail: adviceDetail, |
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.
@pietern I'd really like to include location information here and in the other diagnostics in this file, but I'm not sure there is any good way to do that without reverting 6ea5306 (which was originally discussed in #1712 (comment))
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.
Which location do you want to include?
The conditional checks for absence, so the best possible location seems to be the target definition itself?
If the variables v2 proposal from @denik materializes, we can revisit access to the original targets section. The comment I made in that thread still holds now.
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.
Yeah, I'd just include the target block as seen in 9466bdc. The same would apply to a couple of the other messages in process_target_mode
.
So it seems that the location information would be another benefit of decomposing select_target
. We may care more about that in a later stage of the current workspace work. I think we covered all the other trade-offs in the other thread.
Variable resolution is a good point though — it seems like we would want to resolve variables for the selected target. And we could preemptively clean up the other targets to avoid confusion.
In any case, I'd be okay to merge this as is for now. With the extra comments, the surprises of select_target
are somewhat alleviated. And we can do without location information for now.
Note that tests currently fail here; I'll do another quick pass over this based on the outcome of the discussion above. |
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.
Please consider adding an acceptance test for these conditions. That will ensure that the advice is rendered correctly in the expected cases.
mode: production
diagnostic outputmode: production
diagnostic output
Changes
This refines the
mode: production
diagnostic output now that theDetail
property is rendered as output. This is a follow-up to #1712.