mirror of
https://github.com/carbon-language/carbon-lang.git
synced 2026-09-24 13:50:10 +01:00
Switch from Prettier to Rumdl for Markdown formatting (#7423)
Rumdl already appears to have _significantly_ fewer bugs than prettier, and a solid LSP for editor integration. The tool is: https://github.com/rvben/rumdl/ I've separated out the change across three commits for easier review. The configuration tries to match the existing formatting, the changes to the all the files are to correct issues found by the new tool. Assisted-by: Antigravity with Gemini --------- Co-authored-by: Richard Smith <richard@metafoo.co.uk>
This commit is contained in:
Chandler Carruth
co-authored by
Richard Smith
Richard Smith
parent
6181259cf1
commit
cfd1ed8484
@@ -115,6 +115,7 @@ execute compile-time computations:
|
||||
processes the compile-time execution of the call).
|
||||
- Confirm type validation phase is `Phase::Concrete` to reject incomplete
|
||||
bindings:
|
||||
|
||||
```cpp
|
||||
case SemIR::BuiltinFunctionKind::IntConvertFloat: {
|
||||
if (phase != Phase::Concrete) {
|
||||
@@ -124,6 +125,7 @@ execute compile-time computations:
|
||||
/*require_exact=*/false);
|
||||
}
|
||||
```
|
||||
|
||||
- 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`,
|
||||
@@ -134,18 +136,22 @@ execute compile-time computations:
|
||||
|
||||
- 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`:
|
||||
|
||||
```cpp
|
||||
CARBON_DIAGNOSTIC(IntTooLargeForFloatType, Error,
|
||||
"integer value {0} too large for floating-point type {1}",
|
||||
llvm::APSInt, SemIR::TypeId);
|
||||
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.
|
||||
|
||||
@@ -180,6 +186,7 @@ Inside [handle_call.cpp](../../../toolchain/lower/handle_call.cpp):
|
||||
2. **Assert on Compile-Time-Only Builtins**: Throw a hard assertion on
|
||||
lowering-cases for checked validator builtins that should never hit code
|
||||
generation:
|
||||
|
||||
```cpp
|
||||
case SemIR::BuiltinFunctionKind::IntConvertFloatChecked: {
|
||||
CARBON_CHECK(builtin_kind.IsCompTimeOnly(
|
||||
@@ -198,9 +205,11 @@ builtins under [core/prelude/](../../../core/prelude/):
|
||||
|
||||
- **Primitive Mappings**: Bind Carbon methods directly to string-literal
|
||||
builtin equivalents:
|
||||
|
||||
```carbon
|
||||
fn Convert[self: Self]() -> Float(To) = "int.convert_float";
|
||||
```
|
||||
|
||||
- **Strict Orphan Rule Compliance**: Carbon's orphan rules prohibit
|
||||
implementing interfaces where neither the type nor the interface is locally
|
||||
defined in the backing source module.
|
||||
|
||||
@@ -74,6 +74,7 @@ declaration (`CARBON_DIAGNOSTIC` or `CARBON_DIAGNOSTIC_ON_SCOPE`).
|
||||
- **Local Scope (Recommended)**: If the diagnostic is unique to a single
|
||||
block/function body, declare it **locally** inside the function body
|
||||
adjacent to its `Emit` trigger:
|
||||
|
||||
```cpp
|
||||
void ConvertFloatValueToInt(...) {
|
||||
CARBON_DIAGNOSTIC(FloatNaNConvertedToInt, Error,
|
||||
@@ -81,6 +82,7 @@ declaration (`CARBON_DIAGNOSTIC` or `CARBON_DIAGNOSTIC_ON_SCOPE`).
|
||||
context.emitter().Emit(loc_id, FloatNaNConvertedToInt, dest_type_id);
|
||||
}
|
||||
```
|
||||
|
||||
- **File Scope**: If the diagnostic is shared among multiple functions inside
|
||||
the _same_ file, declare it at **file scope** inside the anonymous namespace
|
||||
of the `.cpp` file.
|
||||
@@ -177,12 +179,14 @@ scopes:
|
||||
|
||||
- `ContextScope`: Automatically converts any diagnostics emitted within its
|
||||
scope into sub-notes under a high-level operation descriptor:
|
||||
|
||||
```cpp
|
||||
ContextScope context_scope(&context.emitter(), [&](ContextBuilder& builder) {
|
||||
builder.Context(eval_loc, InCallToEvalFn);
|
||||
});
|
||||
// any checker error emitted here will automatically append the 'InCallToEvalFn' note
|
||||
```
|
||||
|
||||
- `AnnotationScope`: RAII block scope that automatically attaches blanket note
|
||||
annotations to all scoped diagnostics.
|
||||
|
||||
@@ -246,10 +250,12 @@ Carbon strictly enforces testing coverage at build-time.
|
||||
2. **Stderr Checklist Matchers**: The testcase split verifying the diagnostic
|
||||
must catch it using standard CHECK matchers, explicitly tracking the
|
||||
matching enum tag in standard error comments:
|
||||
|
||||
```carbon
|
||||
// CHECK:STDERR: fail_bounds.carbon:[[@LINE+1]]:15: error: cannot convert NaN to integer type `i32` [FloatNaNConvertedToInt]
|
||||
let a: i32 = Convert(nan_val);
|
||||
```
|
||||
|
||||
3. **Build Enforcement**: Failing to provide a diagnostic test check matcher
|
||||
triggers a build compilation error on the target test
|
||||
`//toolchain/diagnostics:coverage_test`.
|
||||
|
||||
+19
-1
@@ -28,6 +28,15 @@ repos:
|
||||
exclude: '^(.*/fuzzer_corpus/.*|.*\.svg)$'
|
||||
- id: trailing-whitespace
|
||||
exclude: '^(.*/fuzzer_corpus/.*|.*/testdata/.*\.golden|.*\.svg)$'
|
||||
|
||||
# Run markdown linting early so that doc style and table-of-contents see the
|
||||
# linted state.
|
||||
- repo: https://github.com/rvben/rumdl-pre-commit
|
||||
rev: v0.2.22
|
||||
hooks:
|
||||
- id: rumdl
|
||||
args: [--fix]
|
||||
|
||||
- repo: https://github.com/google/pre-commit-tool-hooks
|
||||
rev: efaea7c61c774c0b1a9805fd999e754a2d19dbd1 # frozen: v1.2.5
|
||||
hooks:
|
||||
@@ -38,6 +47,15 @@ repos:
|
||||
.*AGENTS.md
|
||||
)$
|
||||
- id: markdown-toc
|
||||
|
||||
# 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
|
||||
hooks:
|
||||
- id: rumdl
|
||||
args: [--fix]
|
||||
|
||||
- repo: local
|
||||
hooks:
|
||||
- id: fix-cc-deps
|
||||
@@ -79,7 +97,7 @@ repos:
|
||||
# TODO: Not upgrading to/past 3.4.0 due to list indent changes that may
|
||||
# get fixed. See: https://github.com/prettier/prettier/issues/16929
|
||||
additional_dependencies: ['prettier@3.3.3']
|
||||
types_or: [html, javascript, json, markdown, yaml]
|
||||
types_or: [html, javascript, json, yaml]
|
||||
entry: npx prettier@3.3.3 --write --log-level=warn
|
||||
- repo: local
|
||||
hooks:
|
||||
|
||||
+67
@@ -0,0 +1,67 @@
|
||||
# Part of the Carbon Language project, under the Apache License v2.0 with LLVM
|
||||
# Exceptions. See /LICENSE for license information.
|
||||
# SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
||||
|
||||
[global]
|
||||
exclude = [
|
||||
".git",
|
||||
".jj",
|
||||
"CHANGELOG.md",
|
||||
"LICENSE.md",
|
||||
".github/pull_request_template.md",
|
||||
]
|
||||
respect-gitignore = true
|
||||
|
||||
# Disable rules that produce the most noise initially. Some of these might make
|
||||
# sense to re-enable.
|
||||
disable = [
|
||||
"MD013", # Line length exceeded
|
||||
"MD033", # Inline HTML - commonly used in real-world markdown
|
||||
"MD036", # Emphasis used instead of heading
|
||||
"MD040", # Code blocks should have a language specified
|
||||
"MD014", # Commands in code blocks should show output
|
||||
"MD034", # Bare URLs
|
||||
"MD059", # Link text should be descriptive
|
||||
"MD028", # Blank line inside blockquote
|
||||
]
|
||||
|
||||
# Heading style
|
||||
[MD003]
|
||||
style = "atx"
|
||||
|
||||
# Narrow restriction on trailing punctuation in headings -- allows ':' and '!'.
|
||||
[MD026]
|
||||
punctuation = ".,;"
|
||||
|
||||
# Unordered list marker style
|
||||
[MD004]
|
||||
style = "dash"
|
||||
|
||||
# Ordered list numbering
|
||||
[MD029]
|
||||
style = "one-or-ordered"
|
||||
|
||||
# Unordered list indentation
|
||||
[MD007]
|
||||
indent = 4
|
||||
|
||||
[MD077]
|
||||
style = "aligned"
|
||||
|
||||
# Spaces after list markers
|
||||
[MD030]
|
||||
ul-single = 3
|
||||
ul-multi = 3
|
||||
ol-align-column = 4
|
||||
|
||||
# Code block style
|
||||
[MD046]
|
||||
style = "fenced"
|
||||
|
||||
# Emphasis style
|
||||
[MD049]
|
||||
style = "underscore"
|
||||
|
||||
# Strong style
|
||||
[MD050]
|
||||
style = "asterisk"
|
||||
Vendored
+1
@@ -4,6 +4,7 @@
|
||||
"bierner.github-markdown-preview",
|
||||
"carbon-lang.carbon-vscode",
|
||||
"esbenp.prettier-vscode",
|
||||
"rvben.rumdl",
|
||||
"llvm-vs-code-extensions.vscode-clangd",
|
||||
"charliermarsh.ruff",
|
||||
"astral-sh.ty"
|
||||
|
||||
+1
-1
@@ -405,7 +405,7 @@ respectful, and don't drown out other discussion.
|
||||
Changes to Carbon documentation follow the
|
||||
[Google developer documentation style guide](https://developers.google.com/style).
|
||||
|
||||
Markdown files should additionally use [Prettier](https://prettier.io) for
|
||||
Markdown files should additionally use [rumdl](https://github.com/rvben/rumdl) for
|
||||
formatting, which we automate with
|
||||
[prek](/docs/project/contribution_tools.md#running-prek).
|
||||
|
||||
|
||||
@@ -942,6 +942,7 @@ Some common expressions in Carbon include:
|
||||
- [Move](#move): `~x`
|
||||
|
||||
- [Conditionals](expressions/if.md): `if c then t else f`
|
||||
|
||||
- Parentheses: `(7 + 8) * (3 - 1)`
|
||||
|
||||
When an expression appears in a context in which an expression of a specific
|
||||
|
||||
@@ -2705,10 +2705,13 @@ binary operator:
|
||||
And there are two positions that `where` can be written:
|
||||
|
||||
- At the end of an `impl as` declaration, before the body of the impl.
|
||||
|
||||
```carbon
|
||||
impl Class as Interface where .A = i32 { ... }
|
||||
```
|
||||
|
||||
- Inside a type expression.
|
||||
|
||||
```carbon
|
||||
fn F[T: Interface where .A impls OtherInterface](t: T) { ... }
|
||||
```
|
||||
@@ -4276,15 +4279,9 @@ includes:
|
||||
|
||||
The syntax for an out-of-line parameterized `impl` declaration is:
|
||||
|
||||
<!-- prettier-ignore-start -->
|
||||
|
||||
<!-- The following triggers a bug in prettier where it adds an `>` -->
|
||||
|
||||
> `impl forall [` _<parameter-bindings>_ `]` _<type-expression>_ `as`
|
||||
> _<facet-type-expression> [_ `where` _<optional-rewrite-constraints> ]_ `;`
|
||||
|
||||
<!-- prettier-ignore-end -->
|
||||
|
||||
This may also be called a _generic `impl` declaration_.
|
||||
|
||||
### Impl for a parameterized type
|
||||
@@ -5040,18 +5037,12 @@ let U:! B = bool;
|
||||
let V:! B = i32;
|
||||
```
|
||||
|
||||
<!-- prettier-ignore-start -->
|
||||
|
||||
<!-- The following triggers a bug in prettier where it adds an `>` -->
|
||||
|
||||
> **Note:**
|
||||
> [Issue #2880](https://github.com/carbon-language/carbon-lang/issues/2880) is a
|
||||
> tracking bug for known issues with this "strictly more complex" rule for
|
||||
> [Issue #2880](https://github.com/carbon-language/carbon-lang/issues/2880) is
|
||||
> a tracking bug for known issues with this "strictly more complex" rule for
|
||||
> `impl` termination. We are using that issue to track any code that arises in
|
||||
> practice that would terminate but is rejected by this rule.
|
||||
|
||||
<!-- prettier-ignore-end -->
|
||||
|
||||
> **Comparison with other languages:** Rust solves this problem by imposing a
|
||||
> recursion limit, much like C++ compilers use to terminate template recursion.
|
||||
> This goes against
|
||||
|
||||
@@ -144,9 +144,11 @@ This syntax is used for both standard library headers and user-defined headers:
|
||||
This import makes entities like `putchar` available.
|
||||
|
||||
- **C++ User-Defined Header:**
|
||||
|
||||
```carbon
|
||||
import Cpp library "circle.h";
|
||||
```
|
||||
|
||||
This import makes user-defined declarations and definitions available.
|
||||
|
||||
### TODO: Importing C++ code (inline)
|
||||
|
||||
@@ -29,7 +29,6 @@ A _lexical element_ is one of the following:
|
||||
- a [numeric literal](numeric_literals.md)
|
||||
- a [string literal](string_literals.md)
|
||||
- a [character literal](character_literals.md)
|
||||
|
||||
- a [comment](comments.md)
|
||||
- a [symbolic token](symbolic_tokens.md)
|
||||
|
||||
|
||||
@@ -220,7 +220,7 @@ run-time enforcement components of our
|
||||
[memory safety model](#memory-safety-model) above. This means, for example, that
|
||||
bounds checking is enabled in the release build. There is [evidence] that the
|
||||
cost of these hardening steps is low. Following the specific guidance of our top
|
||||
priority for [performance _control_], Carbon will provide ways to write unsafe code
|
||||
priority for [performance control], Carbon will provide ways to write unsafe code
|
||||
that disables the run-time enforcement, enabling the control of any overhead incurred.
|
||||
|
||||
[evidence]: https://chandlerc.blog/posts/2024/11/story-time-bounds-checking/
|
||||
|
||||
@@ -552,17 +552,21 @@ following conditions hold:
|
||||
declarations. For example, we can't apply this rewrite to `⟬X, each Y⟭` in
|
||||
this code, because the resulting signature would have return type `X` but no
|
||||
declaration of `X`:
|
||||
|
||||
```carbon
|
||||
fn F[... ⟬X, each Y⟭:! «type; ‖each next‖+1»]
|
||||
(... each __args: each ⟬X, each Y⟭) -> X;
|
||||
```
|
||||
|
||||
- The pack expansions being rewritten do not contain any pack literals other
|
||||
than the name pack being replaced. For example, we can't apply this rewrite
|
||||
to `⟬X, each Y⟭` in this code, because the pack expansion in the deduced
|
||||
parameter list also contains the pack literal `⟬I, each type⟭`:
|
||||
|
||||
```carbon
|
||||
fn F[... ⟬X, each Y⟭:! ⟬I, each type⟭](... each __args: each ⟬X, each Y⟭);
|
||||
```
|
||||
|
||||
Notice that as a corollary of this rule, all the names in the name pack must
|
||||
have the same type.
|
||||
|
||||
|
||||
@@ -224,12 +224,24 @@ considering if they fit your workflow.
|
||||
- **WARNING**: Bugs in `rs-git-fsmonitor` and/or Watchman can result in
|
||||
`prek` deleting files. If you see files being deleted, disable
|
||||
`rs-git-fsmonitor` with `git config --unset core.fsmonitor`.
|
||||
- [rumdl](https://github.com/rvben/rumdl): A Markdown formatter, which we use for
|
||||
formatting Markdown files. If you want to format files directly or use it in
|
||||
your editor, you can install it:
|
||||
- With `cargo` (preferred): `cargo install --locked rumdl`
|
||||
- With `brew` (on macOS): `brew install rumdl`
|
||||
- For Vim/Neovim, it is recommended to connect using its built-in Language
|
||||
Server Protocol (LSP) capabilities (by way of `rumdl server`). It is supported
|
||||
by [Mason](https://github.com/williamboman/mason.nvim) (as `rumdl`) and
|
||||
can be configured by way of `nvim-lspconfig` or formatting plugins like
|
||||
`conform.nvim`. For more details, see the
|
||||
[rumdl editor integration documentation](https://github.com/rvben/rumdl#editor-integration).
|
||||
- [vim-prettier](https://github.com/prettier/vim-prettier): A vim integration
|
||||
for [Prettier](https://prettier.io/), which we use for formatting.
|
||||
- [Visual Studio Code](https://code.visualstudio.com/): A code editor.
|
||||
- We provide [recommended extensions](/.vscode/extensions.json) to assist
|
||||
Carbon development. Some settings changes must be made separately:
|
||||
- Python › Formatting: Provider: `ruff`
|
||||
- Markdown › Formatting: Default Formatter: `rumdl`
|
||||
- **WARNING:** Visual Studio Code modifies the `PATH` environment
|
||||
variable, particularly in the terminals it creates. The `PATH`
|
||||
difference can cause `bazel` to detect different startup options,
|
||||
|
||||
@@ -16,7 +16,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
||||
- [Language features](#language-features)
|
||||
- [Code organization and structuring](#code-organization-and-structuring)
|
||||
- [Type system](#type-system)
|
||||
- [Functions, statements, expressions, ...](#functions-statements-expressions-)
|
||||
- [Functions, statements, expressions, etc](#functions-statements-expressions-etc)
|
||||
- [Standard library components](#standard-library-components)
|
||||
- [Project features](#project-features)
|
||||
- [Milestone 0.2: feature complete product for evaluation](#milestone-02-feature-complete-product-for-evaluation)
|
||||
@@ -149,7 +149,7 @@ into Carbon.
|
||||
- Mapping C++20 concepts into named predicates, and named predicates
|
||||
into C++20 concepts
|
||||
|
||||
#### Functions, statements, expressions, ...
|
||||
#### Functions, statements, expressions, etc
|
||||
|
||||
- Functions
|
||||
- Separate declaration and definition
|
||||
|
||||
@@ -934,7 +934,6 @@ etc. In general, the PR-centric model was favored.
|
||||
- Less to learn
|
||||
- Fewer steps in the process
|
||||
- No outdated versions in the old format left behind
|
||||
|
||||
- The technical flow seems on balance better than the Google Docs-based
|
||||
workflow. The proposal does a really good job explaining advantages and
|
||||
disadvantages. In summary, the Google Docs-centric workflow has a lot of
|
||||
|
||||
@@ -8,8 +8,6 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
||||
|
||||
[Pull request](https://github.com/carbon-language/carbon-lang/pull/140)
|
||||
|
||||
## Table of contents
|
||||
|
||||
<!-- toc -->
|
||||
|
||||
## Table of contents
|
||||
@@ -19,7 +17,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
||||
- [Details](#details)
|
||||
- [Conventions](#conventions)
|
||||
- [Alternatives considered](#alternatives-considered)
|
||||
- [Maintain the specification in a different language.](#maintain-the-specification-in-a-different-language)
|
||||
- [Maintain the specification in a different language](#maintain-the-specification-in-a-different-language)
|
||||
|
||||
<!-- tocstop -->
|
||||
|
||||
@@ -67,7 +65,7 @@ Hyperlinks between sections of the specification are used liberally.
|
||||
|
||||
## Alternatives considered
|
||||
|
||||
### Maintain the specification in a different language.
|
||||
### Maintain the specification in a different language
|
||||
|
||||
Advantages:
|
||||
|
||||
|
||||
@@ -297,7 +297,6 @@ Con:
|
||||
and do the conversion only when necessary. However, if non-canonical source
|
||||
is formally valid, there are more stringent performance constraints on such
|
||||
conversion than if it is only done for error recovery.
|
||||
|
||||
- Tools such as `grep` do not perform normalization themselves, and so would
|
||||
be unreliable when applied to a codebase with inconsistent normalization.
|
||||
- GCC already diagnoses identifiers that are not in NFC, and WG21 is in the
|
||||
|
||||
@@ -8,8 +8,6 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
||||
|
||||
[Pull request](https://github.com/carbon-language/carbon-lang/pull/144)
|
||||
|
||||
## Table of contents
|
||||
|
||||
<!-- toc -->
|
||||
|
||||
## Table of contents
|
||||
@@ -267,18 +265,24 @@ Advantages:
|
||||
types.
|
||||
- Writing a function that takes any integer literal can be done with more
|
||||
obvious syntax and less syntactic overhead. Instead of:
|
||||
|
||||
```
|
||||
fn OneHigher(L: IntLiteral(template _:! BigInt));
|
||||
```
|
||||
|
||||
we could write
|
||||
|
||||
```
|
||||
fn OneHigher(template L:! Integer);
|
||||
```
|
||||
|
||||
However, with this proposal, a function taking any integer expression that
|
||||
can be evaluated to a constant can be written as
|
||||
|
||||
```
|
||||
fn F(template N:! BigInt);
|
||||
```
|
||||
|
||||
and such a function would accept all integer literals, as well as
|
||||
non-literal constants.
|
||||
|
||||
|
||||
@@ -8,8 +8,6 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
||||
|
||||
[Pull request](https://github.com/carbon-language/carbon-lang/pull/157)
|
||||
|
||||
## Table of contents
|
||||
|
||||
<!-- toc -->
|
||||
|
||||
## Table of contents
|
||||
|
||||
@@ -8,8 +8,6 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
||||
|
||||
[Pull request](https://github.com/carbon-language/carbon-lang/pull/162)
|
||||
|
||||
## Table of contents
|
||||
|
||||
<!-- toc -->
|
||||
|
||||
## Table of contents
|
||||
@@ -156,7 +154,9 @@ expression: expression ':' identifier
|
||||
|
||||
is for pattern variables. For example, in a variable definition such as
|
||||
|
||||
```
|
||||
var Int: x = 0;
|
||||
```
|
||||
|
||||
the `Int: x` is parsed with the grammar rule for pattern variables. In the
|
||||
right-hand side of the above grammar rule, the `expression` to the left of the
|
||||
@@ -286,7 +286,9 @@ member: "var" expression ':' identifier ';'
|
||||
the `expression` must evaluate to a type at compile time. The same is true for
|
||||
the `tuple` in the grammar rule for an alternative:
|
||||
|
||||
```
|
||||
alternative: identifier tuple ';'
|
||||
```
|
||||
|
||||
### Precedence and Associativity
|
||||
|
||||
@@ -298,6 +300,7 @@ lowest to highest precedence, with operators on the same line having equal
|
||||
precedence. Proposal 168 differs in that the operator groups are partially
|
||||
ordered instead of being totally ordered.
|
||||
|
||||
```
|
||||
nonassoc '{' '}'
|
||||
nonassoc ':' ','
|
||||
left "or" "and"
|
||||
@@ -305,6 +308,7 @@ ordered instead of being totally ordered.
|
||||
left '+' '-'
|
||||
left '.' "->"
|
||||
nonassoc '(' ')' '[' ']'
|
||||
```
|
||||
|
||||
### Abstract Syntax
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Create a toolchain team.
|
||||
# Create a toolchain team
|
||||
|
||||
<!--
|
||||
Part of the Carbon Language project, under the Apache License v2.0 with LLVM
|
||||
|
||||
@@ -378,9 +378,11 @@ context of the complete language design.
|
||||
|
||||
### Multi-line text comments
|
||||
|
||||
<!-- rumdl-disable -->
|
||||
No support is provided for multi-line text comments. Instead, the intent is that
|
||||
such comments are expressed by prepending each line with the same `// ` comment
|
||||
marker.
|
||||
<!-- rumdl-enable -->
|
||||
|
||||
Requiring each line to repeat the comment marker will improve readability, by
|
||||
removing a source of non-local state, and removes a needless source of stylistic
|
||||
|
||||
@@ -66,7 +66,7 @@ easily be replaced with a different, more effective libraries to achieve the
|
||||
fundamental result of demonstrating a compelling body of cohesive design and the
|
||||
overarching value proposition.
|
||||
|
||||
#### Language design covers the syntax and semantics of the example port code.
|
||||
#### Language design covers the syntax and semantics of the example port code
|
||||
|
||||
We should have a clear understanding of the syntax and semantics used by these
|
||||
example ports. While this should include accepted proposals, it doesn't
|
||||
|
||||
@@ -209,16 +209,20 @@ fn F() -> var (): _ = () { ... }
|
||||
integration.
|
||||
- **Interoperability with and migration from existing C++ code**
|
||||
- This proposal rejects some constructs that would be valid in C++:
|
||||
|
||||
```
|
||||
return F();
|
||||
```
|
||||
|
||||
in a function with `void` return type would no longer be valid in a
|
||||
corresponding Carbon function with no specified return type, and would
|
||||
need to be translated into
|
||||
|
||||
```
|
||||
F();
|
||||
return;
|
||||
```
|
||||
|
||||
(possibly with braces added). However, the fact that this construct is
|
||||
valid in C++ is surprising to many, and the constructs that would be
|
||||
idiomatic in C++ are still valid under these rules.
|
||||
|
||||
@@ -134,7 +134,6 @@ Disadvantages:
|
||||
- If Carbon were to reuse `if` and `else` keywords for a ternary operator,
|
||||
that could omit braces in order to avoid ambiguity. For example,
|
||||
`int x = if y then 3 else 7;`.
|
||||
|
||||
- Developers are known to make mistakes adding statements to conditionals
|
||||
missing braces, keeping consistent indentation, and missing the incorrect
|
||||
behavior due to cognitive load. For example:
|
||||
|
||||
@@ -33,7 +33,7 @@ that talks about their approach to context dependence.
|
||||
## Proposal
|
||||
|
||||
We propose adding
|
||||
(`docs/project/principles/low_context_sensitivity.md`)[/docs/project/principles/low_context_sensitivity.md],
|
||||
[`docs/project/principles/low_context_sensitivity.md`](/docs/project/principles/low_context_sensitivity.md),
|
||||
which has the details.
|
||||
|
||||
## Rationale based on Carbon's goals
|
||||
|
||||
+1
-1
@@ -6,7 +6,7 @@ Exceptions. See /LICENSE for license information.
|
||||
SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
||||
-->
|
||||
|
||||
## Problem
|
||||
## Context
|
||||
|
||||
For generics, users will define _interfaces_ that describe types. These
|
||||
interfaces may have associated types (see
|
||||
|
||||
@@ -34,14 +34,17 @@ We would like to provide a notation for the following operations:
|
||||
|
||||
- Requesting a type conversion in order to select an operation to perform, or
|
||||
to resolve an ambiguity between possible operations:
|
||||
|
||||
```
|
||||
fn Ratio(a: i32, b: i32) -> f64 {
|
||||
// Note that a / b would invoke a different / operation.
|
||||
return a / (b as f64);
|
||||
}
|
||||
```
|
||||
|
||||
- Specifying the type that an expression will have or will be converted into,
|
||||
for documentation purposes.
|
||||
|
||||
```
|
||||
class Thing {
|
||||
var id: i32;
|
||||
@@ -51,8 +54,10 @@ We would like to provide a notation for the following operations:
|
||||
Print(t.id as i32);
|
||||
}
|
||||
```
|
||||
|
||||
- Specifying the type that an expression is expected to have, potentially
|
||||
after implicit conversions, as a form of static assertion.
|
||||
|
||||
```
|
||||
fn Munge() {
|
||||
// I expect this expression to produce a Widget but I'm getting compiler
|
||||
@@ -364,6 +369,7 @@ Advantage:
|
||||
implicitly. `as` conversions will likely be fairly common and routine in
|
||||
Carbon code due to their use in generics. As such, they may be written
|
||||
without much thought and not given much scrutiny in code review.
|
||||
|
||||
```
|
||||
var found: bool = false;
|
||||
var total_found: i32 = 0;
|
||||
|
||||
@@ -48,21 +48,29 @@ C-family languages provide a `cond ? value1 : value2` operator.
|
||||
- This operator has confusing syntax, because both `cond` and `value2` are
|
||||
undelimited, and it's often unclear to developers how much of the adjacent
|
||||
expressions are part of the conditional expression. For example:
|
||||
|
||||
```
|
||||
int n = has_thing1 && cond ? has_thing2 : has_thing3 && has_thing4;
|
||||
```
|
||||
|
||||
is parsed as
|
||||
|
||||
```
|
||||
int n = (has_thing1 && cond) ? has_thing2 : (has_thing3 && has_thing4);
|
||||
```
|
||||
|
||||
Also, `value1` and `value2` are parsed with different rules:
|
||||
|
||||
```
|
||||
cond ? f(), g() : h(), i();
|
||||
```
|
||||
|
||||
is parsed as
|
||||
|
||||
```
|
||||
(cond ? f(), g() : h()), i();
|
||||
```
|
||||
|
||||
- In C++, this operator has confusing semantics, due to having a complicated
|
||||
set of rules governing how the target type is determined.
|
||||
- Despite the complications of the rules, the result type of `?:` is not
|
||||
@@ -89,7 +97,6 @@ being an important case of this: `Use(if cond { v1 } else { v2 })`.
|
||||
```
|
||||
|
||||
... because the two arms of the `if` don't have the same type.
|
||||
|
||||
- We have already
|
||||
[decided](https://github.com/carbon-language/carbon-lang/issues/430) that we
|
||||
do not want Carbon to treat statements such as `if` as being expressions
|
||||
@@ -201,6 +208,7 @@ We could provide no conditional expression, and instead ask people to use a
|
||||
different mechanism to achieve this functionality. Some options include:
|
||||
|
||||
- Use of an `if` statement:
|
||||
|
||||
```
|
||||
var v: Result;
|
||||
if (cond) {
|
||||
@@ -210,15 +218,21 @@ different mechanism to achieve this functionality. Some options include:
|
||||
}
|
||||
Use(v);
|
||||
```
|
||||
|
||||
- A function call syntax:
|
||||
|
||||
```
|
||||
Use(cond.Select(value1, value2));
|
||||
```
|
||||
|
||||
or, with short-circuiting and lambdas:
|
||||
|
||||
```
|
||||
Use(cond.LazySelect($(value1), $(value2)));
|
||||
```
|
||||
|
||||
- An `if` statement in a lambda:
|
||||
|
||||
```
|
||||
Use(${ if (cond) { return value1; } else { return value2; } });
|
||||
```
|
||||
@@ -278,6 +292,7 @@ Advantages:
|
||||
- Looks more like an `if` statement, albeit one with unbraced operands.
|
||||
- Slightly shorter.
|
||||
- Better line-wrapping for chained `if` expressions:
|
||||
|
||||
```
|
||||
Print(if (guess < value)
|
||||
"Too low!"
|
||||
@@ -286,7 +301,9 @@ Advantages:
|
||||
else
|
||||
"Correct!")
|
||||
```
|
||||
|
||||
may be more readable than
|
||||
|
||||
```
|
||||
Print(if guess < value
|
||||
then "Too low!"
|
||||
@@ -294,7 +311,9 @@ Advantages:
|
||||
then "Too high!"
|
||||
else "Correct!")
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
```
|
||||
Print(if guess < value
|
||||
then "Too low!"
|
||||
@@ -308,18 +327,22 @@ Disadvantages:
|
||||
- Potentially worse line wrapping. The `else` would presumably be wrapped onto
|
||||
a line by itself, wasting vertical space, whereas `then` and `else` when
|
||||
paired can both comfortably precede their values on the same line; consider
|
||||
|
||||
```
|
||||
F(if (cond)
|
||||
value1
|
||||
else
|
||||
value2)
|
||||
```
|
||||
|
||||
occupies more space than
|
||||
|
||||
```
|
||||
F(if cond
|
||||
then value1
|
||||
else value2)
|
||||
```
|
||||
|
||||
- May create confusion between `if` statements and `if` expressions by
|
||||
resembling an `if` statement but not matching the semantics.
|
||||
- May cause evolutionary problems due to syntactic conflict if we ever make
|
||||
@@ -410,6 +433,7 @@ ambiguous. If the author of `A` or `B` wishes to change this behavior:
|
||||
provided specifying the common type is `B`.
|
||||
- If the common type should be something else, then both `impl`s need to be
|
||||
provided:
|
||||
|
||||
```
|
||||
impl A as CommonTypeWith(B) { let Result:! Type = C; }
|
||||
impl B as CommonTypeWith(A) { let Result:! Type = C; }
|
||||
@@ -503,13 +527,17 @@ Disadvantages:
|
||||
- Mutable inputs to operations ("out parameters") in Carbon are expected to be
|
||||
expressed as pointers under #821, so there will be a `&` somewhere anyway;
|
||||
given the choice between an lvalue conditional:
|
||||
|
||||
```
|
||||
F(&(if cond then a else b));
|
||||
```
|
||||
|
||||
and an rvalue-only conditional:
|
||||
|
||||
```
|
||||
F(if cond then &a else &b);
|
||||
```
|
||||
|
||||
the latter option would likely be preferred even if the former were
|
||||
available.
|
||||
- This would create an inconsistency in behavior, which would be particularly
|
||||
|
||||
@@ -117,7 +117,6 @@ conditional conformance options:
|
||||
|
||||
This was too different from how those same impls would be declared
|
||||
out-of-line.
|
||||
|
||||
- Another approach that was too different between inline and out-of-line, is
|
||||
to use pattern matching instead of boolean conditions. This might look like:
|
||||
|
||||
|
||||
@@ -175,6 +175,7 @@ Disadvantages:
|
||||
for them in practice.
|
||||
- Likely to result in complexity and inconsistency for operations falling
|
||||
between the two options. For example, in C++:
|
||||
|
||||
```
|
||||
struct A {
|
||||
static void F();
|
||||
@@ -187,6 +188,7 @@ Disadvantages:
|
||||
b.e; // Error.
|
||||
}
|
||||
```
|
||||
|
||||
- Does not provide an obvious syntax for `impl` lookup.
|
||||
`Type::Interface::method` would be ambiguous and `Type.Interface::method`
|
||||
would be inconsistent with using `::` for static lookup, so we would likely
|
||||
|
||||
@@ -530,7 +530,7 @@ signed integers (whether we provide those operations as operators or library
|
||||
functions). Assuming operator notation for now, and that we define modulo as
|
||||
`a % b == a - a / b * b`, the following options all have merit:
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
<!-- rumdl-disable -->
|
||||
| Property | Round towards zero (truncating division) | Round towards negative infinity (floor division) | Round based on sign of divisor\[1] (Euclidean division) |
|
||||
| ------------------------------------ | -------- | -------- | --------- |
|
||||
| `(-a) / b ==`<br>` a / (-b)` | :+1: Yes | :+1: Yes | No |
|
||||
@@ -541,6 +541,7 @@ functions). Assuming operator notation for now, and that we define modulo as
|
||||
| x86 instruction? | :+1: Yes: `cqo` (or similar) + `idiv` | First option + fixup:<br> `s * (a / (s * b))` where `s` is `sign(a) * sign(b)`[2] | First option + fixup:<br>`a / b - (a % b < 0)` |
|
||||
| LLVM IR + optimization support | :+1: Yes | No | No |
|
||||
| Use in existing languages | C, C++, Rust, Swift <br> `quotRem` in Haskell | `//` and `%` in Python <br> `/` in Python 2 only <br> `divMod` in Haskell | None? |
|
||||
<!-- rumdl-enable -->
|
||||
|
||||
The cells marked :+1: suggest generally desirable properties. For further
|
||||
reading, see
|
||||
|
||||
@@ -346,9 +346,11 @@ We considered the following options:
|
||||
right-hand operand as runtime state, and allow that type to be converted in
|
||||
the same way as its integer constant. However, this would introduce
|
||||
substantial complexity: reasonable and expected uses such as
|
||||
|
||||
```
|
||||
var mask: u32 = (1 << a) - 1;
|
||||
```
|
||||
|
||||
would require a second new type for a shifted value plus an offset, and
|
||||
general support would require a facility analogous to
|
||||
[expression templates](https://en.wikipedia.org/wiki/Expression_templates).
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Remove LLVM from the repository, and clean up history.
|
||||
# Remove LLVM from the repository, and clean up history
|
||||
|
||||
<!--
|
||||
Part of the Carbon Language project, under the Apache License v2.0 with LLVM
|
||||
@@ -26,7 +26,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
||||
- [Rationale](#rationale)
|
||||
- [Alternatives considered](#alternatives-considered)
|
||||
- [Do nothing](#do-nothing)
|
||||
- [Don't rewrite the repository history.](#dont-rewrite-the-repository-history)
|
||||
- [Don't rewrite the repository history](#dont-rewrite-the-repository-history)
|
||||
- [Go back to submodules](#go-back-to-submodules)
|
||||
- [Rename the repository, and create a new one](#rename-the-repository-and-create-a-new-one)
|
||||
- [Manually extract and archive some review comments](#manually-extract-and-archive-some-review-comments)
|
||||
@@ -266,7 +266,7 @@ Disadvantages:
|
||||
|
||||
We think this problem is worth solving.
|
||||
|
||||
### Don't rewrite the repository history.
|
||||
### Don't rewrite the repository history
|
||||
|
||||
We could fix this without rewriting history. If we choose not to rewrite history
|
||||
now, it should be noted that the cost of rewriting history only grows and so we
|
||||
|
||||
@@ -23,7 +23,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
||||
- [Too many cooks in the kitchen](#too-many-cooks-in-the-kitchen)
|
||||
- [Community management overload](#community-management-overload)
|
||||
- [Added distraction or confusion to the C++ evolution process](#added-distraction-or-confusion-to-the-c-evolution-process)
|
||||
- [Added distractions from existing new programming languages.](#added-distractions-from-existing-new-programming-languages)
|
||||
- [Added distractions from existing new programming languages](#added-distractions-from-existing-new-programming-languages)
|
||||
- [Friction with existing LLVM and Clang communities](#friction-with-existing-llvm-and-clang-communities)
|
||||
- [Labeled as vaporware](#labeled-as-vaporware)
|
||||
- [Rationale](#rationale)
|
||||
@@ -296,7 +296,7 @@ Planned mitigations:
|
||||
as possible from the Carbon experiment and incorporate any and all of our
|
||||
ideas into C++ where they see a path to do so.
|
||||
|
||||
#### Added distractions from existing new programming languages.
|
||||
#### Added distractions from existing new programming languages
|
||||
|
||||
- Another programming language in the world might dilute some of the efforts
|
||||
going towards new and exciting but existing languages, especially ones with
|
||||
|
||||
@@ -376,7 +376,7 @@ could be a hashmap index, a string, or pointer to a node, without changing the
|
||||
usage for users.
|
||||
|
||||
The `ElementType` can be a tuple, such as a `(key, value)` for maps, or a single
|
||||
value. See [Future work][#future-work] for other examples.
|
||||
value. See [Future work](#future-work) for other examples.
|
||||
|
||||
#### R-value containers
|
||||
|
||||
@@ -542,8 +542,8 @@ class MyIntContainer {
|
||||
Mixins are currently in early design stages. This section highlights possible
|
||||
uses speculating on the final design. Some may include:
|
||||
|
||||
- Improved semantics for views compared to getter methods: no direct side
|
||||
effect from using the view
|
||||
- Improved semantics for views compared to getter methods: no direct side effect
|
||||
from using the view
|
||||
- Facilitate code reuse, compared to reimplementing an interface
|
||||
- Direct access to `self`, limiting needs for pointers and address resolution
|
||||
|
||||
@@ -624,8 +624,8 @@ author chooses between value and reference).
|
||||
For reference, range-based `for` loops in C++ requires:
|
||||
|
||||
- `begin()` and `end()` methods or free functions, and
|
||||
- the type returned supports pre-increment `++`, indirection `*`, and
|
||||
inequality `!=` operations
|
||||
- the type returned supports pre-increment `++`, indirection `*`, and inequality
|
||||
`!=` operations
|
||||
|
||||
See [range-based for statement](https://eel.is/c++draft/stmt.iter#stmt.ranged)
|
||||
for more details.
|
||||
@@ -799,8 +799,8 @@ This would work similarly to [Python generator functions](#python).
|
||||
|
||||
This has the following advantages:
|
||||
|
||||
- Removes the need for an `Optional`, and the associated overheads, copies,
|
||||
and unwrapping.
|
||||
- Removes the need for an `Optional`, and the associated overheads, copies, and
|
||||
unwrapping.
|
||||
- No boundary checks needed at the `for` level
|
||||
- Compatible with R-value containers
|
||||
|
||||
@@ -850,13 +850,13 @@ value, or [inverting control](#inversion-of-control).
|
||||
The iterator approach was considered but proved to have key limitations that a
|
||||
cursor approach does not have:
|
||||
|
||||
- It requires implementing 2 interfaces instead of 1, and is more complex due
|
||||
to having the iteration logic separated from the container itself
|
||||
- It requires implementing 2 interfaces instead of 1, and is more complex due to
|
||||
having the iteration logic separated from the container itself
|
||||
- More difficult to harden or troubleshoot, compared to a cursor that allows
|
||||
bounds checking in debug & hardened build modes
|
||||
- Can pose problems with ranges that consumes their input (See Barry Revzin’s
|
||||
"take(5)" presentation from C++Now 2023), when compared to a combined
|
||||
`Next()` approach.
|
||||
"take(5)" presentation from C++Now 2023), when compared to a combined `Next()`
|
||||
approach.
|
||||
- Higher overhead
|
||||
- Proves to be difficult to support for R-values
|
||||
|
||||
|
||||
@@ -145,7 +145,7 @@ are examples of character literals for each specific type:
|
||||
- `Char8`: The character literal consists of a single Unicode code point that
|
||||
can be represented within 8 bits. For example:
|
||||
|
||||
`let allowed: Char8 = ‘a’ `
|
||||
`let allowed: Char8 = 'a'`
|
||||
|
||||
In this example, the character literal `’a’` corresponds to the Unicode code
|
||||
point `97`, which is within the valid range of `Char8` since `97` is less than
|
||||
|
||||
@@ -130,12 +130,11 @@ Leads questions which informed the design proposed here:
|
||||
- [What syntax should we use for pointer types? (#523)][#523]
|
||||
|
||||
It also builds on the design of the proposal ["Initialization of memory and
|
||||
variables"][#257] ([#257]), implementing part of [#1993].
|
||||
variables" (#257)][#257], implementing part of [#1993].
|
||||
|
||||
[#257]: https://github.com/carbon-language/carbon-lang/pull/257
|
||||
[#523]: https://github.com/carbon-language/carbon-lang/issues/523
|
||||
[#1993]: https://github.com/carbon-language/carbon-lang/issues/1993
|
||||
[#257]: /proposals/p000257-initialization-of-memory-and-variables.md
|
||||
|
||||
## Proposal
|
||||
|
||||
@@ -468,8 +467,6 @@ memory is accessed and potentially mutated.
|
||||
The syntax both for declaring a pointer type and dereferencing a pointer has
|
||||
been extensively discussed in the leads question [#523].
|
||||
|
||||
[#523]: https://github.com/carbon-language/carbon-lang/issues/523
|
||||
|
||||
The primary sources of concern over a C++-based syntax:
|
||||
|
||||
1. A prefix dereference operator composes poorly with postfix and infix
|
||||
|
||||
@@ -222,6 +222,7 @@ constraints and restrict the syntax of `where A = B` as follows:
|
||||
`SameAs` relations. Same-type constraints are not used automatically by the
|
||||
language rules for any purpose, but a blanket `ImplicitAs` impl permits
|
||||
conversions between types that are known to be the same:
|
||||
|
||||
```
|
||||
impl forall [T:! type, U:! type where .Self == T] T as ImplicitAs(U);
|
||||
```
|
||||
|
||||
@@ -162,7 +162,6 @@ terminology:
|
||||
|
||||
We previously referred to a facet type as a type-of-type, but that is no
|
||||
longer accurate, as the type of any type is now by definition `type`.
|
||||
|
||||
- A _facet_ is a value of a facet type. For example, `i32 as Hashable` is a
|
||||
facet, and `Hashable` is a facet type. Note that all types are facets.
|
||||
- A facet value can be thought of as a tuple of a possibly-symbolic
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Remove artificial version ceiling on C++ interop.
|
||||
# Remove artificial version ceiling on C++ interop
|
||||
|
||||
<!--
|
||||
Part of the Carbon Language project, under the Apache License v2.0 with LLVM
|
||||
|
||||
@@ -19,9 +19,9 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
||||
- [Details](#details)
|
||||
- [Rationale](#rationale)
|
||||
- [Alternatives considered](#alternatives-considered)
|
||||
- [Narrowing the proposed milestone definitions to just 0.1 initially.](#narrowing-the-proposed-milestone-definitions-to-just-01-initially)
|
||||
- [Make a more incremental, less ambitious initial milestone.](#make-a-more-incremental-less-ambitious-initial-milestone)
|
||||
- [Skip the 0.1 milestone and aim for feature completeness.](#skip-the-01-milestone-and-aim-for-feature-completeness)
|
||||
- [Narrowing the proposed milestone definitions to just 0.1 initially](#narrowing-the-proposed-milestone-definitions-to-just-01-initially)
|
||||
- [Make a more incremental, less ambitious initial milestone](#make-a-more-incremental-less-ambitious-initial-milestone)
|
||||
- [Skip the 0.1 milestone and aim for feature completeness](#skip-the-01-milestone-and-aim-for-feature-completeness)
|
||||
|
||||
<!-- tocstop -->
|
||||
|
||||
@@ -123,7 +123,7 @@ on-going language evolution:
|
||||
|
||||
## Alternatives considered
|
||||
|
||||
### Narrowing the proposed milestone definitions to just 0.1 initially.
|
||||
### Narrowing the proposed milestone definitions to just 0.1 initially
|
||||
|
||||
While this would narrow the scope of the proposal and remove some of the more
|
||||
vague aspects, it would make it difficult for readers to understand when
|
||||
@@ -134,7 +134,7 @@ We also expect that explicitly deferring things in this way will make it easier
|
||||
to focus our energy and efforts on the next milestone by avoiding distractions
|
||||
of features that _might_ be interesting absent that deferral.
|
||||
|
||||
### Make a more incremental, less ambitious initial milestone.
|
||||
### Make a more incremental, less ambitious initial milestone
|
||||
|
||||
The initial milestone currently proposed is relatively ambitious, and much
|
||||
larger than most programming language MVPs. Carbon could have a much less
|
||||
@@ -147,7 +147,7 @@ end up in somewhat of an "apples versus oranges" comparison where the feature
|
||||
sets are so different as to thwart any attempt at in-depth comparison and
|
||||
evaluation.
|
||||
|
||||
### Skip the 0.1 milestone and aim for feature completeness.
|
||||
### Skip the 0.1 milestone and aim for feature completeness
|
||||
|
||||
We could have fewer milestones overall and aim for the more ambitious goal. We
|
||||
know that 0.1 will be insufficient to finish most real evaluations of the Carbon
|
||||
|
||||
@@ -310,9 +310,10 @@ An `impl` declaration, with this proposal, must have one of these two forms:
|
||||
- Without an `extend` keyword prefix, used for non-extended `impl`
|
||||
declarations and for all `impl` declarations outside of a class body:
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
<!-- rumdl-disable -->
|
||||
> `impl` [`forall` `[` _deduced-parameters_ `]`] [_type-expression_] `as`
|
||||
> _facet-type-expression_ (`;`|`{` _impl-body_ `}`)
|
||||
<!-- rumdl-enable -->
|
||||
|
||||
The _type-expression_ is required outside of a class body, otherwise it
|
||||
defaults to `Self`.
|
||||
@@ -487,7 +488,6 @@ Notes:
|
||||
a `require` declaration must use `Self`, either to the left or right of
|
||||
`impls`. Note that `require` only supports this subset of `where` clause
|
||||
expressions. Adding other kinds of constraints is future work.
|
||||
|
||||
- Syntax for an `extend` declaration in an interface or named constraint:
|
||||
|
||||
> `extend` _facet-type-expression_ `;`
|
||||
@@ -524,9 +524,10 @@ class C {
|
||||
The declaration that a class uses a mixin is called a "mix" declaration. The
|
||||
syntax of a mix declaration is:
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
<!-- rumdl-disable -->
|
||||
> `extend` [`private`|`protected`] (`_`|_id_) `:` _mixin-expression_ [`=`
|
||||
> _initializer-expression_] `;`
|
||||
<!-- rumdl-enable -->
|
||||
|
||||
The _id_ part of the mix declaration defines the name assigned to that mixin
|
||||
subobject. This name is may be used to access members of the mixin and to
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Clarify name bindings in namespaces.
|
||||
# Clarify name bindings in namespaces
|
||||
|
||||
<!--
|
||||
Part of the Carbon Language project, under the Apache License v2.0 with LLVM
|
||||
|
||||
@@ -13,6 +13,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
||||
## Table of contents
|
||||
|
||||
- [Abstract](#abstract)
|
||||
- [Background](#background)
|
||||
- [Syntax Overview](#syntax-overview)
|
||||
- [Syntax Defined](#syntax-defined)
|
||||
- [Introducer](#introducer)
|
||||
@@ -55,7 +56,7 @@ Associated discussion docs:
|
||||
- [Lambdas Discussion 3](https://docs.google.com/document/d/1VVOlRuPGt8GQpjsygMwH2B7Wd0mBsS3Qif8Ve2yhX_A/)
|
||||
- [Lambdas Discussion 4](https://docs.google.com/document/d/1Sevhvjo06Bc6wTigNL1pK-mlF3IXvzmU1lI2X1W9OYA/)
|
||||
|
||||
# Background
|
||||
## Background
|
||||
|
||||
Refer to the following documentation about lambdas in other languages. What
|
||||
separates these three and makes them more analegous to Carbon's direction is the
|
||||
|
||||
@@ -22,10 +22,10 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
||||
- [Long-Term Stable (LTS) versions and standardization](#long-term-stable-lts-versions-and-standardization)
|
||||
- [Rationale](#rationale)
|
||||
- [Alternatives considered](#alternatives-considered)
|
||||
- [Do nothing, or just talk about a minimal nightly version.](#do-nothing-or-just-talk-about-a-minimal-nightly-version)
|
||||
- [Make no breaking changes past 1.0.](#make-no-breaking-changes-past-10)
|
||||
- [Version different parts of the language separately.](#version-different-parts-of-the-language-separately)
|
||||
- [Use a custom versioning scheme rather than SemVer.](#use-a-custom-versioning-scheme-rather-than-semver)
|
||||
- [Do nothing, or just talk about a minimal nightly version](#do-nothing-or-just-talk-about-a-minimal-nightly-version)
|
||||
- [Make no breaking changes past 1.0](#make-no-breaking-changes-past-10)
|
||||
- [Version different parts of the language separately](#version-different-parts-of-the-language-separately)
|
||||
- [Use a custom versioning scheme rather than SemVer](#use-a-custom-versioning-scheme-rather-than-semver)
|
||||
- [Include more pre-release variations](#include-more-pre-release-variations)
|
||||
|
||||
<!-- tocstop -->
|
||||
@@ -195,7 +195,7 @@ to meet the needs of candidate Carbon users.
|
||||
|
||||
## Alternatives considered
|
||||
|
||||
### Do nothing, or just talk about a minimal nightly version.
|
||||
### Do nothing, or just talk about a minimal nightly version
|
||||
|
||||
Advantages:
|
||||
|
||||
@@ -219,7 +219,7 @@ and all of this if and when we need to. This does not lock Carbon into using
|
||||
this exact versioning scheme. We will listen to any feedback from potential
|
||||
users and can adapt our approach if needed.
|
||||
|
||||
### Make no breaking changes past 1.0.
|
||||
### Make no breaking changes past 1.0
|
||||
|
||||
Advantages:
|
||||
|
||||
@@ -239,7 +239,7 @@ Disadvantages:
|
||||
This complexity inherently comes with an increased risk and importance
|
||||
of being able to improve and fix issues.
|
||||
|
||||
### Version different parts of the language separately.
|
||||
### Version different parts of the language separately
|
||||
|
||||
Advantages:
|
||||
|
||||
@@ -260,7 +260,7 @@ Disadvantages:
|
||||
over the years. As a consequence, while it is tempting to hope for a sharp
|
||||
difference here we don't in practice anticipate one.
|
||||
|
||||
### Use a custom versioning scheme rather than SemVer.
|
||||
### Use a custom versioning scheme rather than SemVer
|
||||
|
||||
Advantages:
|
||||
|
||||
|
||||
@@ -365,7 +365,6 @@ same type due to the different spellings of the types in C++ being the same:
|
||||
|
||||
- `Cpp.float` and `Cpp.double` will be the same type as `f32` and `f64`
|
||||
correspondingly.
|
||||
|
||||
- The type aliases `[u]int_fastN_t`, `[u]int_leastN_t`, `[u]intmax_t`,
|
||||
`[u]intptr_t`, `ptrdiff_t` and `size_t` will be available in Carbon in the
|
||||
`Cpp` namespace if the C++ header declaring them is imported (for example
|
||||
|
||||
@@ -33,7 +33,7 @@ disclosure", but that approach has not been codified as a design principle.
|
||||
## Proposal
|
||||
|
||||
See
|
||||
(`docs/project/principles/progressive_disclosure.md`)[/docs/project/principles/progressive_disclosure.md],
|
||||
[`docs/project/principles/progressive_disclosure.md`](/docs/project/principles/progressive_disclosure.md),
|
||||
which is introduced by this proposal.
|
||||
|
||||
## Rationale
|
||||
|
||||
@@ -19,7 +19,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
||||
- [Object-like macros](#object-like-macros)
|
||||
- [Function-like macros](#function-like-macros)
|
||||
- [Predefined macros](#predefined-macros)
|
||||
- [Swift / C interop [GitHub][documentation]](#swift--c-interop-githubdocumentation)
|
||||
- [Swift / C interop](#swift--c-interop)
|
||||
- [Proposal](#proposal)
|
||||
- [Details](#details)
|
||||
- [Namespace](#namespace)
|
||||
@@ -111,7 +111,11 @@ In function-like macros, the operators `#` and `##` enable:
|
||||
There are also predefined macros available in every translation unit. Examples
|
||||
include: `__cplusplus`, `__FILE__`, `__LINE__`, `__DATE__`, `__TIME__` etc.
|
||||
|
||||
### Swift / C interop [[GitHub](https://github.com/swiftlang/swift/blob/main/lib/ClangImporter/ImportMacro.cpp)][[documentation](https://developer.apple.com/documentation/swift/using-imported-c-macros-in-swift)]
|
||||
### Swift / C interop
|
||||
|
||||
See the Swift
|
||||
[implementation](https://github.com/swiftlang/swift/blob/main/lib/ClangImporter/ImportMacro.cpp)
|
||||
and [documentation](https://developer.apple.com/documentation/swift/using-imported-c-macros-in-swift).
|
||||
|
||||
Swift supports importing object-like C macros as global constants. Macros that
|
||||
use integer, floating-point and string literals are supported. Also simple
|
||||
|
||||
@@ -23,7 +23,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
||||
- [Alternatives considered](#alternatives-considered)
|
||||
- [Considering a facet type of a named constraint to be identified in its definition](#considering-a-facet-type-of-a-named-constraint-to-be-identified-in-its-definition)
|
||||
- [Restricting to `Self`](#restricting-to-self)
|
||||
- [Allowing limited conversions to partially identified facet types.](#allowing-limited-conversions-to-partially-identified-facet-types)
|
||||
- [Allowing limited conversions to partially identified facet types](#allowing-limited-conversions-to-partially-identified-facet-types)
|
||||
|
||||
<!-- tocstop -->
|
||||
|
||||
@@ -240,7 +240,7 @@ partially identified facet type. But by differentiating the the partially
|
||||
identified state from identified, we can form the rules around the state of the
|
||||
facet type instead of the identity of the facet.
|
||||
|
||||
### Allowing limited conversions to partially identified facet types.
|
||||
### Allowing limited conversions to partially identified facet types
|
||||
|
||||
We considered allowing conversions from `N & J` to `N & K` where `N` is
|
||||
partially identified, and `J` and `K` are identified.
|
||||
|
||||
@@ -84,6 +84,9 @@ they have an associated error. An exception is that the main test file may omit
|
||||
|
||||
## Content replacement
|
||||
|
||||
<!-- TODO: Re-enable once rumdl's bugs with complex nested lists are fixed. -->
|
||||
<!-- rumdl-disable -->
|
||||
|
||||
Some keywords can be inserted for content:
|
||||
|
||||
- ```
|
||||
@@ -289,6 +292,8 @@ Supported comment markers are:
|
||||
run the test directly. Tips have no impact on validation; the marker informs
|
||||
autoupdate that it can update or remove them as needed.
|
||||
|
||||
<!-- rumdl-enable -->
|
||||
|
||||
<!--
|
||||
{% endraw %}
|
||||
-->
|
||||
|
||||
@@ -98,10 +98,12 @@ Currently this happens in two cases, which are handled using two maps in
|
||||
instruction IDs:
|
||||
|
||||
- A name binding can be used within the same pattern that declares it:
|
||||
|
||||
```carbon
|
||||
match (x) {
|
||||
case (n: i32, n) => ...
|
||||
```
|
||||
|
||||
For this to work, the name `n` needs to be added to the scope as soon as we
|
||||
handle its declaration, and it needs to resolve to the `ValueBinding`
|
||||
instruction that binds a value to that name. This means that the
|
||||
|
||||
@@ -250,7 +250,6 @@ supported in `Check` diagnostics are:
|
||||
|
||||
- `InstIdAsRawType`
|
||||
- `TypeIdAsRawType`
|
||||
|
||||
- For integer constants, `TypedInt` can be used to format an `APInt` given its
|
||||
type. The type is used to determine the signedness to use for the value.
|
||||
|
||||
|
||||
@@ -100,8 +100,8 @@ fn foo() -> f64 {
|
||||
|
||||
The node order is (with indentation to indicate nesting):
|
||||
|
||||
<!-- Prevent prettier from changing indents. -->
|
||||
<!-- prettier-ignore-start -->
|
||||
<!-- Prevent changing indents. -->
|
||||
<!-- rumdl-disable -->
|
||||
|
||||
```yaml
|
||||
[
|
||||
@@ -121,7 +121,7 @@ The node order is (with indentation to indicate nesting):
|
||||
]
|
||||
```
|
||||
|
||||
<!-- prettier-ignore-end -->
|
||||
<!-- rumdl-enable -->
|
||||
|
||||
In this example, `FileStart`, `FunctionDefinition`, and `FileEnd` are "root"
|
||||
nodes for the tree. Function components are children of `FunctionDefinition`.
|
||||
@@ -175,6 +175,7 @@ var x: i32 = y + 1;
|
||||
Lexing creates distinct tokens for each syntactic element, which will form the
|
||||
basis of the parse tree:
|
||||
|
||||
<!-- rumdl-disable -->
|
||||
<pre>
|
||||
<b>Tokens:</b>
|
||||
|
||||
@@ -371,6 +372,7 @@ respect to the depth of the parse tree.
|
||||
| var | | x | | i32 | | : | | = | | y | | 1 | | + | | ; |
|
||||
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|
||||
</pre>
|
||||
<!-- rumdl-enable -->
|
||||
|
||||
The structural concepts of bracketing nodes (`var` and `;`) and parent nodes
|
||||
with a known child count (`:` and `+` with 2 children, but also `=` with 0
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: 404
|
||||
nav_exclude: true
|
||||
---
|
||||
|
||||
# 404: File not found
|
||||
## 404: File not found
|
||||
|
||||
<!--
|
||||
Part of the Carbon Language project, under the Apache License v2.0 with LLVM
|
||||
|
||||
Reference in New Issue
Block a user