Due to the aspect working on the resolved alias targets but buildozer working on the plain BUILD files alias targets are a problem.
buildozer can't work directly with the targets from the report files, since they don't match the content of the BUILD in case of aliased targets.

However, buildozer can query the content of BUILD files. Maybe we are able to find the targets corresponding to the content of the report file.

Problem Description

Running DWYU on cc_grpc_library targets will fail with errmsg like below:

DWYU analyzing: '//proto:hello_world_cc_grpc'
Result: FAILURE
Includes which are not available from the direct dependencies:
  File='bazel-out/k8-fastbuild/bin/proto/hello_world.grpc.pb.h', include='grpcpp/impl/codegen/client_callback.h'
  File='bazel-out/k8-fastbuild/bin/proto/hello_world.grpc.pb.h', include='grpcpp/impl/codegen/message_allocator.h'
  File='bazel-out/k8-fastbuild/bin/proto/hello_world.grpc.pb.h', include='grpcpp/impl/codegen/server_context.h'
  File='bazel-out/k8-fastbuild/bin/proto/hello_world.grpc.pb.h', include='grpcpp/impl/codegen/method_handler.h'
  File='bazel-out/k8-fastbuild/bin/proto/hello_world.grpc.pb.h', include='grpcpp/impl/codegen/status.h'

See https://github.com/storypku/dwyu_grpc_demo.git, which was created to illestrate this issue.

Analysis

From DWYU's perspective, this issue was due to the missing direct dependency of @com_github_grpc_grpc//:grpc++_codegen_base. In fact, if @com_github_grpc_grpc//:grpc++_codegen_base was added to deps of //proto:hello_world_cc_proto, running DWYU will succeed.

However, since the cc_grpc_library rule was provided by gRPC, making changes to cc_grpc_library rule implementation seems a better solution for issues like this.

BTW, I have tried either adding grpcpp/impl/codegen stuff to DWYU's ignore headers list, or simply tagged cc_grpc_library targets as "no-dwyu", neither of them seems a good workaround.

Discussion Time

My question is, should we workaround this within DWYU or file an PR for upstream gRPC?

buildifier offers a linting mode which we do not yet utilize.

We are bumping to 0.0.11 and getting failures due to too long file names on Linux. The following is the file that is causing the issue:

src/aspect/dwyu.bzl:
output_path = "{}_processed_dep_{}.json".format(_label_to_name(target.label), _label_to_name(dep.label)),

Action <redacted>.json failed: failed to delete output files before executing action: <redacted>.json 

would it be possible to find a unique filename that is not as long?

When one provides a config it shall be possible to overwrite only a single value and not all or nothing.
For example only provide a fixed set of extra header to ignore, bit don't overwrite the standard headers.

Make sure we are compatible to changes introduced by: bazelbuild/bazel#19455

Continuation for the automatic fixes feature from #10

Offer a feature to move public dependencies which are used solely privately to the private dependency attribute for cc_library, given one uses the corresponding experimental Bazel feature.

Super excited to stumble onto your project :) I wrote a very similar tool for a hackathon! Happy to see your version integrated as a bazel aspect vs a tool built exclusively on top of bazel queries :P

https://github.com/martis42/depend_on_what_you_use/blob/main/src/analyze_includes/evaluate_includes.py#L98
I believe this line only allows for resolving headers that are full paths to the root of a workspace, however, if I have

- a/BUILD
cc_binary(
   name = "a",
   deps = "//b:headers"
)
- a/foo.cc
#include <b.h>
- b/BUILD
cc_library(
   name = "headers",
   hdrs = ["include/b.h"],
   includes = ["include"],
)
- b/include/b.h

This fails to resolve //a:a as using b.h from //b:b

Hi @martis42,

The link for the #Ensure-a-proper-split-between-public-and-private-dependencies section in top-level README.md (main branch) is broken at present.

Looks like fetch of one of pip packages fails, even though I am able to locate it in /var/cache/pip folder.

ERROR: An error occurred during the fetch of repository 'dwyu_py_deps_pcpp':
   Traceback (most recent call last):
        File "/bazel_cache/output_user_root/61da6a75bcd751b8ee01d9c498363d41/external/rules_python/python/pip_install/pip_repository.bzl", line 438, column 13, in _whl_library_impl
                fail("whl_library %s failed: %s (%s)" % (rctx.attr.name, result.stdout, result.stderr))
