Skip to content
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

Fix many compiler warnings #831

Open
wants to merge 13 commits into
base: master
Choose a base branch
from

Conversation

mhucka
Copy link
Member

@mhucka mhucka commented Dec 12, 2024

This fixes a large number of Bazel build and compiler warnings. Summary:

  • Fix various compiler warnings about type mismatches. Pretty much all of these concerned loop variables; the warnings concerned int's being used where unsigned int or vector size types should be used instead, to match the type of the value the loop variable was being compared against.
  • Fix compiler warnings about unused variables in tensorflow_quantum/core/src/circuit_parser_qsim.cc. These involved status return values from Abseil function calls. I replaced the code with simple testing of the return
    values, similar to how it was already done in one place in the file, and in a way that follows the recommendations from the Abseil docs.
  • Pull out the definition of function BalanceTrajectory from util_qsim.h into a separate file (util_balance_trajectory.cc), and make adjustments in the BUILD file and files that used the function. This was to eliminate repeated warnings about unused function BalanceTrajectory in files that included util_qsim.h. Also moved the relevant tests from util_qsim_test.cc to their own file.
  • Fix a "unused lambda capture" compiler warning in one file.
  • Fix a couple of sha256 hashes in the Bazel WORKSPACE file.
  • Add Bazel build options to configure.sh to silence warnings we can't do anything about because they're coming from packages included as a result of importing TensorFlow Bazel workspace files. The options are scoped as narrowly as possible to limit the impact of hiding warnings to specific cases.

I tested these changes with both gcc 14.2.0 and clang 17.0.6 on a Debian 6.10 Linux system.

The compiler complains about comparisons between int and unsigned int
in a handful of cases in these two files. The integers are being used
for loops, and it seems clear that unsigned int is a fine replacement
for signed in these cases.
This file produces many warnings of the form

```
tensorflow_quantum/core/src/circuit_parser_qsim.cc:185:8:
warning: variable 'unused' set but not used [-Wunused-but-set-variable]
  185 |   bool unused = absl::SimpleAtoi(op.qubits(0).id(), &q0);
      |        ^
```

Inspecting the code reveals that variable `unused` is indeed set but
never used. I replaced the code with simple testing of the return
values, similar to what is used in one place in the file, and in a way
that follows the recommendations from the Abseil docs.
One of the cases of lambda capture in this file resulted in warnings
of this sort:

```
tensorflow_quantum/core/ops/tfq_simulate_state_op.cc:154:29:
warning: lambda capture 'max_num_qubits' is not used [-Wunused-lambda-capture]
  154 |       auto copy_f = [i, nq, max_num_qubits, &output_tensor, &ss, &sv](
      |                           ~~^~~~~~~~~~~~~~
```

The parameter really was not used in the body. Removing it from the
lambda capture silenced the warning.
Previously, util_qsim.h included the definitions of the function
`BalanceTrajectory`. This led to compiler warnings about undefined
functions in places that included util_qsim.h but didn't use all
variants of `BalanceTrajectory`.

This refactor moves `BalanceTrajectory` to its own file
(util_balance_trajectory.cc), and also moves the relevant tests from
util_qsim_test.cc to the corresponding util_balance_trajectory.cc.
`INSTANTIATE_TEST_CASE_P` is deprecated and produces compilation
warnings. The replacement is `INSTANTIATE_TEST_SUITE_P`.
A number of harmless warnings during compilation come from third-party
things pulled in by the TFQ build rules. They involve things like
unused functions, unused variables, or (in the case of zlib) some
deprecated uses of prototypes. The best way to fix them would be in
the original source code, but in some cases this is impossible; for
example, we can't change what TensorFlow 2.15.0 needs. The second best
way would be to add patch rules in TFQ to adjust the code or the build
rules. I spent a couple of hours trying to figure out how to that for
the copy of zlib included by bazel_rules, but due to my still-limited
Bazel knowledge, I wasn't able to get the patching scheme working. So,
for the time being, and in consideration of the harmless nature of the
warnings, the approach taken here is to add compile-time per-file
flags that tell the compiler not to warn about the specific kinds of
problems that we know exist in the files involved.
Many files produced many type mismatch warnings with both clang 17 and
gcc 14 on a Debian 6.10.11 x86_64 system. This commit fixes almost all
the ones I'm seeing in the TFQ code base.

Some other warnings still arise in other code and modules. Those
warnings don't appear to be things we can easily work around short of
creating a lot of patch files (at significant cost in time and
testing). For those, I'm currently relying on setting compiler options
(e.g., `-Wno-unused-function` for warnings about unused functions)
narrowed in scope to the problematic package using Bazel's
`--per_file_copt` and `--host_per_file_copt` flags. Those flags are
not in this commit; they need to be made part of the TFQ
`configure.sh` script.
@mhucka mhucka added the area/code-health Concerns stability, quality, technical debt, etc. label Dec 12, 2024
In more recent versions of Python like 3.10, the `base64` package
changed APIs, and this in turn caused nbformat 4.4.0 to fail to work.
Updating to the latest version (5.1.3) solved that problem.

A minor tweak was also needed in scripts/format_ipynb.py to account
for a different error class being returned when "!pip ..." commands
are encountered in the notebook file.
After updating nbformat, running scripts/format_ipynb.py changed the
contents of all the ipython notebook files. Most frustratingly, one of
the changes is that the indentation of the .ipynb files changed,
making the diffs particularly noisy. Spot-inspecting files manually
reveals a number of real changes, some being worthwhile (e.g., adding
missing spaces in argument lists) and some being just differences in
formatting such as where line breaks are introduced. The latter set
of changes is puzzling because the style settings haven't changed. I
tried but couldn't find a way to avoid these changes except by
outright changing the style parameters, but then, that would mean the
TFQ .ipynb file formatting would become non-standard, and that seems
worse. So, for lack of a better solution, I'm checking in all the
reformatting notebooks with the hope that future versions of yapf and
nbformat don't keep introducing more .ipynb format changes.
Forgot to run the formatter.
Copy link

Check out this pull request on  ReviewNB

See visual diffs & provide feedback on Jupyter Notebooks.


Powered by ReviewNB

@mhucka mhucka marked this pull request as ready for review December 12, 2024 21:19
Copy link
Collaborator

@MichaelBroughton MichaelBroughton left a comment

Choose a reason for hiding this comment

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

This is pretty big and contains a lot of changes that don't have a lot to do with each other. Could we split this into a few smaller PRs ? Perhaps something like:

  1. The notebook format as it's own PR.
  2. The C++ type changes and some warning fixes.
  3. The refactoring of trajectory balancing.
  4. The introduction of the additional error checking in some of the parse code.

As it stands there is a lot going on in each of these areas and I worry if we miss things and require a rollback, we also won't have a commit history that lets us separate out things easily.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/code-health Concerns stability, quality, technical debt, etc.
Projects
Development

Successfully merging this pull request may close these issues.

2 participants