From de8b03faa3178ae683d8e7124fbcba81eb88e00c Mon Sep 17 00:00:00 2001 From: Chandler Carruth Date: Fri, 10 Jul 2026 09:16:28 -0700 Subject: [PATCH] Update to latest `rumdl` release and enable another option (#7483) The `style = "fixed"` is partially implied by `indent = 4`, but not fully in some specific cases. There were also bugs in fully applying it that are now fixed, and so we can specify it explicitly to get rumdl to canonicalize nested list indentation more thoroughly. Assisted-by: Antigravity with Gemini --- .agents/skills/builtins/SKILL.md | 60 +++++++++---------- .pre-commit-config.yaml | 2 +- .rumdl.toml | 1 + proposals/p000142-unicode-source-files.md | 18 +++--- ...p002665-semicolons-terminate-statements.md | 8 +-- proposals/p003720-member-binding-operators.md | 12 ++-- .../p003762-merging-forward-declarations.md | 2 +- proposals/p003938-exporting-imported-names.md | 28 ++++----- ...for-integer-and-floating-point-literals.md | 6 +- proposals/scripts/template.md | 2 +- utils/vscode/README.md | 6 +- utils/vscode/development.md | 10 ++-- 12 files changed, 78 insertions(+), 77 deletions(-) diff --git a/.agents/skills/builtins/SKILL.md b/.agents/skills/builtins/SKILL.md index 1fce41d39313..60c1dabff8a0 100644 --- a/.agents/skills/builtins/SKILL.md +++ b/.agents/skills/builtins/SKILL.md @@ -75,10 +75,10 @@ Inside the matching `SemIR` type instruction (such as `FloatType` or `FloatLiteralType`). Use pre-established semantic helpers: - - `TypeParam`: Ensures different parameters resolve to identical type - structures (e.g., generic constraint matching). - - `AnyInt`, `AnyFloat`, `AnySizedInt`, `AnySizedFloat`, `CharCompatible`, - `StdInitializerList`, `NoReturn`. + - `TypeParam`: Ensures different parameters resolve to identical type + structures (e.g., generic constraint matching). + - `AnyInt`, `AnyFloat`, `AnySizedInt`, `AnySizedFloat`, `CharCompatible`, + `StdInitializerList`, `NoReturn`. 2. **Map Literal Name & Register Constraint Signature**: Declare a `BuiltinInfo` constant inside `namespace BuiltinFunctionInfo` matching the macro-defined @@ -94,13 +94,13 @@ Inside 3. **Establish Compile-Time Residency Status**: Update `BuiltinFunctionKind::IsCompTimeOnly` to determine if a call requires compile-time evaluation: - - **Checked/Diagnostics Primitives**: Return `true` immediately. Runtime - lowering of these is illegal (e.g. `IntConvertFloatChecked`). - - **Runtime Primitives**: Return - `AnyLiteralTypes(sem_ir, arg_ids, return_type_id)` to enforce that - expressions involving unsized literal values (like `IntLiteral` or - `FloatLiteral`) are evaluated exclusively at compile-time (as they lack - runtime representation). + - **Checked/Diagnostics Primitives**: Return `true` immediately. Runtime + lowering of these is illegal (e.g. `IntConvertFloatChecked`). + - **Runtime Primitives**: Return + `AnyLiteralTypes(sem_ir, arg_ids, return_type_id)` to enforce that + expressions involving unsized literal values (like `IntLiteral` or + `FloatLiteral`) are evaluated exclusively at compile-time (as they lack + runtime representation). --- @@ -111,10 +111,10 @@ execute compile-time computations: 1. **Implement Constant Evaluation Logic**: - - Handle the builtin case inside `MakeConstantForBuiltinCall` (which - processes the compile-time execution of the call). - - Confirm type validation phase is `Phase::Concrete` to reject incomplete - bindings: + - Handle the builtin case inside `MakeConstantForBuiltinCall` (which + processes the compile-time execution of the call). + - Confirm type validation phase is `Phase::Concrete` to reject incomplete + bindings: ```cpp case SemIR::BuiltinFunctionKind::IntConvertFloat: { @@ -126,24 +126,24 @@ execute compile-time computations: } ``` - - Extract inputs safely from local value stores (e.g. - `context.ints().Get(arg.int_id)` or `context.floats().Get(arg.float_id)`). - - Leverage high-precision LLVM mathematical structures (`llvm::APInt`, - `llvm::APFloat`, `llvm::APSInt`) to handle custom bits and signedness - safely. + - Extract inputs safely from local value stores (e.g. + `context.ints().Get(arg.int_id)` or `context.floats().Get(arg.float_id)`). + - Leverage high-precision LLVM mathematical structures (`llvm::APInt`, + `llvm::APFloat`, `llvm::APSInt`) to handle custom bits and signedness + safely. 2. **Diagnose Invalid Parameters or Exceptions**: - - Define compile-time diagnostics inside - [kind.def](../../../toolchain/diagnostics/kind.def): + - Define compile-time diagnostics inside + [kind.def](../../../toolchain/diagnostics/kind.def): ```cpp // toolchain/diagnostics/kind.def CARBON_DIAGNOSTIC_KIND(IntTooLargeForFloatType) ``` - - Emplace localized diagnostic formatting messages where they are caught in - `eval.cpp`: + - Emplace localized diagnostic formatting messages where they are caught in + `eval.cpp`: ```cpp CARBON_DIAGNOSTIC(IntTooLargeForFloatType, Error, @@ -152,14 +152,14 @@ execute compile-time computations: context.emitter().Emit(loc_id, IntTooLargeForFloatType, val, dest_type_id); ``` - - Return `SemIR::ErrorInst::ConstantId` to gracefully abort invalid constant - generation rather than crashing the compiler. + - Return `SemIR::ErrorInst::ConstantId` to gracefully abort invalid constant + generation rather than crashing the compiler. 3. **Fast-Path Range Limits**: - - Before evaluating expensive math operations on giant exponents (e.g. - `1.0e1000000`), executing range limits check against `dest_width + 64` - (sized) or `IntStore::MaxIntWidth` (unsized) is mandatory to prevent - out-of-bounds calculations and compile-time memory exhaustion. + - Before evaluating expensive math operations on giant exponents (e.g. + `1.0e1000000`), executing range limits check against `dest_width + 64` + (sized) or `IntStore::MaxIntWidth` (unsized) is mandatory to prevent + out-of-bounds calculations and compile-time memory exhaustion. --- diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index 93907c63e2c5..c3d0ff03be93 100644 --- a/.pre-commit-config.yaml +++ b/.pre-commit-config.yaml @@ -51,7 +51,7 @@ repos: # Re-run markdown linting to fix any issues caused by doc style and TOC. This # is very fast, so it shouldn't be problematic to run twice. - repo: https://github.com/rvben/rumdl-pre-commit - rev: v0.2.22 + rev: v0.2.30 hooks: - id: rumdl args: [--fix] diff --git a/.rumdl.toml b/.rumdl.toml index a0ea3867f020..b20844e416dc 100644 --- a/.rumdl.toml +++ b/.rumdl.toml @@ -43,6 +43,7 @@ style = "one-or-ordered" # Unordered list indentation [MD007] +style = "fixed" indent = 4 [MD077] diff --git a/proposals/p000142-unicode-source-files.md b/proposals/p000142-unicode-source-files.md index 81b8bcc4a714..cb843adec837 100644 --- a/proposals/p000142-unicode-source-files.md +++ b/proposals/p000142-unicode-source-files.md @@ -103,15 +103,15 @@ The choice to require NFC is really four choices: 1. Equivalence classes: we use a canonical normalization form rather than a compatibility normalization form or no normalization form at all. - - If we use no normalization, invisibly-different ways of representing the - same glyph, such as with pre-combined diacritics versus with diacritics - expressed as separate combining characters, or with combining characters - in a different order, would be considered different characters. - - If we use a canonical normalization form, all ways of encoding diacritics - are considered to form the same character, but ligatures such as `ffi` are - considered distinct from the character sequence that they decompose into. - - If we use a compatibility normalization form, ligatures are considered - equivalent to the character sequence that they decompose into. + - If we use no normalization, invisibly-different ways of representing the + same glyph, such as with pre-combined diacritics versus with diacritics + expressed as separate combining characters, or with combining characters + in a different order, would be considered different characters. + - If we use a canonical normalization form, all ways of encoding diacritics + are considered to form the same character, but ligatures such as `ffi` are + considered distinct from the character sequence that they decompose into. + - If we use a compatibility normalization form, ligatures are considered + equivalent to the character sequence that they decompose into. For a fixed-width font, a canonical normalization form is most likely to consider characters to be the same if they look the same. Unicode annexes diff --git a/proposals/p002665-semicolons-terminate-statements.md b/proposals/p002665-semicolons-terminate-statements.md index 73095ef09298..aac34d7e4492 100644 --- a/proposals/p002665-semicolons-terminate-statements.md +++ b/proposals/p002665-semicolons-terminate-statements.md @@ -43,10 +43,10 @@ Statements need some system for separation. There are two main options for this: 1. Require semicolons to terminate statements. 2. Automatically determine where statements terminate. - - Some languages, such as Python, define a syntax where a newline terminates - statements. - - Other languages, such as Javascript, require semicolons but define rules - for semicolon insertion. + - Some languages, such as Python, define a syntax where a newline terminates + statements. + - Other languages, such as Javascript, require semicolons but define rules + for semicolon insertion. Although Carbon's design currently assumes semicolons are required, it hasn't been directly addressed by a proposal. diff --git a/proposals/p003720-member-binding-operators.md b/proposals/p003720-member-binding-operators.md index c133fb6b46af..26a6acbf1956 100644 --- a/proposals/p003720-member-binding-operators.md +++ b/proposals/p003720-member-binding-operators.md @@ -235,12 +235,12 @@ How does this arise? Note that `C.F` is `__C_F` with type `__TypeOf_C_F`, and `C.Static` is `__C_Static` with type `__TypeOf_C_Static`. 2. It then looks at the expression to the left of the `.`: - - If it is a facet value, the "member binding to type" (`BindToType`) - operator is applied. - - If it is a reference expression, the "member binding to reference" - (`BindToRef`) operator is applied. - - If it is a value expression, the "member binding to value" (`BindToValue`) - operator is applied. + - If it is a facet value, the "member binding to type" (`BindToType`) + operator is applied. + - If it is a reference expression, the "member binding to reference" + (`BindToRef`) operator is applied. + - If it is a value expression, the "member binding to value" (`BindToValue`) + operator is applied. 3. The result of the member binding has a type that implements the call interface. diff --git a/proposals/p003762-merging-forward-declarations.md b/proposals/p003762-merging-forward-declarations.md index 14d476c7be9f..42aeb74a3c33 100644 --- a/proposals/p003762-merging-forward-declarations.md +++ b/proposals/p003762-merging-forward-declarations.md @@ -193,7 +193,7 @@ declaration, only access modifiers are valid (see When considering whether a declaration is allowed, we apply the rules: 1. A declaration should always add new information. - - No declarations after a definition. + - No declarations after a definition. 2. Only one library can declare an entity without `extern`. 3. Support moving declarations between already-imported `api` files without affecting compilation of client libraries. diff --git a/proposals/p003938-exporting-imported-names.md b/proposals/p003938-exporting-imported-names.md index 172449719e78..be2b6e6a2cf9 100644 --- a/proposals/p003938-exporting-imported-names.md +++ b/proposals/p003938-exporting-imported-names.md @@ -259,15 +259,15 @@ on advantages and disadvantages for each option. Advantages: - - No need to teach developers they cannot (don't need to) `export` locally - introduced names. + - No need to teach developers they cannot (don't need to) `export` locally + introduced names. Disadvantages: - - Although the restricted placement might imply placement is tied to - specific libraries, that's not the case. This could mislead developers. - - In theory, we could enforce this, but then we could end up breaking - code if the path a name is imported through changes. + - Although the restricted placement might imply placement is tied to + specific libraries, that's not the case. This could mislead developers. + - In theory, we could enforce this, but then we could end up breaking + code if the path a name is imported through changes. 2. `export name` with other declarations @@ -276,15 +276,15 @@ on advantages and disadvantages for each option. Advantages: - - `import` remains very special. - - Makes it unambiguous that names valid for `export` are already imported. + - `import` remains very special. + - Makes it unambiguous that names valid for `export` are already imported. Disadvantages: - - Prevents placing `export name` next to the import that is expected to add - the name. - - Means `export import` and `export name` will be in different sections: no - single place to look for re-exports. + - Prevents placing `export name` next to the import that is expected to add + the name. + - Means `export import` and `export name` will be in different sections: no + single place to look for re-exports. 3. No ordering for `export name` @@ -292,11 +292,11 @@ on advantages and disadvantages for each option. Advantages: - - Maximum flexibility, HOA rule. + - Maximum flexibility, HOA rule. Disadvantages: - - Most inconsistent with the desire to treat `import` as special. + - Most inconsistent with the desire to treat `import` as special. We're choosing option (2). The name lookup issues avoided by requiring `export` be below `import` directives seem worthwhile. diff --git a/proposals/p006668-c-interop-type-mapping-for-integer-and-floating-point-literals.md b/proposals/p006668-c-interop-type-mapping-for-integer-and-floating-point-literals.md index 068f838bebba..10f5e19956f2 100644 --- a/proposals/p006668-c-interop-type-mapping-for-integer-and-floating-point-literals.md +++ b/proposals/p006668-c-interop-type-mapping-for-integer-and-floating-point-literals.md @@ -184,11 +184,11 @@ Carbon supports **decimal and hexadecimal** floating-point literals. Example: 1. Decimal: - - `123.456` - - `1.23456e791` + - `123.456` + - `1.23456e791` 2. Hexadecimal: - - `0x1.Ap123` + - `0x1.Ap123` #### Literal types diff --git a/proposals/scripts/template.md b/proposals/scripts/template.md index 98443c0bf3f8..366ccabe7379 100644 --- a/proposals/scripts/template.md +++ b/proposals/scripts/template.md @@ -29,7 +29,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception 1. Copy this template to `new.md`, and create a commit. 2. Create a GitHub pull request, to get a pull request number. - - Add the `proposal draft` label to the pull request. + - Add the `proposal draft` label to the pull request. 3. Rename `new.md` to `/proposals/p####.md`, where `####` should be the pull request number. 4. Update the title of the proposal (the `TODO` on line 1). diff --git a/utils/vscode/README.md b/utils/vscode/README.md index e71508e4b2e2..9aa678e3dead 100644 --- a/utils/vscode/README.md +++ b/utils/vscode/README.md @@ -15,9 +15,9 @@ This extension is currently experimental, and being developed alongside Carbon. 1. Download and install a `carbon` [release](https://github.com/carbon-language/carbon-lang/releases). - - By default, the extension will look for `carbon` under `./bazel-bin`. This - is for developers actively working on Carbon and running VS Code inside a - [carbon-lang](https://github.com/carbon-language/carbon-lang) clone. + - By default, the extension will look for `carbon` under `./bazel-bin`. This + is for developers actively working on Carbon and running VS Code inside a + [carbon-lang](https://github.com/carbon-language/carbon-lang) clone. 2. Install the [Carbon Language extension](https://marketplace.visualstudio.com/items?itemName=carbon-lang.carbon-vscode). 3. Configure the installed path to `carbon`. diff --git a/utils/vscode/development.md b/utils/vscode/development.md index d20c2aa9fcab..776fe1e90218 100644 --- a/utils/vscode/development.md +++ b/utils/vscode/development.md @@ -37,8 +37,8 @@ This installs `vsce` and `ovsx` to `/usr/local/bin`. Ensure that - Using the UI: 1. `npm install && vsce package -o carbon.vsix && realpath carbon.vsix` - - This installs dependencies, builds the VSIX file, and prints the - path. + - This installs dependencies, builds the VSIX file, and prints the + path. 2. Open the [command palette](https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette) and select "Extensions: Install from VSIX...". @@ -51,9 +51,9 @@ This installs `vsce` and `ovsx` to `/usr/local/bin`. Ensure that 1. `npm install && vsce package -o carbon.vsix && realpath carbon.vsix` 2. Go to https://marketplace.visualstudio.com/manage/publishers/carbon-lang - - We use `infra-role@carbon-lang.dev` for publishing; the GitHub - account `CarbonInfraBot` can also be used for login. Contact leads - if you require access. + - We use `infra-role@carbon-lang.dev` for publishing; the GitHub + account `CarbonInfraBot` can also be used for login. Contact leads + if you require access. 3. Next to the extension name, click the "..." and select "Update". 4. Select the `carbon.vsix` file. 3. Build and publish to the Open VSX Registry by following the