Error in fail: whl_library dwyu_py_deps_pcpp failed: Looking in links: /var/cache/pip
Collecting pcpp==1.30
  File was already downloaded /var/cache/pip/pcpp-1.30-py2.py3-none-any.whl
 (Traceback (most recent call last):
  File "/usr/lib/python3.8/runpy.py", line 194, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/bazel_cache/output_user_root/61da6a75bcd751b8ee01d9c498363d41/external/rules_python/python/pip_install/parse_requirements_to_bzl/extract_single_wheel/__main__.py", line 4, in <module>
    main()
  File "/bazel_cache/output_user_root/61da6a75bcd751b8ee01d9c498363d41/external/rules_python/python/pip_install/parse_requirements_to_bzl/extract_single_wheel/__init__.py", line 68, in main
    whl = next(iter(glob.glob("*.whl")))
StopIteration
)
ERROR:<STRIPPED>/WORKSPACE:1474:18: fetching whl_library rule //external:dwyu_py_deps_pcpp: Traceback (most recent call last):
        File "/bazel_cache/output_user_root/61da6a75bcd751b8ee01d9c498363d41/external/rules_python/python/pip_install/pip_repository.bzl", line 438, column 13, in _whl_library_impl
                fail("whl_library %s failed: %s (%s)" % (rctx.attr.name, result.stdout, result.stderr))
Error in fail: whl_library dwyu_py_deps_pcpp failed: Looking in links: /var/cache/pip
Collecting pcpp==1.30
  File was already downloaded /var/cache/pip/pcpp-1.30-py2.py3-none-any.whl
 (Traceback (most recent call last):
  File "/usr/lib/python3.8/runpy.py", line 194, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/bazel_cache/output_user_root/61da6a75bcd751b8ee01d9c498363d41/external/rules_python/python/pip_install/parse_requirements_to_bzl/extract_single_wheel/__main__.py", line 4, in <module>
    main()
  File "/bazel_cache/output_user_root/61da6a75bcd751b8ee01d9c498363d41/external/rules_python/python/pip_install/parse_requirements_to_bzl/extract_single_wheel/__init__.py", line 68, in main
    whl = next(iter(glob.glob("*.whl")))
StopIteration
)
ERROR: /bazel_cache/output_user_root/61da6a75bcd751b8ee01d9c498363d41/external/depend_on_what_you_use/src/analyze_includes/BUILD:4:11: @depend_on_what_you_use//src/analyze_includes:lib depends on @dwyu_py_deps_pcpp//:pkg in repository @dwyu_py_deps_pcpp which failed to fetch. no such package '@dwyu_py_deps_pcpp//': whl_library dwyu_py_deps_pcpp failed: Looking in links: /var/cache/pip
Collecting pcpp==1.30
  File was already downloaded /var/cache/pip/pcpp-1.30-py2.py3-none-any.whl
 (Traceback (most recent call last):
  File "/usr/lib/python3.8/runpy.py", line 194, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/bazel_cache/output_user_root/61da6a75bcd751b8ee01d9c498363d41/external/rules_python/python/pip_install/parse_requirements_to_bzl/extract_single_wheel/__main__.py", line 4, in <module>
    main()
  File "/bazel_cache/output_user_root/61da6a75bcd751b8ee01d9c498363d41/external/rules_python/python/pip_install/parse_requirements_to_bzl/extract_single_wheel/__init__.py", line 68, in main
    whl = next(iter(glob.glob("*.whl")))
StopIteration
)
ERROR: Analysis of aspects '[//:aspect.bzl%your_dwyu_aspect] with parameters {} on <TARGET>' failed; build aborted: 

bazel version: 6.3.2
dowyu version: 0.13

It seems one can perform the analysis of "using private headers" and "using headers from transitive dependencies" also by simply using the clang compiler with some specific settings: https://maskray.me/blog/2022-09-25-layering-check-with-clang

Bazel offers easy access to this through the layering_check feature of the default toolchain

• layering_check
• bazelbuild/bazel#17055

Example usage: bazel build --verbose //:foo --repo_env=CC=clang --features=layering_check

