2023-12-14 03:38:41 +08:00
|
|
|
# SPDX-License-Identifier: Apache-2.0
|
2018-12-23 22:19:45 +08:00
|
|
|
# Copyright 2018 The Meson development team
|
|
|
|
|
2022-09-14 09:22:35 +08:00
|
|
|
from __future__ import annotations
|
2018-12-23 22:19:45 +08:00
|
|
|
|
2021-03-10 21:41:54 +08:00
|
|
|
import argparse
|
2018-12-23 22:19:45 +08:00
|
|
|
import subprocess
|
2021-03-10 02:15:06 +08:00
|
|
|
from pathlib import Path
|
scripts: make clang tools obey b_colorout
Right now, the clang-tidy and clang-format targets use the program default
and do not let b_colorout decide whether to colorize output.
However, the wrappers that run the tool are going to be changed to buffer
output, and that would disable colorization unconditionally. So pass
a --color option to the tools and use it when building the command line.
clang-format's -fcolor-diagnostics option simply does not work, and the
"right" (or at least working) option is --color which is undocumented.
--color is present all the way back to clang 10, but I digged into
clang-format's source code to figure out what's happening. The problem
is that -fcolor-diagnostics is a complete no-operation; in fact it is
a bool that is initialized to true. gdb shows:
(gdb) p ShowColors
$2 = {<llvm::cl::Option> = {
... <llvm::cl::opt_storage<bool, false, false>> = {Value = true, ... }, ...}
on entry to clang-format's main, meaning that specifying the option on
the command line does nothing at all.
To see how clang-format determines whether to use colors you need to look
at enters SMDiagnostic::print, which simply does
ColorMode Mode = ShowColors ? ColorMode::Auto : ColorMode::Disable;
showing once more that in fact the option cannot force-on the colors (
-fno-color-diagnostics instead works). Continuing in SMDiagnostic::print,
this RAII constructor would write the escape sequence to the terminal:
WithColor S(OS, raw_ostream::SAVEDCOLOR, true, false, Mode);
It ends up in WithColor::changeColor, which does
if (colorsEnabled())
OS.changeColor(Color, Bold, BG);
Digging further down, colorsEnabled() is where the Mode member is consulted:
bool WithColor::colorsEnabled() {
switch (Mode) {
case ColorMode::Enable:
return true;
case ColorMode::Disable:
return false;
case ColorMode::Auto:
return AutoDetectFunction(OS);
}
llvm_unreachable("All cases handled above.");
}
and the "AutoDetectFunction" is
static bool DefaultAutoDetectFunction(const raw_ostream &OS) {
return *UseColor == cl::BOU_UNSET ? OS.has_colors()
: *UseColor == cl::BOU_TRUE;
}
UseColor is controlled by the "--color" option, so if that option was
unset you go to OS.has_colors() even in the presence of -fcolor-diagnostics.
This has been around for over 5 years in clang-format, and it was present
even earlier, so use it in meson as well.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-11-20 15:50:55 +08:00
|
|
|
import sys
|
2018-12-23 22:19:45 +08:00
|
|
|
|
2024-11-17 16:34:11 +08:00
|
|
|
from .run_tool import run_clang_tool
|
2019-09-19 21:24:04 +08:00
|
|
|
from ..environment import detect_clangformat
|
on newer versions of clang-format, use builtin --check handling
Due to a deficiency in upstream clang-format, our automatic target for
`ninja clang-format-check` runs clang-format, then compares the bytes of
the file before and after to see if anything changed. If it did change,
we rewrite the file back to its original form and error out.
Since clang-format 10, there is an option to report warnings instead of
writing the reformatted file, and also, to make those warnings fatal.
This is a much better user experience, to see *what* is wrong, not just
that something is wrong, and also gets rid of a pretty gross "modify
your files when you didn't ask for it" behavior that is vulnerable to
getting interrupted.
Let's switch over to the new approach, if we can.
2022-11-16 07:12:41 +08:00
|
|
|
from ..mesonlib import version_compare
|
|
|
|
from ..programs import ExternalProgram
|
2020-08-30 03:23:43 +08:00
|
|
|
import typing as T
|
2018-12-23 22:19:45 +08:00
|
|
|
|
scripts: make clang tools obey b_colorout
Right now, the clang-tidy and clang-format targets use the program default
and do not let b_colorout decide whether to colorize output.
However, the wrappers that run the tool are going to be changed to buffer
output, and that would disable colorization unconditionally. So pass
a --color option to the tools and use it when building the command line.
clang-format's -fcolor-diagnostics option simply does not work, and the
"right" (or at least working) option is --color which is undocumented.
--color is present all the way back to clang 10, but I digged into
clang-format's source code to figure out what's happening. The problem
is that -fcolor-diagnostics is a complete no-operation; in fact it is
a bool that is initialized to true. gdb shows:
(gdb) p ShowColors
$2 = {<llvm::cl::Option> = {
... <llvm::cl::opt_storage<bool, false, false>> = {Value = true, ... }, ...}
on entry to clang-format's main, meaning that specifying the option on
the command line does nothing at all.
To see how clang-format determines whether to use colors you need to look
at enters SMDiagnostic::print, which simply does
ColorMode Mode = ShowColors ? ColorMode::Auto : ColorMode::Disable;
showing once more that in fact the option cannot force-on the colors (
-fno-color-diagnostics instead works). Continuing in SMDiagnostic::print,
this RAII constructor would write the escape sequence to the terminal:
WithColor S(OS, raw_ostream::SAVEDCOLOR, true, false, Mode);
It ends up in WithColor::changeColor, which does
if (colorsEnabled())
OS.changeColor(Color, Bold, BG);
Digging further down, colorsEnabled() is where the Mode member is consulted:
bool WithColor::colorsEnabled() {
switch (Mode) {
case ColorMode::Enable:
return true;
case ColorMode::Disable:
return false;
case ColorMode::Auto:
return AutoDetectFunction(OS);
}
llvm_unreachable("All cases handled above.");
}
and the "AutoDetectFunction" is
static bool DefaultAutoDetectFunction(const raw_ostream &OS) {
return *UseColor == cl::BOU_UNSET ? OS.has_colors()
: *UseColor == cl::BOU_TRUE;
}
UseColor is controlled by the "--color" option, so if that option was
unset you go to OS.has_colors() even in the presence of -fcolor-diagnostics.
This has been around for over 5 years in clang-format, and it was present
even earlier, so use it in meson as well.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-11-20 15:50:55 +08:00
|
|
|
def run_clang_format(fname: Path, exelist: T.List[str], options: argparse.Namespace, cformat_ver: T.Optional[str]) -> subprocess.CompletedProcess:
|
on newer versions of clang-format, use builtin --check handling
Due to a deficiency in upstream clang-format, our automatic target for
`ninja clang-format-check` runs clang-format, then compares the bytes of
the file before and after to see if anything changed. If it did change,
we rewrite the file back to its original form and error out.
Since clang-format 10, there is an option to report warnings instead of
writing the reformatted file, and also, to make those warnings fatal.
This is a much better user experience, to see *what* is wrong, not just
that something is wrong, and also gets rid of a pretty gross "modify
your files when you didn't ask for it" behavior that is vulnerable to
getting interrupted.
Let's switch over to the new approach, if we can.
2022-11-16 07:12:41 +08:00
|
|
|
clangformat_10 = False
|
scripts: make clang tools obey b_colorout
Right now, the clang-tidy and clang-format targets use the program default
and do not let b_colorout decide whether to colorize output.
However, the wrappers that run the tool are going to be changed to buffer
output, and that would disable colorization unconditionally. So pass
a --color option to the tools and use it when building the command line.
clang-format's -fcolor-diagnostics option simply does not work, and the
"right" (or at least working) option is --color which is undocumented.
--color is present all the way back to clang 10, but I digged into
clang-format's source code to figure out what's happening. The problem
is that -fcolor-diagnostics is a complete no-operation; in fact it is
a bool that is initialized to true. gdb shows:
(gdb) p ShowColors
$2 = {<llvm::cl::Option> = {
... <llvm::cl::opt_storage<bool, false, false>> = {Value = true, ... }, ...}
on entry to clang-format's main, meaning that specifying the option on
the command line does nothing at all.
To see how clang-format determines whether to use colors you need to look
at enters SMDiagnostic::print, which simply does
ColorMode Mode = ShowColors ? ColorMode::Auto : ColorMode::Disable;
showing once more that in fact the option cannot force-on the colors (
-fno-color-diagnostics instead works). Continuing in SMDiagnostic::print,
this RAII constructor would write the escape sequence to the terminal:
WithColor S(OS, raw_ostream::SAVEDCOLOR, true, false, Mode);
It ends up in WithColor::changeColor, which does
if (colorsEnabled())
OS.changeColor(Color, Bold, BG);
Digging further down, colorsEnabled() is where the Mode member is consulted:
bool WithColor::colorsEnabled() {
switch (Mode) {
case ColorMode::Enable:
return true;
case ColorMode::Disable:
return false;
case ColorMode::Auto:
return AutoDetectFunction(OS);
}
llvm_unreachable("All cases handled above.");
}
and the "AutoDetectFunction" is
static bool DefaultAutoDetectFunction(const raw_ostream &OS) {
return *UseColor == cl::BOU_UNSET ? OS.has_colors()
: *UseColor == cl::BOU_TRUE;
}
UseColor is controlled by the "--color" option, so if that option was
unset you go to OS.has_colors() even in the presence of -fcolor-diagnostics.
This has been around for over 5 years in clang-format, and it was present
even earlier, so use it in meson as well.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-11-20 15:50:55 +08:00
|
|
|
if options.check and cformat_ver:
|
on newer versions of clang-format, use builtin --check handling
Due to a deficiency in upstream clang-format, our automatic target for
`ninja clang-format-check` runs clang-format, then compares the bytes of
the file before and after to see if anything changed. If it did change,
we rewrite the file back to its original form and error out.
Since clang-format 10, there is an option to report warnings instead of
writing the reformatted file, and also, to make those warnings fatal.
This is a much better user experience, to see *what* is wrong, not just
that something is wrong, and also gets rid of a pretty gross "modify
your files when you didn't ask for it" behavior that is vulnerable to
getting interrupted.
Let's switch over to the new approach, if we can.
2022-11-16 07:12:41 +08:00
|
|
|
if version_compare(cformat_ver, '>=10'):
|
|
|
|
clangformat_10 = True
|
|
|
|
exelist = exelist + ['--dry-run', '--Werror']
|
scripts: make clang tools obey b_colorout
Right now, the clang-tidy and clang-format targets use the program default
and do not let b_colorout decide whether to colorize output.
However, the wrappers that run the tool are going to be changed to buffer
output, and that would disable colorization unconditionally. So pass
a --color option to the tools and use it when building the command line.
clang-format's -fcolor-diagnostics option simply does not work, and the
"right" (or at least working) option is --color which is undocumented.
--color is present all the way back to clang 10, but I digged into
clang-format's source code to figure out what's happening. The problem
is that -fcolor-diagnostics is a complete no-operation; in fact it is
a bool that is initialized to true. gdb shows:
(gdb) p ShowColors
$2 = {<llvm::cl::Option> = {
... <llvm::cl::opt_storage<bool, false, false>> = {Value = true, ... }, ...}
on entry to clang-format's main, meaning that specifying the option on
the command line does nothing at all.
To see how clang-format determines whether to use colors you need to look
at enters SMDiagnostic::print, which simply does
ColorMode Mode = ShowColors ? ColorMode::Auto : ColorMode::Disable;
showing once more that in fact the option cannot force-on the colors (
-fno-color-diagnostics instead works). Continuing in SMDiagnostic::print,
this RAII constructor would write the escape sequence to the terminal:
WithColor S(OS, raw_ostream::SAVEDCOLOR, true, false, Mode);
It ends up in WithColor::changeColor, which does
if (colorsEnabled())
OS.changeColor(Color, Bold, BG);
Digging further down, colorsEnabled() is where the Mode member is consulted:
bool WithColor::colorsEnabled() {
switch (Mode) {
case ColorMode::Enable:
return true;
case ColorMode::Disable:
return false;
case ColorMode::Auto:
return AutoDetectFunction(OS);
}
llvm_unreachable("All cases handled above.");
}
and the "AutoDetectFunction" is
static bool DefaultAutoDetectFunction(const raw_ostream &OS) {
return *UseColor == cl::BOU_UNSET ? OS.has_colors()
: *UseColor == cl::BOU_TRUE;
}
UseColor is controlled by the "--color" option, so if that option was
unset you go to OS.has_colors() even in the presence of -fcolor-diagnostics.
This has been around for over 5 years in clang-format, and it was present
even earlier, so use it in meson as well.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-11-20 15:50:55 +08:00
|
|
|
# The option is not documented but it exists in version 10
|
|
|
|
if options.color == 'always' or options.color == 'auto' and sys.stdout.isatty():
|
|
|
|
exelist += ['--color=1']
|
on newer versions of clang-format, use builtin --check handling
Due to a deficiency in upstream clang-format, our automatic target for
`ninja clang-format-check` runs clang-format, then compares the bytes of
the file before and after to see if anything changed. If it did change,
we rewrite the file back to its original form and error out.
Since clang-format 10, there is an option to report warnings instead of
writing the reformatted file, and also, to make those warnings fatal.
This is a much better user experience, to see *what* is wrong, not just
that something is wrong, and also gets rid of a pretty gross "modify
your files when you didn't ask for it" behavior that is vulnerable to
getting interrupted.
Let's switch over to the new approach, if we can.
2022-11-16 07:12:41 +08:00
|
|
|
else:
|
|
|
|
original = fname.read_bytes()
|
2021-03-10 02:15:06 +08:00
|
|
|
before = fname.stat().st_mtime
|
2021-11-10 23:57:41 +08:00
|
|
|
ret = subprocess.run(exelist + ['-style=file', '-i', str(fname)])
|
2021-03-10 02:15:06 +08:00
|
|
|
after = fname.stat().st_mtime
|
|
|
|
if before != after:
|
|
|
|
print('File reformatted: ', fname)
|
scripts: make clang tools obey b_colorout
Right now, the clang-tidy and clang-format targets use the program default
and do not let b_colorout decide whether to colorize output.
However, the wrappers that run the tool are going to be changed to buffer
output, and that would disable colorization unconditionally. So pass
a --color option to the tools and use it when building the command line.
clang-format's -fcolor-diagnostics option simply does not work, and the
"right" (or at least working) option is --color which is undocumented.
--color is present all the way back to clang 10, but I digged into
clang-format's source code to figure out what's happening. The problem
is that -fcolor-diagnostics is a complete no-operation; in fact it is
a bool that is initialized to true. gdb shows:
(gdb) p ShowColors
$2 = {<llvm::cl::Option> = {
... <llvm::cl::opt_storage<bool, false, false>> = {Value = true, ... }, ...}
on entry to clang-format's main, meaning that specifying the option on
the command line does nothing at all.
To see how clang-format determines whether to use colors you need to look
at enters SMDiagnostic::print, which simply does
ColorMode Mode = ShowColors ? ColorMode::Auto : ColorMode::Disable;
showing once more that in fact the option cannot force-on the colors (
-fno-color-diagnostics instead works). Continuing in SMDiagnostic::print,
this RAII constructor would write the escape sequence to the terminal:
WithColor S(OS, raw_ostream::SAVEDCOLOR, true, false, Mode);
It ends up in WithColor::changeColor, which does
if (colorsEnabled())
OS.changeColor(Color, Bold, BG);
Digging further down, colorsEnabled() is where the Mode member is consulted:
bool WithColor::colorsEnabled() {
switch (Mode) {
case ColorMode::Enable:
return true;
case ColorMode::Disable:
return false;
case ColorMode::Auto:
return AutoDetectFunction(OS);
}
llvm_unreachable("All cases handled above.");
}
and the "AutoDetectFunction" is
static bool DefaultAutoDetectFunction(const raw_ostream &OS) {
return *UseColor == cl::BOU_UNSET ? OS.has_colors()
: *UseColor == cl::BOU_TRUE;
}
UseColor is controlled by the "--color" option, so if that option was
unset you go to OS.has_colors() even in the presence of -fcolor-diagnostics.
This has been around for over 5 years in clang-format, and it was present
even earlier, so use it in meson as well.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-11-20 15:50:55 +08:00
|
|
|
if options.check and not clangformat_10:
|
2021-04-30 00:18:41 +08:00
|
|
|
# Restore the original if only checking.
|
|
|
|
fname.write_bytes(original)
|
2021-03-10 21:41:54 +08:00
|
|
|
ret.returncode = 1
|
2021-03-10 02:15:06 +08:00
|
|
|
return ret
|
|
|
|
|
2020-08-30 03:23:43 +08:00
|
|
|
def run(args: T.List[str]) -> int:
|
2021-03-10 21:41:54 +08:00
|
|
|
parser = argparse.ArgumentParser()
|
|
|
|
parser.add_argument('--check', action='store_true')
|
scripts: make clang tools obey b_colorout
Right now, the clang-tidy and clang-format targets use the program default
and do not let b_colorout decide whether to colorize output.
However, the wrappers that run the tool are going to be changed to buffer
output, and that would disable colorization unconditionally. So pass
a --color option to the tools and use it when building the command line.
clang-format's -fcolor-diagnostics option simply does not work, and the
"right" (or at least working) option is --color which is undocumented.
--color is present all the way back to clang 10, but I digged into
clang-format's source code to figure out what's happening. The problem
is that -fcolor-diagnostics is a complete no-operation; in fact it is
a bool that is initialized to true. gdb shows:
(gdb) p ShowColors
$2 = {<llvm::cl::Option> = {
... <llvm::cl::opt_storage<bool, false, false>> = {Value = true, ... }, ...}
on entry to clang-format's main, meaning that specifying the option on
the command line does nothing at all.
To see how clang-format determines whether to use colors you need to look
at enters SMDiagnostic::print, which simply does
ColorMode Mode = ShowColors ? ColorMode::Auto : ColorMode::Disable;
showing once more that in fact the option cannot force-on the colors (
-fno-color-diagnostics instead works). Continuing in SMDiagnostic::print,
this RAII constructor would write the escape sequence to the terminal:
WithColor S(OS, raw_ostream::SAVEDCOLOR, true, false, Mode);
It ends up in WithColor::changeColor, which does
if (colorsEnabled())
OS.changeColor(Color, Bold, BG);
Digging further down, colorsEnabled() is where the Mode member is consulted:
bool WithColor::colorsEnabled() {
switch (Mode) {
case ColorMode::Enable:
return true;
case ColorMode::Disable:
return false;
case ColorMode::Auto:
return AutoDetectFunction(OS);
}
llvm_unreachable("All cases handled above.");
}
and the "AutoDetectFunction" is
static bool DefaultAutoDetectFunction(const raw_ostream &OS) {
return *UseColor == cl::BOU_UNSET ? OS.has_colors()
: *UseColor == cl::BOU_TRUE;
}
UseColor is controlled by the "--color" option, so if that option was
unset you go to OS.has_colors() even in the presence of -fcolor-diagnostics.
This has been around for over 5 years in clang-format, and it was present
even earlier, so use it in meson as well.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-11-20 15:50:55 +08:00
|
|
|
parser.add_argument('--color', default='always')
|
2021-03-10 21:41:54 +08:00
|
|
|
parser.add_argument('sourcedir')
|
|
|
|
parser.add_argument('builddir')
|
|
|
|
options = parser.parse_args(args)
|
|
|
|
|
|
|
|
srcdir = Path(options.sourcedir)
|
|
|
|
builddir = Path(options.builddir)
|
2019-09-19 21:24:04 +08:00
|
|
|
|
|
|
|
exelist = detect_clangformat()
|
|
|
|
if not exelist:
|
|
|
|
print('Could not execute clang-format "%s"' % ' '.join(exelist))
|
|
|
|
return 1
|
|
|
|
|
2023-02-23 14:28:03 +08:00
|
|
|
if options.check:
|
|
|
|
cformat_ver = ExternalProgram('clang-format', exelist, silent=True).get_version()
|
|
|
|
else:
|
|
|
|
cformat_ver = None
|
|
|
|
|
2024-11-17 16:34:11 +08:00
|
|
|
return run_clang_tool('clang-format', srcdir, builddir, run_clang_format, exelist, options, cformat_ver)
|