T-SQL: a CREATE FUNCTION swallows the declaration that follows it — the next CREATE VIEW is silently absent

[YNFM]

graphify 0.9.39, Windows, Python 3.14.2, graphify . --code-only (AST only, no backend).

A CREATE FUNCTION consumes the declaration that follows it. The function itself is extracted; the next statement is not. Swapping the function for a procedure — same file, same following statement — extracts all three.

Found while isolating a separate bracket-quoting defect; this one is independent of quoting and reproduces with bare identifiers.

Repro

A — function, then view. schema.sql:

CREATE TABLE dbo.Customer (Id INT NOT NULL PRIMARY KEY);
GO
CREATE FUNCTION dbo.CustomerName (@Id INT)
RETURNS INT
AS
BEGIN
    RETURN (SELECT Id FROM dbo.Customer WHERE Id = @Id);
END
GO
CREATE VIEW dbo.CustomerList
AS
    SELECT Id FROM dbo.Customer;
GO

graphify . --code-only

Actual — 3 nodes: schema.sql, dbo.Customer, dbo.CustomerName(). No dbo.CustomerList.

B — procedure, then the same view. Replace the function with:

CREATE PROCEDURE dbo.GetCustomer @Id INT
AS
BEGIN
    SELECT Id FROM dbo.Customer WHERE Id = @Id;
END
GO

Actual — 4 nodes: schema.sql, dbo.Customer, dbo.GetCustomer(), dbo.CustomerList. The view is back.

C — the view alone, with no callable before it, also yields all three nodes. So CREATE VIEW is extracted normally; it is the preceding CREATE FUNCTION that loses it.

Notes

• Both GO separators are present in every variant, so it is not a missing batch terminator.
• The same effect appears with a bracket-quoted function name (CREATE FUNCTION [dbo].[CustomerName] → 2 nodes, losing both the function and the view), so it is not the bracket defect I filed separately, and unrelated to T-SQL: bracket-quoted identifiers keep their brackets — [dbo].[Customer] becomes the label dbo].[Customer, so no lookup by real name matches #2712/T-SQL: a bracketed FOREIGN KEY can drop the child table entirely and emit a self-referencing edge tagged EXTRACTED #2713.
• Only the immediately following declaration is affected in these cases; I have not tested how far the swallow extends in longer files, and the effect is easy to miss in a large corpus because the lost declaration produces no warning — the build exits 0 and the graph simply omits it.

The practical consequence is that whether a declaration appears in the graph depends on what precedes it, which makes a node's absence hard to attribute to anything.