I'm trying to add "array" to the ignore_include_paths; however, this then causes issues with a custom include that also contains array in the name. I think it would be a simple fix to instead check the strings for equality, but this might break peoples current work flow. Wanted to open a discussion on what the best way to fix this would be!

While testing 0.0.5 on our repo I hit upon a suggestion from DWYU to use implementation_deps on my cc_test target. That attribute seems to only be available for cc_library. I couldn't find a test for this specific test. It should be fairly easy to recreate with use_implementation_deps = True and a cc_test, if not let me know and I will create a MWE, thanks.

Is the feature to analyze the dependency utilization indeed useful?

It is not part of the core DWYU concept to make sure only header from direct dependencies are used and no superfluous dependencies exist.
While the implementation of the feature is not complex it is still code which has to be tested, documented and maintained.
On top, the feature is not reliable when virtual includes are involved.
Furthermore, most likely an extension will be required to allow users to specify an allow list of dependencies where low utilizations are accepted for whatever reason.

Then again, having small targets allows building slim and efficient dependency trees and this feature can help with that.
Moving this into an own project seems wasteful, since the implementation would be mostly identical to DWYU.

Current ideas:

• Remove it, if user feedback for this is not positive. It is not part to invest much here, since it is not a core DWYU feature.
• If user feedback is positive, move it into an own tool/aspect but reuse the DWYU implementation.

Extend the documentation to explicitly explain why one should only use headers from direct dependencies.

Currently a Linux development PC is the only machine executing the tests.
A CI system would provide a neutral source for test results and enables to provide automated feedback to pull request authors.

Further reading on Bazel and GitHub actions: https://dev.to/davidb31/experimentations-on-bazel-github-action-5639

If we first run bazel build -c opt --config=dwyu //somepath/... then followed by a bazel run -c opt @depend_on_what_you_use//:apply_fixes -- --workspace=/path/to/my/project, apply fixes won't try to glob xxx_dwyu_report.json files under the actual bazel-bin directory:

ls -ld bazel-bin
lrwxrwxrwx 1 story story 93 May  8 17:30 bazel-bin -> /home/story/.cache/bazel/5f6cfd791ed6436cd7d0a9ad06515f99/execroot/com_qcraft/bazel-out/k8-opt/bin

shows that it was symlinked to some xxx/k8-opt/bin directory

However, the directory from running bazel info bazel-bin was xxx/k8-fastbuild/bin (See below).

$ bazel info bazel-bin
/home/story/.cache/bazel/5f6cfd791ed6436cd7d0a9ad06515f99/execroot/com_qcraft/bazel-out/k8-fastbuild/bin

Shall we use readlink bazel-bin rather than bazel info bazel-bin to locate the actual bazel-bin directory ?

look into https://github.com/renovatebot/renovate
Maybe we can use it to keep our pre-commit checks up to date

Hi, I'd like to propose using the tag no-dwyu to allow opting out of DWYU on specific targets.

We use some external dependencies which do not work with dwyu.

It would be extremely useful to be able to opt out of these checks for a few targets while still getting the benefits for all other targets.

seeing errors of the form:
Found multiple targets which potentially can provide include 'rt/libs/libspatial/mechanisms/ids.h' of target '@//rt/libs/libtrackingutils/state_trajectory_tracking:kcmpc'.
Please fix this manually. Candidates which have been discovered:

• //rt/libs/libkalman2:libkalman2
• //rt/libs/libspatial/mechanisms:ids
  It seems like the code might be confused, there are two header files named ids.h but they are each included with fully qualified paths, seems like the code might be missing that fact.

The aspect correctly detects unused implementation or interface deps (although tests are missing). But the report file does not contain the information which attribute holds the unused dependency and the apply_fixes script always assumes it s working with the deps attribute.

• Add tests for unused implementation_deps and interface_deps
• Add the dependency attribute containing the unused dependency to the report file
• Adapt the apply fixes script be able to remove dependencies from any dependency attribute
• Addd tests for automatically removing unused implementation_deps and interface_deps

I'm not sure if the issue I'm encountering depends on some miscofiguration on my part or it is a bug in the tool, but I'll report it here.
There are some configurations, even very simple ones, where using the use_implementation_deps=True flag creates unsatisfaiable requirements for dwyu if a target map is specified, even when the map itself is completely empty.

What follows is a simple example i was able to prepare

