mirror of
https://github.com/carbon-language/carbon-lang.git
synced 2026-10-01 22:02:45 +01:00
Jon Ross-Perkins
a23f15e901
This is how I'm interpreting discussion:
- Basic elements are getting set to an ID.
- SetName exists to assign a name (which can then be referred to later with an identifier expression) to an ID.
- Expressions are broken down into a series of operations which operate on IDs.
So with something like the last test:
```
fn Main() { return 12 + 34; }
```
This becomes:
```
Function(%0,
{IntegerLiteral(%3, 12),
IntegerLiteral(%2, 34),
BinaryOperator(%1, +, %3, %2),
Return(%1),
})
SetName(`Main`, %0)
```
Note I'm treating blocks as fairly equal to the top of a file now, and basically eliminating boundaries between things. That's because we have discussed also supporting code like:
```
fn Foo() {
fn Bar() {}
Bar();
}
```
Here a declaration of a function is occurring inside a code block, so it felt like eliminating the difference was the best choice.
I know you'd commented on the separation of nodes to individual files before; I still think we're going to have a lot of different types of nodes, and so separating them out into individual files makes them easier to browse.
25 lines
576 B
C++
25 lines
576 B
C++
// 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
|
|
|
|
#ifndef CARBON_TOOLCHAIN_SEMANTICS_NODE_KIND_H_
|
|
#define CARBON_TOOLCHAIN_SEMANTICS_NODE_KIND_H_
|
|
|
|
#include <cstdint>
|
|
|
|
namespace Carbon::Semantics {
|
|
|
|
// Meta node information for declarations.
|
|
enum class NodeKind {
|
|
BinaryOperator,
|
|
Function,
|
|
IntegerLiteral,
|
|
Return,
|
|
SetName,
|
|
Invalid,
|
|
};
|
|
|
|
} // namespace Carbon::Semantics
|
|
|
|
#endif // CARBON_TOOLCHAIN_SEMANTICS_NODE_KIND_H_
|