]> git.ipfire.org Git - thirdparty/gcc.git/blobdiff - gcc/diagnostic-color.c
* doc/install.texi (Specific, alpha): Remove note to use
[thirdparty/gcc.git] / gcc / diagnostic-color.c
index 42aa1b6022623122483cc5bedbcf00c2cf1b8a5f..69e759ff6e84daa51b3a54f6ed5152f7722cb570 100644 (file)
@@ -1,5 +1,5 @@
 /* Output colorization.
-   Copyright (C) 2011-2016 Free Software Foundation, Inc.
+   Copyright (C) 2011-2019 Free Software Foundation, Inc.
 
    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
 #include "system.h"
 #include "diagnostic-color.h"
 
-/* Select Graphic Rendition (SGR, "\33[...m") strings.  */
-/* Also Erase in Line (EL) to Right ("\33[K") by default.  */
-/*    Why have EL to Right after SGR?
-        -- The behavior of line-wrapping when at the bottom of the
-           terminal screen and at the end of the current line is often
-           such that a new line is introduced, entirely cleared with
-           the current background color which may be different from the
-           default one (see the boolean back_color_erase terminfo(5)
-           capability), thus scrolling the display by one line.
-           The end of this new line will stay in this background color
-           even after reverting to the default background color with
-           "\33[m', unless it is explicitly cleared again with "\33[K"
-           (which is the behavior the user would instinctively expect
-           from the whole thing).  There may be some unavoidable
-           background-color flicker at the end of this new line because
-           of this (when timing with the monitor's redraw is just right).
-        -- The behavior of HT (tab, "\t") is usually the same as that of
-           Cursor Forward Tabulation (CHT) with a default parameter
-           of 1 ("\33[I"), i.e., it performs pure movement to the next
-           tab stop, without any clearing of either content or screen
-           attributes (including background color); try
-              printf 'asdfqwerzxcv\rASDF\tZXCV\n'
-           in a bash(1) shell to demonstrate this.  This is not what the
-           user would instinctively expect of HT (but is ok for CHT).
-           The instinctive behavior would include clearing the terminal
-           cells that are skipped over by HT with blank cells in the
-           current screen attributes, including background color;
-           the boolean dest_tabs_magic_smso terminfo(5) capability
-           indicates this saner behavior for HT, but only some rare
-           terminals have it (although it also indicates a special
-           glitch with standout mode in the Teleray terminal for which
-           it was initially introduced).  The remedy is to add "\33K"
-           after each SGR sequence, be it START (to fix the behavior
-           of any HT after that before another SGR) or END (to fix the
-           behavior of an HT in default background color that would
-           follow a line-wrapping at the bottom of the screen in another
-           background color, and to complement doing it after START).
-           Piping GCC's output through a pager such as less(1) avoids
-           any HT problems since the pager performs tab expansion.
-
-      Generic disadvantages of this remedy are:
-        -- Some very rare terminals might support SGR but not EL (nobody
-           will use "gcc -fdiagnostics-color" on a terminal that does not
-           support SGR in the first place).
-        -- Having these extra control sequences might somewhat complicate
-           the task of any program trying to parse "gcc -fdiagnostics-color"
-           output in order to extract structuring information from it.
-      A specific disadvantage to doing it after SGR START is:
-        -- Even more possible background color flicker (when timing
-           with the monitor's redraw is just right), even when not at the
-           bottom of the screen.
-      There are no additional disadvantages specific to doing it after
-      SGR END.
-
-      It would be impractical for GCC to become a full-fledged
-      terminal program linked against ncurses or the like, so it will
-      not detect terminfo(5) capabilities.  */
-#define COLOR_SEPARATOR                ";"
-#define COLOR_NONE             "00"
-#define COLOR_BOLD             "01"
-#define COLOR_UNDERSCORE       "04"
-#define COLOR_BLINK            "05"
-#define COLOR_REVERSE          "07"
-#define COLOR_FG_BLACK         "30"
-#define COLOR_FG_RED           "31"
-#define COLOR_FG_GREEN         "32"
-#define COLOR_FG_YELLOW                "33"
-#define COLOR_FG_BLUE          "34"
-#define COLOR_FG_MAGENTA       "35"
-#define COLOR_FG_CYAN          "36"
-#define COLOR_FG_WHITE         "37"
-#define COLOR_BG_BLACK         "40"
-#define COLOR_BG_RED           "41"
-#define COLOR_BG_GREEN         "42"
-#define COLOR_BG_YELLOW                "43"
-#define COLOR_BG_BLUE          "44"
-#define COLOR_BG_MAGENTA       "45"
-#define COLOR_BG_CYAN          "46"
-#define COLOR_BG_WHITE         "47"
-#define SGR_START              "\33["
-#define SGR_END                        "m\33[K"
-#define SGR_SEQ(str)           SGR_START str SGR_END
-#define SGR_RESET              SGR_SEQ("")
+#ifdef __MINGW32__
+#  include <windows.h>
+#endif
 
