Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

checker: fix fn call with option call argument in autofree mode (fix #19495) #19515

Merged
merged 1 commit into from
Oct 7, 2023

Conversation

yuyi98
Copy link
Member

@yuyi98 yuyi98 commented Oct 5, 2023

This PR fix fn call with option call argument in autofree mode (fix #19495).

import os

fn maybe_error() !string {
	return 'string'
}

fn return_string_result() ! {
	os.write_file('./test.txt', maybe_error()!)!
}

fn main() {
	return_string_result() or {
		println(err.msg())
		exit(1)
	}
}

PS D:\Test\v\tt1> v -autofree run .

Comment on lines +534 to +535
if arg.expr in [ast.Ident, ast.StringLiteral, ast.SelectorExpr]
|| (arg.expr is ast.CallExpr && arg.expr.or_block.kind != .absent) {
Copy link
Member

@spytheman spytheman Oct 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That indeed fixes the compilation, and may work for now, but consider, that the result of the callexpr arg, may be a string itself, or an array, or a map, or another struct, that was allocated inside that function:

import rand
fn f() !string { return rand.string(5) + '8' }
fn g(x string, y string) string { return x + y }
s := g( f()!, f()! )
println(s)

Here, both f()! and f()! will return different dynamically created strings, that will have to be freed, after g() finishes.

i.e. the cost of skipping those callexpression arguments, is allowing a preventable leak.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK,I see.

Copy link
Member

@spytheman spytheman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good for now (a compiling program is better than one failing with a cgen error), but it should be fixed properly later, so that the result is freed, for -autofree to work.

@medvednikov medvednikov merged commit f3e4963 into vlang:master Oct 7, 2023
47 checks passed
@yuyi98 yuyi98 deleted the fix_autofree_option_arg branch October 7, 2023 01:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

C error only with -autofree flag.
3 participants