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

compile-time use of undefined value detection #597

Open
andrewrk opened this issue Nov 7, 2017 · 8 comments
Open

compile-time use of undefined value detection #597

andrewrk opened this issue Nov 7, 2017 · 8 comments
Labels
enhancement Solving this issue will likely involve adding new logic or components to the codebase. frontend Tokenization, parsing, AstGen, Sema, and Liveness.
Milestone

Comments

@andrewrk
Copy link
Member

andrewrk commented Nov 7, 2017

extern fn bar();
export fn entry() {
    var a: i32 = undefined;
    if (a > 10) {
        bar();
    }
}

Zig should be able to detect that we will with 100% certainty branch on an undefined value.

Related:

export fn entry() {
    unreachable;
}

Should be an error, because it's 100% certain at compile-time that we will reach unreachable code.

Not to be confused with #211 which is adding extra code and data in safety-enabled builds to detect use of undefined value at runtime.

@andrewrk andrewrk added the enhancement Solving this issue will likely involve adding new logic or components to the codebase. label Nov 7, 2017
@andrewrk andrewrk added this to the 0.3.0 milestone Nov 7, 2017
@pluto439
Copy link

pluto439 commented Nov 7, 2017

After a = undefined, will I be able to create another variable with the same name, but a different type?

@andrewrk
Copy link
Member Author

andrewrk commented Nov 7, 2017

No, you would need to make a go out of scope. This use case is not supported because we want code readers to have the guarantee that within a scope, if you see a variable name, that same variable name is the same type and refers to the same memory location in the entire scope.

@pluto439
Copy link

pluto439 commented Nov 7, 2017

It's not the same as deleting a variable then. I want it to stop existing, completely. I will only ever delete variables that are temporary anyway.

Probably a wrong place to talk about it, should've I wrote this in the closed issue?

@PavelVozenilek
Copy link

PavelVozenilek commented Nov 9, 2017

@pluto439:

After a = undefined, will I be able to create another variable with the same name, but a different type?

You are asking for feature similar to "hyperstatic scope" used in Forths ( http://wiki.c2.com/?HyperStaticGlobalEnvironment ). Here it is used for functions (Forth doesn't have anything else) and allows to reuse their names, reducing the need to invent unique names all the time. It is one of Forth's strong points.

@pluto439
Copy link

pluto439 commented Nov 9, 2017

@PavelVozenilek

That's too smart for me. I'm just trying to steal the del keyword from python. Which in c-like languages will mean "free stack, or mark this place on stack as free to reuse".

@PavelVozenilek
Copy link

@pluto439

Which in c-like languages will mean "free stack, or mark this place on stack as free to reuse".

LLVM does this automatically, it is called "stack slot coloring".

@pluto439
Copy link

@PavelVozenilek I know, but didn't knew it's called "stack slot coloring". Just wanted to say that it's possible for compiled languages too, and not for interpreted ones only.

It's more of a hint for a programmer that this variable will not be used again, and also a safety net. More details here #594, further discussion should be there I guess.

@andrewrk andrewrk modified the milestones: 0.3.0, 0.4.0 Feb 28, 2018
@andrewrk
Copy link
Member Author

Related: #1947

@andrewrk andrewrk modified the milestones: 0.4.0, 0.5.0 Feb 15, 2019
@andrewrk andrewrk modified the milestones: 0.5.0, 0.6.0 Sep 11, 2019
@andrewrk andrewrk modified the milestones: 0.6.0, 0.7.0 Feb 10, 2020
@andrewrk andrewrk added the frontend Tokenization, parsing, AstGen, Sema, and Liveness. label Oct 9, 2020
@andrewrk andrewrk modified the milestones: 0.7.0, 0.8.0 Oct 9, 2020
@andrewrk andrewrk modified the milestones: 0.8.0, 0.9.0 Jun 4, 2021
@andrewrk andrewrk modified the milestones: 0.9.0, 0.10.0 Nov 21, 2021
@andrewrk andrewrk modified the milestones: 0.10.0, 0.11.0 Jun 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Solving this issue will likely involve adding new logic or components to the codebase. frontend Tokenization, parsing, AstGen, Sema, and Liveness.
Projects
Status: To do
Development

No branches or pull requests

3 participants