4 Commits (3c8a4e6e05afefb7639bf30efa852cf59f14ade6)

Author	SHA1	Message	Date
Alisdair McDiarmid	3a9b369b43	views/json: Fix diag crash with invalid highlight ... Some diagnostic sources (I'm looking at you, HCL) fail to set the end of the subject range. This is a bug in those code paths, but we can ensure that we generate valid JSON diagnostics by checking for it here. By doing so before the range normalization, we ensure that we generate a unit width highlight whenever possible, so that at least something useful is displayed.	5 years ago
Martin Atkins	8f233cde4c	cli: Diagnostics can include collections with sensitive elements ... We previously had a shallow IsMarked call in compactValueStr's caller but then a more-conservative deep ContainsMarked call inside compactValueStr with a different resulting message. As well as causing an inconsistency in messages, this was also a bit confusing because it made it seem like a non-sensitive collection containing a sensitive element value was wholly sensitive, making the debug information in the diagnostic messages not trustworthy for debugging certain varieties of problem. I originally considered just removing the redundant check in compactValueStr here, but ultimately I decided to keep it as a sort of defense in depth in case a future refactoring disconnects these two checks. This should also serve as a prompt to someone making later changes to compactValueStr to think about the implications of sensitive values in there, which otherwise wouldn't be mentioned at all. Disclosing information about a collection containing sensitive values is safe here because compactValueStr only discloses information about the value's type and element keys, and neither of those can be sensitive in isolation. (Constructing a map with sensitive keys reduces to a sensitive overall map.)	5 years ago
James Bardin	406ac97965	add the address field to the view diagnostics	5 years ago
Alisdair McDiarmid	d9d88b9243	cli: Add comprehensive JSON diagnostic structure ... This commit adds a comprehensive JSON format for diagnostics, which ensures that all current diagnostic output can be semantically represented in a machine-readable format. The diagnostic formatter interface remains unchanged, but it first transforms its input via the JSON format to ensure that there is only one code path for creating the diagnostic data. The JSON diagnostic renderer extracts the non-presentational logic from the format package, and returns a structure which can either be marshaled into JSON or rendered as text. The resulting text diagnostic output is unchanged for all cases covered by unit tests and my own manual testing. Included in this commit are a number of golden reference files for the marshaled JSON output of a diagnostic. This format should change rarely if at all, and these are in place to ensure that any changes to the format are intentional and considered.	5 years ago