CLion plugin doesn't support external_include_paths feature

[erinacio]

What was done

We opted-in bazel external_include_paths feature so that we can use #include<> for dependencies.

What is expected

We expect bazel and CLion plugin all work normally.

What happened actually

Bazel itself works while CLion plugin doesn't, still yelling that we should use #include"" instead.

Environment

• Bazel: 5.1.1, directly downloaded from github release page.
• CLion: 2022.1.3, Build #CL-221.5921.27
• CLion plugin: 2022.06.28.0.0-api-version-221
• OS: Arch Linux

More details?

The external_include_paths feature is from https://github.com/bazelbuild/bazel/pull/13107 (see also: https://github.com/bazelbuild/bazel/commit/08936aecb96f2937c61bdedfebcf1c5a41a0786d and https://github.com/bazelbuild/bazel/issues/12009), which allows us using #include<> for dependencies so that we don't get uninterested compilation warnings (or errors, if -Werror) from dependency headers. This feature is available from Bazel 5.0.0 and onwards. This feature is enabled by specifying build --features=external_include_paths in our .bazelrc file.

It works great on bazel 5.1.1 but not on CLion bazel plugin. IDE still flags errors for our #include<>s, like below:

Here gsl is introduced by http_archive with build_file_content set to a simple cc_library call since it's just a header-only library. abseil is introduced by http_archive directly because itself supports bazel. We can make gsl works with #include<> by adding includes=["."] to build_file_content provided by us, but we can't do the same thing for abseil without manually creating a patch adding includes arguments in all cc_library rules of it.

[tpasternak]

I don't know how to reproduce it, just tried with catch and it seems correct

WORKSPACE:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "bazel_skylib",
    sha256 = "b8a1527901774180afc798aeb28c4634bdccf19c4d98e7bdd1ce79d1fe9aaad7",
    urls = [
        "https://mirror.bazel.build/github.com/bazelbuild/bazel-skylib/releases/download/1.4.1/bazel-skylib-1.4.1.tar.gz",
        "https://github.com/bazelbuild/bazel-skylib/releases/download/1.4.1/bazel-skylib-1.4.1.tar.gz",
    ],
)

load("@bazel_skylib//:workspace.bzl", "bazel_skylib_workspace")

bazel_skylib_workspace()

http_archive(
    name = "catch2",
    sha256 = "8361907f4d9bff3ae7c1edb027f813659f793053c99b67837a0c0375f065bae2",
    strip_prefix = "Catch2-3.3.2",
    urls = ["https://github.com/catchorg/Catch2/archive/v3.3.2.tar.gz"],
)

BUILD:

cc_test(
    name = "test",
    srcs = ["test.cpp"],
    copts = ["-std=c++14"],
    deps = [
        "@catch2//:catch2_main",
    ],
)

[erinacio]

This issue was created months ago, and both CLion and Bazel plugin have been updated many times since then. Seems that this issue simply got resolved, maybe as a side effect of other fixes or optimizations.

[erinacio]

Turns out that the issue still exists. The previous test that I succeeded is caused by absl installed in the system include directory, not fetched by the bazel.

MRE:

.bazelrc

build --features=external_include_paths
build --cxxopt=-std=c++17

.bazelversion

6.2.0

WORKSPACE

workspace(name = "bzlexp")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "bazel_skylib",
    sha256 = "b8a1527901774180afc798aeb28c4634bdccf19c4d98e7bdd1ce79d1fe9aaad7",
    urls = [
        "https://mirror.bazel.build/github.com/bazelbuild/bazel-skylib/releases/download/1.4.1/bazel-skylib-1.4.1.tar.gz",
        "https://github.com/bazelbuild/bazel-skylib/releases/download/1.4.1/bazel-skylib-1.4.1.tar.gz",
    ],
)

http_archive(
    name = "com_google_absl",
    sha256 = "81311c17599b3712069ded20cca09a62ab0bf2a89dfa16993786c8782b7ed145",
    strip_prefix = "abseil-cpp-20230125.1",
    urls = [
        "https://github.com/abseil/abseil-cpp/archive/refs/tags/20230125.1.tar.gz",
    ],
)

BUILD.bazel

cc_binary(
    name = "main",
    srcs = ["main.cc"],
    deps = ["@com_google_absl//absl/strings"],
)

main.cc

#include <iostream>
#include <absl/strings/str_cat.h>

int main() {
    std::cout << "hello, world" << std::endl;
    return 0;
}

Using latest stable CLion with Bazel plugin 2023.05.16.0.1-api-version-231. Not using the latest version because it's so broken that make all sync failed. See https://github.com/bazelbuild/intellij/issues/4965 for details.

[erinacio]

I don't know how to reproduce it, just tried with catch and it seems correct

WORKSPACE:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "bazel_skylib",
    sha256 = "b8a1527901774180afc798aeb28c4634bdccf19c4d98e7bdd1ce79d1fe9aaad7",
    urls = [
        "https://mirror.bazel.build/github.com/bazelbuild/bazel-skylib/releases/download/1.4.1/bazel-skylib-1.4.1.tar.gz",
        "https://github.com/bazelbuild/bazel-skylib/releases/download/1.4.1/bazel-skylib-1.4.1.tar.gz",
    ],
)

load("@bazel_skylib//:workspace.bzl", "bazel_skylib_workspace")

bazel_skylib_workspace()

http_archive(
    name = "catch2",
    sha256 = "8361907f4d9bff3ae7c1edb027f813659f793053c99b67837a0c0375f065bae2",
    strip_prefix = "Catch2-3.3.2",
    urls = ["https://github.com/catchorg/Catch2/archive/v3.3.2.tar.gz"],
)

BUILD:

cc_test(
    name = "test",
    srcs = ["test.cpp"],
    copts = ["-std=c++14"],
    deps = [
        "@catch2//:catch2_main",
    ],
)

Not work for me though. This time the CLion just can't find the include file, even with #include "". But bazel build //... still works. I have no idea why.

[erinacio]

With further investigation, I found that @cache2//:cache2 and @cache2//:cache2_main both have includes. This will make #include<> work regardless of whether external_include_paths is enabled. In contrast, abseil-cpp has no includes in its public cc_library targets, so external_include_paths is required for #include<> to work. This issue still exists.

So why I said that I failed with cache hours ago? Turns out that enabling external_include_paths in .bazelrc will make bazel clion plugin ignore includes in all external cc_library targets. I will submit another issue with more details.