-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
std.debug: handle some possible errors and resolve low-hanging TODOs #12298
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
Merged
Conversation
This file contains hidden or 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
Member
|
Looks like I merged your PRs out of order. Sorry about that. You mind rebasing this one? |
Author
|
Sure! Rebased. |
Author
|
Now it should be up-to-date again. |
andrewrk
requested changes
Oct 30, 2022
Originally I just wanted to move these down because they seemed to be in some random position of the file, but these constants look very old with their CASING and pretty unnecessary anyway so I just inlined them.
Author
|
aarch64-windows got stuck so I rebased once more. All other CIs already passed though. |
squeek502
added a commit
to squeek502/zig
that referenced
this pull request
Dec 15, 2022
This fixes a regression introduced in ziglang#12298 where colors would never reset in a Windows console because the attributes would be queried on every `setColor` call, and then try to 'reset' the attributes to what it just queried (i.e. it was essentially doing a complicated no-op on .Reset). This fixes the problem while (I think) keeping with the spirit of the changes in ziglang#12298--that is, `TTY.Config` is not specifically tied to stderr like it was before ziglang#12298. To that end, detectTTYConfig now takes a `File` and that's what gets used to query the initial attributes to reset to. (for context, before ziglang#12298, the first `setColor` call is where the reset attributes would get queried and it would always use stderr to do it)
andrewrk
pushed a commit
that referenced
this pull request
Dec 15, 2022
This fixes a regression introduced in #12298 where colors would never reset in a Windows console because the attributes would be queried on every `setColor` call, and then try to 'reset' the attributes to what it just queried (i.e. it was essentially doing a complicated no-op on .Reset). This fixes the problem while (I think) keeping with the spirit of the changes in #12298--that is, `TTY.Config` is not specifically tied to stderr like it was before #12298. To that end, detectTTYConfig now takes a `File` and that's what gets used to query the initial attributes to reset to. (for context, before #12298, the first `setColor` call is where the reset attributes would get queried and it would always use stderr to do it)
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.
ttyconf.setColor(stderr, .Dim)just likestderr.print("{s}", .{plain.msg})can fail, so I don't see why we wouldn't handle the former just like the latter. It's an edge case. You can always still ignore the error in your specific case if you want to.Apart from that it solves a bunch of related TODOs and it also removes a bunch of
unreachables instd.Progresswhich is supposed to be non-fallible because now I'm confident theseunreachables can be reached since the user can modify thestd.Progress.terminalfield. It can probably fail anyway. Better safe than sorry.