# MODULE.bazel
module(name = "example")

bazel_dep(name = "rules_cc", version = "0.0.9")
bazel_dep(name = "fmt", version = "10.2.1")
bazel_dep(name = "spdlog", version = "1.12.0")
bazel_dep(name = "depend_on_what_you_use", version = "0.0.0")
git_override(
    module_name = "depend_on_what_you_use",
    commit = "b817c225d79c492c25b28872445e34be4a36d5aa",
    remote = "https://github.com/martis42/depend_on_what_you_use",
)

# BUILD.bazel
load("@depend_on_what_you_use//:defs.bzl", "MAP_TRANSITIVE_DEPS", "dwyu_make_cc_info_mapping")

package(default_visibility = ["//visibility:public"])

exports_files([
    "ignore_includes.json",
])

# DWYU mappings
dwyu_make_cc_info_mapping(
    name = "dwyu_mapping",
    mapping = {
# Empty mapping
    },
)

# dwyu.bzl
load("@depend_on_what_you_use//:defs.bzl", "dwyu_aspect_factory")

dwyu = dwyu_aspect_factory(use_implementation_deps = True, recursive = True, skip_external_targets = True, target_mapping = Label("//:dwyu_mapping"))

# main/BUILD.bazel
load("@rules_cc//cc:defs.bzl", "cc_binary", "cc_library")

cc_library(
    name = "logging",
    hdrs = ["logging.h"],
    deps = ["@fmt", "@spdlog"],
)

cc_library(
    name = "lib",
    srcs = ["lib.cpp"],
    hdrs = ["lib.h"],
    # Commenting one and uncommenting the other does not satisfy dwyu
    # implementation_deps = [":logging"], 
    deps = [":logging"],
)

cc_binary(
    name = "main",
    srcs = ["main.cpp"],
    deps = [":lib"],
)

//----------------------------
// In main/lib.h

// Empty

//----------------------------
// In main/lib.cpp

#include "lib.h"
#include "logging.h"

//----------------------------
// In main/logging.h

#ifndef NLOG
#include <fmt/core.h>
#include <spdlog/spdlog.h>
#else
#endif

//----------------------------
// In main/main.cpp

#include "lib.h"

Running

bazel build --aspects=//:dwyu.bzl%dwyu --output_groups=dwyu //main

Output if using deps

================================================================================
DWYU analyzing: '@@//main:lib'

Result: FAILURE

Public dependencies which are used only in private code:
  Dependency='@@//main:logging'
================================================================================

Output if using implementation_deps

================================================================================
DWYU analyzing: '@@//main:lib'

Result: FAILURE

Includes which are not available from the direct dependencies:
  File='main/lib.cpp', include='logging.h'
================================================================================
Aspect //:dwyu.bzl%dwyu of //main:main failed to build

EDIT:

bazel version 7.1.1

The known limitations are caused by the complexity of all possible ways to include a header in C++.
The complexity is caused mainly by the preprocessor which allows dynamically adding include statements through macros and to enable/disable includes based on defines.

We could reimplement the preprocessor logic inside DWYU to support more complex include patterns.
The benefit would be that DYWU remains self-contained without external dependencies.
However, this would also be reinventing the wheel.
The C preprocessor is an old problem which has been solved many times until now.
Trying to implement and test a C preprocessor solely for the sake of prevent third party dependencies is wasteful.
The world does not need yet another C Preprocessor.

No design how to proceed has been made up yet.

The following tools could be part of the solution if we want to keep Python as implementation language:

• https://pypi.org/project/pcpp/
• https://github.com/paulross/cpip
• https://github.com/eliben/pycparser
• https://eli.thegreenplace.net/2011/07/03/parsing-c-in-python-with-clang

We could also move the implementation to C++.
The LLVM toolchain is a quite powerful toolset and allows interaction with the preprocessor.
See for example https://clang.llvm.org/doxygen/classclang_1_1Preprocessor.html#details.
LLVM is however not a lightweight dependency and having to compile DWYU will reduce its portability.

Yet another possibility is telling the compiler to generate a .d file, which lists the includes required for a given source file.
This provides an easy to parse output listing all include statements which are required after resolving macros and defines.
However, a first test shows all transitive headers are resolved.
This is a problem, since we need to know the include statements for the file under inspection, but not more.
If all transitive includes are listed as well, we cannot compare this list to the direct dependencies.
It is not yet known if this behavior can be modified.
6fb152f

