Skip to content
This repository was archived by the owner on Feb 25, 2025. It is now read-only.

clang-tidy: Added an environment variable that allows fix to print the generated diff. #37024

Merged
merged 1 commit into from
Nov 7, 2022
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 21 additions & 1 deletion ci/lint.sh
Original file line number Diff line number Diff line change
Expand Up @@ -36,6 +36,15 @@ DART="${DART_BIN}/dart"
# to have this as an error.
MAC_HOST_WARNINGS_AS_ERRORS="performance-move-const-arg,performance-unnecessary-value-param"

# FLUTTER_LINT_PRINT_FIX will make it so that fix is executed and the generated
# diff is printed to stdout if clang-tidy fails. This is helpful for enabling
# new lints.
if [[ -z "${FLUTTER_LINT_PRINT_FIX}" ]]; then
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of using an environment variable, I think it would be simpler to just test for the presence of --fix in $@.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did that at first, but that makes it hard to use with the bots since $@ is changed in the bot configuration. This way you can just edit lint.sh file temporarily with FLUTTER_LINT_PRINT_FIX=1

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, okay, I get it (I think). So the workflow is to modify the script on a PR branch to get the presubmit checks to generate the diff?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, that's the best I could come up with for now. Alternatively we could always execute with --fix but I worry about execution time.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally, we'd have something like flutter/flutter#114085, to pass the --fix flag only in presubmit. In the meantime, I think this change is okay. Would you mind adding a TODO in the code for me that links to that issue?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We definitely care about postsubmit cycle time.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I wouldn't say they have equal weight though. Given that if there is a failure, turning this on and running again takes ~1hr to get results, it might be worth running it always. So the calculus as-to wether this should be turned on always or not should be: (likelihood of violation * 1hr) - ((1 - likelihood of violation) * 5min).

Let me run some tests locally since that 5 minute I just pulled out of my butt. Maybe it isn't so bad to always have it on. Also, maybe the real solution to performance isn't turning off something that is helpful and saves time but to do better sharding. I discuss this in the post-mortem I just sent. Now that I talk about this I think it's better to having this turn on always, assuming it doesn't add a crazy amount of time. I'll measure it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just ran it locally with a diff that was checking 47 files, there was a 12.5% increase in execution time so ~7.5 minutes longer to execute for one that takes ~1 hr.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, here is my suggestion:

  1. We add a new builder that runs only in pre-submit.
  2. It passes the --fix flag
  3. It only runs when .clang-tidy or engine tree source files have changed.

The new builder definition (one example) would looks something like this: #37082

The missing piece is a new parameter to the engine_lint.py recipe to trigger the logic in this PR around the --fix flag, which would go here:

https://flutter.googlesource.com/recipes/+/refs/heads/main/recipes/engine/engine_lint.proto#8

and here

https://flutter.googlesource.com/recipes/+/refs/heads/main/recipes/engine/engine_lint.py#55

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should land this as is for now. This was helpful for me for now. Let's see about turning it on by default if we get feedback from the team that addressing the lints across multiple platforms is a pain. In normal usage this might not be a big deal and more for when migrating new lint flags. Once we land sharding we'll have some more breathing room to do the fix if we want since it is reducing the number of files linted from ~800 to ~600 that should still leave us ahead.

fix_flag=""
else
fix_flag="--fix"
fi

COMPILE_COMMANDS="$SRC_DIR/out/host_debug/compile_commands.json"
if [ ! -f "$COMPILE_COMMANDS" ]; then
(cd "$SRC_DIR"; ./flutter/tools/gn)
Expand All @@ -47,7 +56,18 @@ cd "$SCRIPT_DIR"
"$SRC_DIR/flutter/tools/clang_tidy/bin/main.dart" \
--src-dir="$SRC_DIR" \
--mac-host-warnings-as-errors="$MAC_HOST_WARNINGS_AS_ERRORS" \
"$@"
$fix_flag \
"$@" && true # errors ignored
clang_tidy_return=$?
if [ $clang_tidy_return -ne 0 ]; then
if [ -n "$fix_flag" ]; then
echo "###################################################"
echo "# Attempted to fix issues with the following patch:"
echo "###################################################"
git --no-pager diff
fi
exit $clang_tidy_return
fi

cd "$FLUTTER_DIR"
pylint-2.7 --rcfile=.pylintrc \
Expand Down