120 lines
6.5 KiB
Plaintext
120 lines
6.5 KiB
Plaintext
# GitHub Copilot Repository Instructions: C++ Modernization
|
|
|
|
## Project Context
|
|
- **Language:** C++
|
|
- **Target Standard:** C++23 (Strict enforcement)
|
|
- **Migration Goal:** Systematically upgrade legacy C++11/C++14/C++17 code to modern C++23 paradigms.
|
|
|
|
## Core Objective
|
|
Modernize the codebase incrementally and safely. Preserve existing behavior unless the task explicitly requests functional changes. Prefer small, reviewable refactors that improve correctness, safety, readability, and maintainability.
|
|
|
|
## Global Migration Principles
|
|
- Preserve semantics first; modernize second.
|
|
- Prefer standard C++23 library facilities over custom utilities where equivalent.
|
|
- Favor compile-time validation, explicit ownership, and strong type safety.
|
|
- Reduce boilerplate only when readability improves.
|
|
- Avoid unnecessary churn in code that is already modern and clear.
|
|
- Keep ABI-sensitive or externally exposed interfaces stable unless breaking changes are explicitly allowed.
|
|
- For larger migrations, refactor file-by-file or subsystem-by-subsystem.
|
|
|
|
## Migration Rules
|
|
|
|
### 1. Type Inference & Variables
|
|
- Replace explicit types with `auto` where the type is obvious from the initializer.
|
|
- Do not use `auto` when it obscures important type information or changes value/reference semantics unintentionally.
|
|
- Prefer `const auto` and `const auto&` where appropriate.
|
|
- Use structured bindings (`auto [x, y] = ...`) instead of `std::tie`, `.first/.second`, or tuple indexing where it improves clarity.
|
|
- Prefer uniform initialization where appropriate.
|
|
|
|
### 2. Memory & Resource Management
|
|
- Replace raw owning pointers and manual `delete` with `std::unique_ptr` or `std::shared_ptr`.
|
|
- Prefer `std::unique_ptr` by default; use `std::shared_ptr` only for true shared ownership.
|
|
- Use `std::make_unique` and `std::make_shared`.
|
|
- Enforce RAII for all resource management.
|
|
- Replace manual lifetime management with scoped objects where possible.
|
|
- Distinguish clearly between owning and non-owning access; prefer references, `std::span`, or observer-style usage for non-owning views.
|
|
|
|
### 3. Containers, Views & Strings
|
|
- Use `std::string_view` for read-only string parameters where lifetime safety is guaranteed.
|
|
- Never introduce dangling `std::string_view`.
|
|
- Replace `if (items.find(key) != items.end())` with `if (items.contains(key))` where supported.
|
|
- Prefer `.starts_with()`, `.ends_with()`, and `.contains()` when they improve readability.
|
|
- Prefer `std::span` for non-owning contiguous views.
|
|
- Use `std::mdspan` for multidimensional indexing only where it meaningfully improves safety or clarity.
|
|
- Prefer standard algorithms and ranges over manual loops when they improve readability and maintainability.
|
|
- Avoid unnecessary copies; prefer move semantics, `emplace`, and views where safe.
|
|
|
|
### 4. Control Flow & Error Handling
|
|
- Prefer early returns over deep nesting.
|
|
- Use `[[nodiscard]]` for functions whose return values should not be ignored.
|
|
- Modernize `std::optional` usage with `.and_then()`, `.transform()`, and `.or_else()` where this makes the logic clearer.
|
|
- Replace sentinel values with `std::optional`, strong types, or `std::expected` if supported by the project/toolchain.
|
|
- Preserve existing exception guarantees and error behavior unless changes are explicitly requested.
|
|
|
|
### 5. Formatting & Output
|
|
- Replace `printf` and legacy `<iostream>` console output with `<print>` where toolchain support exists.
|
|
- Use `std::print` and `std::println` for standard console output.
|
|
- If `<print>` is unavailable in the project toolchain, note the limitation and prefer the most modern supported alternative.
|
|
- Do not mix output styles in the same updated code path without a strong reason.
|
|
|
|
### 6. Compile-Time Optimization & Templates
|
|
- Maximize appropriate use of `constexpr`.
|
|
- Use `consteval` and `constinit` where semantically beneficial.
|
|
- Replace legacy SFINAE / `std::enable_if` with Concepts and `requires` clauses.
|
|
- Use `if constexpr` to simplify compile-time branching.
|
|
- Prefer readable template constraints and diagnostics over complex metaprogramming.
|
|
|
|
### 7. API & Interface Modernization
|
|
- Add `noexcept` where correct and useful.
|
|
- Use `override` consistently for overridden virtual functions.
|
|
- Use `final` where appropriate.
|
|
- Prefer `= default` and `= delete` for special member functions.
|
|
- Prefer `enum class` over unscoped enums where practical.
|
|
- Replace output parameters with return values or small result structs where this improves clarity and does not break required interfaces.
|
|
|
|
### 8. Concurrency & Time
|
|
- Prefer modern standard library concurrency primitives.
|
|
- Use `std::jthread` instead of `std::thread` where automatic joining and cancellation semantics are beneficial.
|
|
- Prefer typed `std::chrono` durations and literals over raw integer time values.
|
|
|
|
## Code Style Enforcement
|
|
- Avoid C-style macros where `constexpr`, `const`, enums, or inline functions are better.
|
|
- Never introduce deprecated or removed standard library facilities.
|
|
- Prefer expressive, self-documenting code over mechanical modernization.
|
|
- Keep includes minimal and correct.
|
|
- Avoid hidden lifetime bugs, dangling references, dangling views, and ownership ambiguity.
|
|
- Preserve repository formatting and local style conventions unless explicitly changing them.
|
|
|
|
## Safety Constraints
|
|
- Do not change business logic unless explicitly requested.
|
|
- Do not silently alter ownership semantics without calling it out.
|
|
- Do not replace code with newer constructs if the result is harder to read.
|
|
- Do not introduce C++23 features that are unsupported by the project compiler/toolchain.
|
|
- Highlight any modernization that may affect ABI, performance, exception behavior, or object lifetime.
|
|
|
|
## Review Checklist
|
|
For each proposed migration, verify:
|
|
- Behavior is preserved.
|
|
- Ownership and lifetime are clearer and safer.
|
|
- Readability is improved.
|
|
- Interface compatibility is maintained unless breaking changes are allowed.
|
|
- C++23 features are applied only where beneficial.
|
|
- Toolchain compatibility is respected.
|
|
- Tests and warnings should still pass after the change.
|
|
|
|
## Expected Copilot Behavior
|
|
When modernizing code:
|
|
1. Start from the existing implementation and refactor incrementally.
|
|
2. Prefer minimal, reviewable patches over broad rewrites.
|
|
3. Briefly explain non-trivial modernizations.
|
|
4. Call out risky or behavior-adjacent changes explicitly.
|
|
5. Provide optional follow-up refactors separately when they are useful but non-essential.
|
|
6. Avoid touching unrelated code.
|
|
|
|
## Preferred Output Format
|
|
For each migration task, provide:
|
|
- the modernized code,
|
|
- a short rationale,
|
|
- any compatibility/toolchain caveats,
|
|
- and optional next-step improvements.tes
|