Offer a function which allows loading the dependencies (e.g. rules_python). Should utilize maybe to allow others overwriting the version by loading the dependency upfront in a specific version.

Automatic fixes for alias targets do not work. DWYU reports the resolved alias. However, buildozer will fail to remove this resolved target from a dependency list. After all, the BUILD file has the alias in the dependency list and not the resolved target.

A separate tool could read all the report files generated by DWYU and then invoke buildozer to apply the fixes to the workspace.

At the beginning support removing unused dependencies

Bazel 5.0.0 introduced a new approach to manage external dependencies.
See bzlmod.

Currently we skip incompatible targets with this workaround

When we raise the minimum required Bazel version to one including the implementation of bazelbuild/bazel#15271, we should be able to remove this workaround.

We can resolve this when we raise the minimum Bazel version to 5.3.0.
See bazelbuild/bazel@a8db283 which cherry picks bazelbuild/bazel#15984 to 5.3.0

The get_includes_from_file function from parse_source.py will fail to find include for the following line:

/* commented out */ #include "abc.h" /* commented out */

Although such use case is rare.

In the near future we will raise the minimum required Python version from 3.6 to to 3.8.
There are multiple reasons for this:

• Python 3.7 is reaching soonish the end-of-life at 2023-06-27, see https://devguide.python.org/versions/
• One of the benefits when working with Bazel is the sandboxed execution and thus the high reproducability across different machines, given one uses a hermetic toolchains. rules_python offers ready to use hermetic Python toolchains. They are however only available for Python 3.8 and later.
• We can use more modern Python features. Some examples are dataclass and the leaner subprocess.run API.

If anybody has concerns regarding this, please comment here.

Invoking DWYU with Bazel 7 and implementation_deps activated on a cc_test target fails, which is why we have to disable the corresponding test.

Error:

ERROR: .../e663c61e10a8ed8d3fb71670c233b37b/external/local_jdk/BUILD.bazel:2:10: in fail_rule rule @local_jdk//:jdk: 
Traceback (most recent call last):
	File ".../e663c61e10a8ed8d3fb71670c233b37b/external/bazel_tools/tools/jdk/fail_rule.bzl", line 19, column 13, in _fail_rule_impl
		fail("%s %s" % (ctx.attr.header, ctx.attr.message))
Error in fail: Auto-Configuration Error: Cannot find Java binary bin/java in .../e96122088fa3cf13e8284bd38097b13e/embedded_tools/tools/jdk/nosystemjdk; either correct your JAVA_HOME, PATH or specify Java from remote repository (e.g. --java_runtime_version=remotejdk_11)
ERROR: .../e663c61e10a8ed8d3fb71670c233b37b/external/local_jdk/BUILD.bazel:2:10: Analysis of target '@local_jdk//:jdk' failed
ERROR: .../e663c61e10a8ed8d3fb71670c233b37b/external/remote_coverage_tools/BUILD:10:12: errors encountered resolving toolchains for @remote_coverage_tools//:Main
ERROR: Analysis of target '//test/aspect/implementation_deps:test_using_foo' failed; build aborted: 
INFO: Elapsed time: 0.154s
INFO: 0 processes.

TODO

Create a minimal example for reproducing and report upstream as regression for Bazel 7.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• chore(deps): update dependency typing-extensions to v4.12.1

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

We should be abe to process this:

#define MY_INCLUDE "some/header.h"
#include MY_INCLUDE 

Make sure aliases are not causing unexpected behavior

DWYU is mainly developed based on Python 3.8. However, some users use older Python versions. We should setup test execution with multiple Python versions to make sure support for old Python versions does not break.

This time, repro'ed within DWYU test case :)

looks like if you have a single build rule with two headers in sub directories, one including the other, DWYU doesn't find the locally sourced header.

Tested with:
bazel build --aspects=//my_awesome:aspect.bzl%your_dwyu_aspect --output_groups=cc_dwyu_output --override_repository=depend_on_what_you_use=/home/michael.johnson/code/depend_on_what_you_use @depend_on_what_you_use//test/aspect/includes:includes2

0001-Add-relative-include.patch

Code generators often use tree artifacts to model their outputs.
DWYU should support those as well.

