Function Declarations

Topic Overview

Parsing Function Signatures

Function declarations introduce a name, parameter list, and return type into the program's structure. Clang's ParseFunctionDefinition and GCC's declarator parsing handle prototypes vs definitions, variadic parameters, and pointer return types. Getting signatures right here feeds directly into type checking.

Grammar Sketch

A declaration looks like type name(type param, ...) { body } or a prototype ending in ;. The parser must collect parameter names and types, build an AST node, and distinguish forward declarations from definitions with bodies.

cCopy
Loading…

• Parameter list may be empty: void foo(void) vs void foo()
• Return type can be pointer or struct name
• Prototypes end with semicolon; definitions have a block body
• Store parameter types for signature checking later

Connecting to real compilers

Production compilers embed this step inside a longer pipeline. GCC flows through cpp, cc1, assembly, and ld; Clang uses the driver, Sema, LLVM IR passes, and a target backend. LLVM bitcode, JVM bytecode, and WASM are other familiar IRs at the same layer. The exercise isolates one pass so you can test it alone before chaining it to the next stage.

Why for this exercise

You will parse function declarations and definitions including parameter lists and return types. This exercise requires building AST nodes that carry full function signatures for the semantic analysis pass to validate call sites.

Your Task

Grow the statement parser from Statement Parsing into a parser for whole translation units: function definitions, prototypes, parameter lists, local declarations and function calls.

Input

C-subset source on stdin. On top of the previous task's tokens, int, void and char are keywords and , is a token.

Grammar (additions to the previous task)

cCopy
Loading…

A function ending in ; is a prototype. (void) and () both mean "no parameters".

Output

For each function, in order, a header line:

cCopy
Loading…

(() when there are no parameters.) A definition's body statements follow, indented two spaces, printed exactly as in Statement Parsing (the body's own braces print no BLOCK line), plus:

• a declaration prints as DECL TYPE NAME or DECL TYPE NAME VALUE;
• a call prints as the S-expression (call NAME ARG1 ARG2 ...), e.g. (call f) with no arguments.

Finally functions=F prototypes=P calls=C, where C counts every call expression, nested ones included.

Errors

As in the previous task: stop at the first error and print only error at LINE:COL: MESSAGE. New messages: expected type (where a function or parameter must start), expected identifier, and expected '{' or ';' (after a function's parameter list).

Example

Input:

cCopy
Loading…

Output:

cCopy
Loading…

Requirements

1. parse_function, parse_params, parse_declaration and call parsing inside parse_primary (an identifier followed by ( is a call).
2. Keep a NODE_FUNC_DECL-style record with the return type, name, parameter list and an optional body.

Hidden tests cover calls with zero and many arguments, calls inside conditions and loops, uninitialised declarations, many parameters, and a stray trailing comma in a parameter list.