| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 4 | 5 | 0% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 0 | 3 | 0 | 0% |
What each file covers
Sections
0 shared · 4 only in A · 5 only in B- − gRPC C++ Agents Collaboration Guide
- − Preferred Tools & Libraries
- − Code Style & Conventions
- − About gRPC
- + gRPC Server
- + Overarching Purpose
- + Files
- + Major Classes
- + Notes
Commands
neither file has anySection tags
0 shared · 3 only in A · 0 only in B- − code-style
- − dependencies
- − do-not
Line diff
grpc/grpc · AGENTS.md
@@ −1 @@
1# gRPC C++ Agents Collaboration Guide
2
3This document outlines conventions and best practices for AI-assisted development in the gRPC C++ codebase.
4
5## Preferred Tools & Libraries
6* Prefer gRPC types before absl.
7* Prefer std types when available, use absl types when not
8* Prefer `std::optional` over `absl::optional`
9* gRPC uses C++17, so we can't use C++20 onwards types.
10* The Python implementation cannot depend on the protobuf library, so any shared libraries must expose a C-style API that does not rely on C++ protobuf types.
11
12## Code Style & Conventions
13* `#include <grpc/support/port_platform.h>` is not required unless its macros are needed for compilation.
14* Only include headers that are actively used.
15* Abseil headers are sorted before gRPC headers.
16* For public api headers (in `include/grpc`) we use `<grpc/...>`.
17 * Example: `#include <grpc/grpc.h>`
18* Prefer explicit types over `std::pair` or `std::tuple` for return types.
19* Use `LOG(ERROR)` from `absl/log/log.h` for logging errors, never use `std::cerr` or `gpr_log`.
20* The `fuzztest.h` header is located at `fuzztest/fuzztest.h`.
21
22## About gRPC
23* gRPC uses its own macros for Bazel libraries, tests, etc. Each directory should have a `grpc_package` declaration. For libraries use `grpc_cc_library`, for tests `grpc_cc_test`.
24* Dependencies on non-gRPC libraries (like gtest or absl) are listed in the `external_deps` attribute.
25* The `:grpc` BUILD target is not allowed to depend on the C++ protobuf library, either directly or transitively.
26* Build files for implementation code are typically located in `src/core/BUILD` and `BUILD`. Do not add new `BUILD` files under the `src/` tree without explicit instruction.
27* Tests are located in `test/core` and `test/cpp` (corresponding to the `src` directories). These test directories contain their own `BUILD` files.
28* Fuzz tests use `fuzztest_main` instead of `gtest_main`.
29* When depending on a `grpc_proto_library`, the name of the `cc_library` target is the same as the `name` of the `grpc_proto_library` rule itself, not `[name]_cc_proto` as one might expect from standard Bazel `cc_proto_library` rules. The build system error messages can be misleading in this case.
30* The 'gtest' external_dep also includes 'gmock'.
31* All `upb` related build rules (`grpc_upb_proto_library`, `grpc_upb_proto_reflection_library`) for protos defined anywhere in the repository must be defined in the root `BUILD` file. They should not be placed in the `BUILD` file of the subdirectory where the proto is located.
32* Core end-to-end tests are defined in `test/core/end2end/BUILD` using the `grpc_core_end2end_test_suite` macro. This macro generates multiple `grpc_cc_test` targets by combining a configuration file (like `end2end_http2_config.cc`) with individual test implementation files located in `test/core/end2end/tests/`. The final test target name is created by appending `_test` to the `name` attribute of the macro. For example, `grpc_core_end2end_test_suite(name = "end2end_http2", ...)` generates the test target `//test/core/end2end:end2end_http2_test`.
33* Unused named parameters is a compilation failure.
34
grpc/grpc · src/core/server/AGENTS.md
@@ +1 @@
1# gRPC Server
2
3This directory contains the core implementation of the gRPC server.
4
5## Overarching Purpose
6
7The gRPC server is responsible for listening for incoming connections, handling requests, and sending responses. It is the main entry point for all server-side gRPC applications.
8
9## Files
10
11- **`server.h` / `server.cc`**: Defines the `Server` class, which is the main class for the gRPC server.
12- **`server_interface.h`**: Defines the `ServerInterface` class, which is an interface that can be used to interact with the server.
13- **`add_port.cc`**: Contains the implementation of the `grpc_server_add_http2_port` function, which is used to add a listening port to the server.
14- **`server_call_tracer_filter.h` / `server_call_tracer_filter.cc`**: Defines a filter that can be used to trace server-side calls.
15- **`server_config_selector.h`**: Defines the `ServerConfigSelector` class, which is used to select the server configuration for a given request.
16- **`server_config_selector_filter.h` / `server_config_selector_filter.cc`**: Defines a filter that uses the `ServerConfigSelector` to select the server configuration.
17- **`xds_channel_stack_modifier.h` / `xds_channel_stack_modifier.cc`**: Defines a class that can be used to modify the channel stack for XDS-enabled servers.
18- **`xds_server_config_fetcher.cc`**: Fetches server configuration from an XDS server.
19
20## Major Classes
21
22- **`grpc_core::Server`**: The main class for the gRPC server.
23- **`grpc_core::ServerInterface`**: An interface that can be used to interact with the server.
24- **`grpc_core::ServerConfigSelector`**: A class that is used to select the server configuration for a given request.
25
26## Notes
27
28- The gRPC server is a complex piece of software with many different components.
29- The `Server` class is the main entry point for all server-side gRPC applications.
30- The `ServerBuilder` class can be used to create and configure a `Server` instance.
31- The server can be configured with a variety of options, including the number of threads, the maximum number of concurrent requests, and the security credentials to use.
32
@@ −1 +1 @@
1−# gRPC C++ Agents Collaboration Guide
1+# gRPC Server
22
3−This document outlines conventions and best practices for AI-assisted development in the gRPC C++ codebase.
3+This directory contains the core implementation of the gRPC server.
44
5−## Preferred Tools & Libraries
6−* Prefer gRPC types before absl.
7−* Prefer std types when available, use absl types when not
8−* Prefer `std::optional` over `absl::optional`
9−* gRPC uses C++17, so we can't use C++20 onwards types.
10−* The Python implementation cannot depend on the protobuf library, so any shared libraries must expose a C-style API that does not rely on C++ protobuf types.
5+## Overarching Purpose
116
12−## Code Style & Conventions
13−* `#include <grpc/support/port_platform.h>` is not required unless its macros are needed for compilation.
14−* Only include headers that are actively used.
15−* Abseil headers are sorted before gRPC headers.
16−* For public api headers (in `include/grpc`) we use `<grpc/...>`.
17− * Example: `#include <grpc/grpc.h>`
18−* Prefer explicit types over `std::pair` or `std::tuple` for return types.
19−* Use `LOG(ERROR)` from `absl/log/log.h` for logging errors, never use `std::cerr` or `gpr_log`.
20−* The `fuzztest.h` header is located at `fuzztest/fuzztest.h`.
7+The gRPC server is responsible for listening for incoming connections, handling requests, and sending responses. It is the main entry point for all server-side gRPC applications.
218
22−## About gRPC
23−* gRPC uses its own macros for Bazel libraries, tests, etc. Each directory should have a `grpc_package` declaration. For libraries use `grpc_cc_library`, for tests `grpc_cc_test`.
24−* Dependencies on non-gRPC libraries (like gtest or absl) are listed in the `external_deps` attribute.
25−* The `:grpc` BUILD target is not allowed to depend on the C++ protobuf library, either directly or transitively.
26−* Build files for implementation code are typically located in `src/core/BUILD` and `BUILD`. Do not add new `BUILD` files under the `src/` tree without explicit instruction.
27−* Tests are located in `test/core` and `test/cpp` (corresponding to the `src` directories). These test directories contain their own `BUILD` files.
28−* Fuzz tests use `fuzztest_main` instead of `gtest_main`.
29−* When depending on a `grpc_proto_library`, the name of the `cc_library` target is the same as the `name` of the `grpc_proto_library` rule itself, not `[name]_cc_proto` as one might expect from standard Bazel `cc_proto_library` rules. The build system error messages can be misleading in this case.
30−* The 'gtest' external_dep also includes 'gmock'.
31−* All `upb` related build rules (`grpc_upb_proto_library`, `grpc_upb_proto_reflection_library`) for protos defined anywhere in the repository must be defined in the root `BUILD` file. They should not be placed in the `BUILD` file of the subdirectory where the proto is located.
32−* Core end-to-end tests are defined in `test/core/end2end/BUILD` using the `grpc_core_end2end_test_suite` macro. This macro generates multiple `grpc_cc_test` targets by combining a configuration file (like `end2end_http2_config.cc`) with individual test implementation files located in `test/core/end2end/tests/`. The final test target name is created by appending `_test` to the `name` attribute of the macro. For example, `grpc_core_end2end_test_suite(name = "end2end_http2", ...)` generates the test target `//test/core/end2end:end2end_http2_test`.
33−* Unused named parameters is a compilation failure.
9+## Files
10+
11+- **`server.h` / `server.cc`**: Defines the `Server` class, which is the main class for the gRPC server.
12+- **`server_interface.h`**: Defines the `ServerInterface` class, which is an interface that can be used to interact with the server.
13+- **`add_port.cc`**: Contains the implementation of the `grpc_server_add_http2_port` function, which is used to add a listening port to the server.
14+- **`server_call_tracer_filter.h` / `server_call_tracer_filter.cc`**: Defines a filter that can be used to trace server-side calls.
15+- **`server_config_selector.h`**: Defines the `ServerConfigSelector` class, which is used to select the server configuration for a given request.
16+- **`server_config_selector_filter.h` / `server_config_selector_filter.cc`**: Defines a filter that uses the `ServerConfigSelector` to select the server configuration.
17+- **`xds_channel_stack_modifier.h` / `xds_channel_stack_modifier.cc`**: Defines a class that can be used to modify the channel stack for XDS-enabled servers.
18+- **`xds_server_config_fetcher.cc`**: Fetches server configuration from an XDS server.
19+
20+## Major Classes
21+
22+- **`grpc_core::Server`**: The main class for the gRPC server.
23+- **`grpc_core::ServerInterface`**: An interface that can be used to interact with the server.
24+- **`grpc_core::ServerConfigSelector`**: A class that is used to select the server configuration for a given request.
25+
26+## Notes
27+
28+- The gRPC server is a complex piece of software with many different components.
29+- The `Server` class is the main entry point for all server-side gRPC applications.
30+- The `ServerBuilder` class can be used to create and configure a `Server` instance.
31+- The server can be configured with a variety of options, including the number of threads, the maximum number of concurrent requests, and the security credentials to use.
3432
