You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We can improve the output of compiler messages to make it easier for users to spot problems. Some potential improvements include:
Colouring text to indicate different levels of message (e.g. red for errors, yellow for warnings, green for success).
Grouping messages - maybe we should group warnings and errors separately, and output the errors last to reduce scrolling to find all the errors.
Multiple levels of diagnostic output (see below).
Multiple Levels of Diagnostic Output
We don't want to cause information overload by providing users with too much information. At the same time, in certain situations we can provide extra contextual information that can help diagnose problems.
If we take the following IDL sample:
structUser {
slistUsername
}
We can provide a simple warning message like the following to indicate that the slist field is deprecated:
thrift-samples/structs/User.thrift(5,5-9): Warning TC0204: 'CreatedOn' uses the `slist` type, which should no-longer be used. Please use the `string`type instead. [/home/adam/github.com/adamconnelly/thrift.net/thrift-samples/structs/User.thrift]
The message might be easier to read if we exclude the absolute path, so maybe we could output the following:
thrift-samples/structs/User.thrift(5,5-9): Warning TC0204: 'CreatedOn' uses the `slist` type, which should no-longer be used. Please use the `string`type instead.
Similarly, users might not care about the error code, so we could potentially drop that if requested.
In the opposite direction, we could provide additional context information to help diagnose the error. For example:
struct User {
slist Username
^^^^^
thrift-samples/structs/User.thrift(5,5-9): Warning TC0204: 'CreatedOn' uses the `slist` type, which should no-longer be used. Please use the `string`type instead.
This won't be desirable all the time since it will add a lot of noise to the output, so maybe we can allow users to adjust the verbosity of the compiler via command line flags, or use some kind of heuristic system. For example, maybe when the number of messages is under a certain amount we automatically produce more verbose output.
Group Messages by File
We could maybe make the messages easier to read by reducing the duplication of the filename. For example:
thrift-samples/structs/User.thrift [/home/adam/github.com/adamconnelly/thrift.net/thrift-samples/structs/User.thrift]
5,5-9: Warning TC0204: 'CreatedOn' uses the `slist` type, which should no-longer be used. Please use the `string`type instead.
22,11-12: Error TC0207: The set must have an element type specified.
thrift-samples/structs/Address.thrift [/home/adam/github.com/adamconnelly/thrift.net/thrift-samples/structs/Address.thrift]
5,5-8: Warning TC0009: The enum member 'Read' does not have a value specified, and has an implicit value of '0'. Please specify a value.
The text was updated successfully, but these errors were encountered:
We can improve the output of compiler messages to make it easier for users to spot problems. Some potential improvements include:
Multiple Levels of Diagnostic Output
We don't want to cause information overload by providing users with too much information. At the same time, in certain situations we can provide extra contextual information that can help diagnose problems.
If we take the following IDL sample:
We can provide a simple warning message like the following to indicate that the
slist
field is deprecated:The message might be easier to read if we exclude the absolute path, so maybe we could output the following:
Similarly, users might not care about the error code, so we could potentially drop that if requested.
In the opposite direction, we could provide additional context information to help diagnose the error. For example:
This won't be desirable all the time since it will add a lot of noise to the output, so maybe we can allow users to adjust the verbosity of the compiler via command line flags, or use some kind of heuristic system. For example, maybe when the number of messages is under a certain amount we automatically produce more verbose output.
Group Messages by File
We could maybe make the messages easier to read by reducing the duplication of the filename. For example:
The text was updated successfully, but these errors were encountered: