carbon-lang

1,420 Commits 3 Branches 810 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
Jon Ross-Perkins	4c8fdf5124	Start drafting out semantic type checking. (#2406 ) This is a first pass at what semantic type checking might look like. Types propagate along nodes, we use an InvalidType object when there's an error, and once there's an InvalidType we stop doing so much type checking. This adds some RealLiteral handling in order to get type mismatches. I'm cautious about creating some real value for SemanticsIR (since the tokenized buffer version is a bit constrained), so I'm not doing that yet. But I will probably need to in order to maintain SemanticsIR having hermetic copies of its data, without a parse tree dependency.	2022-11-17 13:36:40 -08:00
Jon Ross-PerkinsandChandler Carruth	352fec1885	Add some coarse debug information to semantics. (#2382 ) Example stack: ``` 1. node_stack_: 0. FunctionDefinitionStart 1. ReturnStatement -> node1 2. node_block_stack_: 0. block0 1. block1 ``` Example trace output: ``` * SemanticsParseTreeHandler::Build Begin * Push 0: FunctionIntroducer Push 1: DeclaredName Push 2: ParameterListEnd Pop 2: ParameterListEnd Push 2: ParameterList Pop 2: ParameterList Pop 0: FunctionIntroducer AddNode block0: FunctionDeclaration() AddNode block0: BindName(ident0, node0) AddNode block0: FunctionDefinition(node0, block1) Push 0: FunctionDefinitionStart Push 1: Literal -> IntegerLiteral AddNode block1: IntegerLiteral(int0): node_xref1 Push 2: StatementEnd Pop 2: StatementEnd Pop 1: any (Literal) -> node0 Push 1: ReturnStatement -> ReturnExpression AddNode block1: ReturnExpression(node0) Pop 0: FunctionDefinitionStart Push 0: FunctionDefinition * SemanticsParseTreeHandler::Build End * cross_reference_irs.size == 2, cross_references = { node_xref0 = "xref(ir0, block0, node0)"; node_xref1 = "xref(ir0, block0, node1)"; }, identifiers = { ident0 = "Foo"; }, integer_literals = { int0 = 0; }, node_blocks = { block0 = { node0 = FunctionDeclaration(); node1 = BindName(ident0, node0); node2 = FunctionDefinition(node0, block1); }, block1 = { node0 = IntegerLiteral(int0): node_xref1; node1 = ReturnExpression(node0); }, } ``` Co-authored-by: Chandler Carruth <chandlerc@gmail.com>	2022-11-11 14:10:13 -08:00
Jon Ross-Perkins	57090142e8	Start adding builtins to SemanticsIR (#2356 ) This starts adding builtins with TypeType and IntegerLiteralType. Note, structurally that's all they are, and not directly accessible in any way. Adds a type field to SemanticsNode. Now, IntegerLiteralType can be identified as having type=TypeType, and IntegerLiteral as type=IntegerLiteralType. The current iteration doesn't do anything for type propagation, because I wanted to avoid making this too big. This also switches the Identifier IR to instead BindName, with some side-effects. I'd been trying to think how to provide a name for TypeType, and switching around how things worked seemed like a better approach. And while I think it's the right direction (e.g., alias should just be a BindName), I also realized I don't need to name TypeType: there's probably a keyword to refer to the builtin, so it shouldn't use regular name lookup.	2022-10-28 14:16:51 -07:00

Author

SHA1

Message

Date

Jon Ross-Perkins

4c8fdf5124

Start drafting out semantic type checking. (#2406 )

This is a first pass at what semantic type checking might look like. Types propagate along nodes, we use an InvalidType object when there's an error, and once there's an InvalidType we stop doing so much type checking.

This adds some RealLiteral handling in order to get type mismatches. I'm cautious about creating some real value for SemanticsIR (since the tokenized buffer version is a bit constrained), so I'm not doing that yet. But I will probably need to in order to maintain SemanticsIR having hermetic copies of its data, without a parse tree dependency.

2022-11-17 13:36:40 -08:00

Jon Ross-PerkinsandChandler Carruth

352fec1885

Add some coarse debug information to semantics. (#2382 )

Example stack:

```
1.	node_stack_:
	0.	FunctionDefinitionStart
	1.	ReturnStatement -> node1
2.	node_block_stack_:
	0.	block0
	1.	block1
```

Example trace output:

```
*** SemanticsParseTreeHandler::Build Begin ***
Push 0: FunctionIntroducer
Push 1: DeclaredName
Push 2: ParameterListEnd
Pop 2: ParameterListEnd
Push 2: ParameterList
Pop 2: ParameterList
Pop 0: FunctionIntroducer
AddNode block0: FunctionDeclaration()
AddNode block0: BindName(ident0, node0)
AddNode block0: FunctionDefinition(node0, block1)
Push 0: FunctionDefinitionStart
Push 1: Literal -> IntegerLiteral
AddNode block1: IntegerLiteral(int0): node_xref1
Push 2: StatementEnd
Pop 2: StatementEnd
Pop 1: any (Literal) -> node0
Push 1: ReturnStatement -> ReturnExpression
AddNode block1: ReturnExpression(node0)
Pop 0: FunctionDefinitionStart
Push 0: FunctionDefinition
*** SemanticsParseTreeHandler::Build End ***
cross_reference_irs.size == 2,
cross_references = {
  node_xref0 = "xref(ir0, block0, node0)";
  node_xref1 = "xref(ir0, block0, node1)";
},
identifiers = {
  ident0 = "Foo";
},
integer_literals = {
  int0 = 0;
},
node_blocks = {
  block0 = {
    node0 = FunctionDeclaration();
    node1 = BindName(ident0, node0);
    node2 = FunctionDefinition(node0, block1);
  },
  block1 = {
    node0 = IntegerLiteral(int0): node_xref1;
    node1 = ReturnExpression(node0);
  },
}
```

Co-authored-by: Chandler Carruth <chandlerc@gmail.com>

2022-11-11 14:10:13 -08:00

Jon Ross-Perkins

57090142e8

Start adding builtins to SemanticsIR (#2356 )

This starts adding builtins with TypeType and IntegerLiteralType. Note, structurally that's all they are, and not directly accessible in any way.

Adds a type field to SemanticsNode. Now, IntegerLiteralType can be identified as having type=TypeType, and IntegerLiteral as type=IntegerLiteralType. The current iteration doesn't do anything for type propagation, because I wanted to avoid making this too big.

This also switches the Identifier IR to instead BindName, with some side-effects. I'd been trying to think how to provide a name for TypeType, and switching around how things worked seemed like a better approach. And while I think it's the right direction (e.g., alias should just be a BindName), I also realized I don't need to name TypeType: there's probably a keyword to refer to the builtin, so it shouldn't use regular name lookup.

2022-10-28 14:16:51 -07:00