watch: excessive memory usage [6gb...]

[Ddiidev]

Describe the bug

When there is an error in the query syntax in the orm, and being executed with watch, it consumes a lot of memory.

In the video he used 6GB, but then it's like 🧑🏻‍🚀 Buzz Lightyear would say: "to infinity and beyond"
https://github.com/vlang/v/assets/7676415/800e3654-8de5-4e13-8520-72bd1765a59b

Reproduction Steps

1. sql db {...}! cannot return to any variable;
2. sql db {...}! must have an error in the syntax, be it the wrong name or operator (as in the case of the example code);
3. needs to be executed with watch, otherwise the compiler will identify an error such as: teste.v:65:3: error: unexpected keyword select, expecting name or fail when analyzing the syntax (everything occurs as expected)

example:

module main

import db.sqlite

@[table: 'modules']
struct Module {
	id           int    @[primary; sql: serial]
	name         string
	nr_downloads int    @[sql: u64]
	creator      User
}

struct User {
	id             int    @[primary; sql: serial]
	age            u32    @[unique: 'user']
	name           string @[sql: 'username'; sql_type: 'VARCHAR(200)'; unique]
	is_customer    bool   @[sql: 'abc'; unique: 'user']
	skipped_string string @[skip]
}

struct Parent {
	id       int     @[primary; sql: serial]
	name     string
	children []Child @[fkey: 'parent_id']
}

struct Child {
	id        int    @[primary; sql: serial]
	parent_id int
	name      string
}

fn main() {
	eprintln('------------ ${@METHOD} -----------------')
	mut db := sqlite.connect(':memory:')!
	defer {
		sql db {
			drop table Parent
			drop table Child
		} or {}
		db.close() or {}
	}

	sql db {
		create table Parent
	}!
	sql db {
		create table Child
	}!
	par := Parent{
		name: 'test'
		children: [
			Child{
				name: 'abc'
			},
			Child{
				name: 'def'
			},
		]
	}
	sql db {
		insert par into Parent
	}!
	sql db {
		select from Parent where id == 1 & name == "whatever"
	}!
	eprintln(parent)
}

Expected Behavior

teste.v:65:34: error: infix expr: cannot use `string` (right expression) as `int literal`
   63 |     }!
   64 |     parent := sql db {
   65 |         select from Parent where id == 1 & name == "whatever"
      |                                        ~~~~~~~~
   66 |     }!
   67 |     eprintln(parent)
teste.v:65:28: error: infix expr: cannot use `string` (right expression) as `bool`
   63 |     }!
   64 |     parent := sql db {
   65 |         select from Parent where id == 1 & name == "whatever"
      |                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   66 |     }!
   67 |     eprintln(parent)
teste.v:65:34: error: ORM: left side of the `&` expression must be one of the `Parent`'s fields
   63 |     }!
   64 |     parent := sql db {
   65 |         select from Parent where id == 1 & name == "whatever"
      |                                        ^
   66 |     }!
   67 |     eprintln(parent)

Current Behavior

High memory consumption

Possible Solution

I don't know exactly, but it seems to me that the watch is not taking into account that this specific part made an error and it continues to reset the process (I could be wrong)

Additional Information/Context

No response

V version

V 0.4.4 bc37c85.c9933da

Environment details (OS name and version, etc.)

V full version: V 0.4.4 bc37c85.c9933da
OS: windows, Microsoft Windows 11 Pro v22631 64 bits
Processor: 12 cpus, 64bit, little endian,

getwd: C:\Users\andre\Desktop
vexe: E:\Progs\v\v.exe
vexe mtime: 2024-02-13 06:22:48

vroot: OK, value: E:\Progs\v
VMODULES: OK, value: C:\Users\andre\.vmodules
VTMP: OK, value: C:\Users\andre\AppData\Local\Temp\v_0

Git version: git version 2.43.0.windows.1
Git vroot status: weekly.2023.50-458-gc9933da6-dirty (44 commit(s) behind V master)
.git/config present: true

CC version: Error: 'cc' não é reconhecido como um comando interno
ou externo, um programa operável ou um arquivo em lotes.

thirdparty/tcc status: thirdparty-windows-amd64 a39eb79b-dirty

Note

You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote.
Other reactions and those to comments will not be taken into account.

[MCausc78]

Related: #20276

[spytheman]

Your issue is not very related @MCausc78 . The root cause of this issue, is in the parser, which had a loop, that did not expect an EOF token, and can be fixed by this patch in vlib/v/parser/orm.v:

        for p.tok.kind != .rcbr {
+               if p.tok.kind == .eof {
+                       p.unexpected_with_pos(pos, got: 'eof, while parsing an SQL statement')
+                       return ast.SqlStmt{}
+               }
                lines << p.parse_sql_stmt_line()
        }

The root cause of your issue, is in the checker, and the ast modules, where a type is stringified in a way, that causes an infinite recursion, and is not very easy to fix, and I think that currently the best we could to is put a limiter/counter instead.