+#include "color-macros.h"
 
 /* The context and logic for choosing default --color screen attributes
    (foreground and background colors, etc.) are the following.
@@ -170,6 +91,11 @@ static struct color_cap color_dict[] =
   { "quote", SGR_SEQ (COLOR_BOLD), 5, false },
   { "fixit-insert", SGR_SEQ (COLOR_FG_GREEN), 12, false },
   { "fixit-delete", SGR_SEQ (COLOR_FG_RED), 12, false },
+  { "diff-filename", SGR_SEQ (COLOR_BOLD), 13, false },
+  { "diff-hunk", SGR_SEQ (COLOR_FG_CYAN), 9, false },
+  { "diff-delete", SGR_SEQ (COLOR_FG_RED), 11, false },
+  { "diff-insert", SGR_SEQ (COLOR_FG_GREEN), 11, false },
+  { "type-diff", SGR_SEQ (COLOR_BOLD COLOR_SEPARATOR COLOR_FG_GREEN), 9, false },
   { NULL, NULL, 0, false }
 };
 
@@ -200,7 +126,9 @@ colorize_stop (bool show_color)
 /* Parse GCC_COLORS.  The default would look like:
    GCC_COLORS='error=01;31:warning=01;35:note=01;36:\
    range1=32:range2=34:locus=01:quote=01:\
-   fixit-insert=32:fixit-delete=31'
+   fixit-insert=32:fixit-delete=31:'\
+   diff-filename=01:diff-hunk=32:diff-delete=31:diff-insert=32:\
+   type-diff=01;32'
    No character escaping is needed or supported.  */
 static bool
 parse_gcc_colors (void)
@@ -268,23 +196,28 @@ parse_gcc_colors (void)
       return true;
 }
 
-#if defined(_WIN32)
-bool
-colorize_init (diagnostic_color_rule_t)
-{
-  return false;
-}
-#else
-
 /* Return true if we should use color when in auto mode, false otherwise. */
 static bool
 should_colorize (void)
 {
+#ifdef __MINGW32__
+  /* For consistency reasons, one should check the handle returned by
+     _get_osfhandle(_fileno(stderr)) because the function
+     pp_write_text_to_stream() in pretty-print.c calls fputs() on
+     that stream.  However, the code below for non-Windows doesn't seem
+     to care about it either...  */
+  HANDLE h;
+  DWORD m;
+
+  h = GetStdHandle (STD_ERROR_HANDLE);
+  return (h != INVALID_HANDLE_VALUE) && (h != NULL)
+         && GetConsoleMode (h, &m);
+#else
   char const *t = getenv ("TERM");
   return t && strcmp (t, "dumb") != 0 && isatty (STDERR_FILENO);
+#endif
 }
 
-
 bool
 colorize_init (diagnostic_color_rule_t rule)
 {
@@ -303,4 +236,3 @@ colorize_init (diagnostic_color_rule_t rule)
       gcc_unreachable ();
     }
 }
-#endif