I think a regression was introduced in a31db72 and is not working on latest.

We have the following module:

$ tree foo/
foo/
├── BUILD.bazel
├── foo.h
└── src
    ├── foobar.h
    └── foo.cpp

$ cat foo/BUILD.bazel 
cc_library(
    name = "foo",
    srcs = [
        "src/foo.cpp",
        "src/foobar.h",
    ],
    hdrs = [
        "foo.h",
    ],
    deps = [],
)

$ cat foo/src/foo.cpp 
#include "foo/foo.h"

#include "foobar.h"
// #include "foo/src/foobar.h"  // changing to this makes it work again.

int foobar()
{
    return 42;
}

================================================================================
DWYU analyzing: '@//foo:foo'

Result: FAILURE

Includes which are not available from the direct dependencies:
  File='foo/src/foo.cpp', include='foobar.h'
================================================================================

This worked fine in f2ecd05. Was this change intentional or unintentional?

Right now we maintain an allow list of headers which one can use without dedicated dependency.
If the aspect would depend on the active CC toolchain and query the headers which are available through the toolchain, we might be able to remove this manually maintained list of standard headers.

Hi,
I'm experiencing incredibly long run times when I run the script that applies the fixes.

I'm doing this on a single target, the actual dwyu run takes just a handful of seconds, and then I run bazel run @depend_on_what_you_use//:apply_fixes -- --fix-all and it runs for hours. I kid you not. Hours.

Am I doing something wrong? Is it stuck on something but not telling me ?
Do you have any tips for me so that I can provide more useful information without posting here my company's code ?

Thanks!

Currently I cannot invest much time into this project.

You can expect me to answers questions, but I won't be able to perform much coding.
I am however still very much interested in this project. I intend to invest more time into this again in autumn and to reach version 1.0.0 before Bazel 6.0.0 is released.

Followup to #18

Currently the feature to automatically add missing direct dependencies does not consider if a discovered dependency is visible to the target under inspection.

Assuming we make no error in matching include statement to target, there are 2 cases we can resolve by implementing this:

• If multiple targets in the dependency tree provide a given header we skip this right now with a warning. With visibility we could potentially decide which target to choose.
• Even if we find only a single dependency, it might be invalid. If aliases are involved we might add a target which breaks the build, although the added dependency provides the required header.

In the near future we will raise the minimum required Bazel version from 4.0.0 to to 5.0.0.
There are multiple reasons for this:

• Bazel is a rapidly developing tool. We aim to be up to date with the latest developments. Version 4.0.0 will reach end of life in 2023 either way.
• Many of the established rule sets already require a Bazel. version > 5.0.0.
• Several integration tests don't work with Bazel < 5.0.0.
• One of the main features of DWYU is enforcing implementation_deps which is only available starting with Bazel 5.0.0.
• We want to support the new dependency management concept bzlmod eventually, which is however only available starting with Bazel 5.0.0.

If anybody has concerns regarding this, please comment here.

When the minimum Bazel version is new enough that we can expect all users to have set --incompatible_visibility_private_attributes_at_definition or it being enforced by Bazel, we should restrict the visibility of our implementation details.

Hi!

I was wondering if there are plans for adding some sort of "export" functionality to DWYU, similar to the equivalent functionality in IWYU. We currently have issues on googletests, because DWYU forces us to duplicate the deps:

        "@googletest//:gtest",
        "@googletest//:gtest_main",

It would be great if we could tell DWYU that gtest_main exports gtest, so it's fine to include only gtest_main.

Thanks!

Right now we only process defines which are set inside a file under inspection or are injected through Bazel (rule attributes, toolchain, ...).
If a define X is set in a header A which is included in file B, parsing file B is treating X as undefined.

By improving how we manage include paths and make them available to the code parser and pcpp preprocessor, we should be able to resolve this.

Continuation for the automatic fixes feature from #10

When detecting a header which is not available from a direct dependency query the workspace for the target providing the header and suggest using it.

Follow up on an issue raised in #39

If one performs the apply_fixes script multiple times, consecutive runs will fail due to the report files being outdated and the issues already being resolved.

A solution proposal does not yet exist. It would be trivial to consume the report files by deleting them after using them as input. However, this would meddle with bazel-out, which seems like a hack.