Skip to content

Check bugprone-unchecked-optional-access in Engine clang-tidy. #127701

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
2 tasks done
zanderso opened this issue May 26, 2023 · 6 comments
Closed
2 tasks done

Check bugprone-unchecked-optional-access in Engine clang-tidy. #127701

zanderso opened this issue May 26, 2023 · 6 comments
Labels
engine flutter/engine repository. See also e: labels. P2 Important issues not at the top of the work list team Infra upgrades, team productivity, code health, technical debt. See also team: labels.

Comments

@zanderso
Copy link
Member

zanderso commented May 26, 2023

There are a number of existing violations to work through (flutter/engine#42281), so we'll have to attack this in two stages:

@zanderso zanderso added team Infra upgrades, team productivity, code health, technical debt. See also team: labels. engine flutter/engine repository. See also e: labels. P2 Important issues not at the top of the work list labels May 26, 2023
@chinmaygarde
Copy link
Member

As I said here, we could also opt in all Impeller components by modifying the impeller_component template.

@zanderso
Copy link
Member Author

zanderso commented Jun 9, 2023

This check is now enabled in all non-unit test files. Unchecked access is a common pattern in unit tests, and the tests will fail on bad optional accesses, so the lint likely has limited value there. So I'll close this issue as done.

@zanderso zanderso closed this as completed Jun 9, 2023
@github-actions
Copy link

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 23, 2023
@flar
Copy link
Contributor

flar commented Aug 11, 2023

I'm just running into this now in the new DL geometry class tests where I have methods that return optional values. I would be happy if clang-tidy could be taught to recognize ASSERT_TRUE(result.has_value()); as protective since it returns if the test fails, but clang-tidy still warns about accesses in the subsequent code. There may be an issue in that ASSERT_TRUE is a macro that might not be expanded to return from the function in the environment under which clang-tidy is running? (But I thought it ran under host_debug which should have the macros functional?)

@flar
Copy link
Contributor

flar commented Aug 12, 2023

Meanwhile, I've had good luck with the following macro in my unit test files. I just switch to ENFORCE_TRUE(result.has_value()) and clang-tidy stops complaining...

// ASSERT_TRUE(result.has_value()) should be enough to prevent the test
// code that follows it to run, but clang-tidy doesn't seem to recognize
// that macro expansion as protective. This macro is more proactive
// about ending execution at the place where the statement lives.
#define ENFORCE_TRUE(condition) \
  do {                          \
    if (!(condition)) {         \
      ASSERT_TRUE(condition);   \
      return;                   \
    }                           \
  } while (0)

@zanderso
Copy link
Member Author

Yeah, due to this problem, we have the clang-tidy check disabled in most(all?) unit test files. If you have a good way forward, we should get that macro added to a common location, so that we can enable the check in more places.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
engine flutter/engine repository. See also e: labels. P2 Important issues not at the top of the work list team Infra upgrades, team productivity, code health, technical debt. See also team: labels.
Projects
None yet
Development

No branches or pull requests

3 participants