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

'not nil' check missing early function return. #1235

Open
GrundleTrundle opened this issue May 30, 2014 · 2 comments
Open

'not nil' check missing early function return. #1235

GrundleTrundle opened this issue May 30, 2014 · 2 comments
Assignees
Labels

Comments

@GrundleTrundle
Copy link
Contributor

I'm getting a "can't prove o.p is not nil" error for the following test code:

type
   RefObj = ref object
   A = object
      p: RefObj

proc action(o1: RefObj not nil) =
  echo "action"

proc check(o: A) =
   if o.p == nil:
      return

   action(o.p)    # <-- can't prove o.p is nil

var
   x : A

check(x)

It doesn't seem to recognize that the control flow won't reach that statement if o.p == nil.

@dom96 dom96 added this to the 0.9.6 milestone Aug 14, 2014
@Araq
Copy link
Member

Araq commented Aug 14, 2014

This is how the algorithm has been designed. It needs better documentation, but it is on par with the FP pattern matching solution so definitely good enough for version 1, IMO.

@dom96 dom96 removed this from the 0.9.6 milestone Aug 14, 2014
@wiml
Copy link
Contributor

wiml commented Sep 8, 2020

I just ran into this (I think) in Nim 1.2.6. This is a fairly frustrating defect — it makes it awkward to insert the manual nil checks at the boundaries between not nil and maybe nil code.

Although it might be a pain to track not-nil–ness through every kind of control flow, it seems to me that it should be straightforward for the compiler to understand the equivalence of

if condition:
   something-that-does-not-fall-through (like a return or raise)
more-statements

with

if condition:
   something-that-does-not-fall-through
else:
  more-statements

which would be good enough for quite a few use cases.

Clyybber pushed a commit to Clyybber/Nim that referenced this issue Mar 13, 2024
## Summary

Attempting to manually create a node (via `newNimNode`) of kind
`nnkError`, `nnkIdent`, `nnkSym`, or `nnkType` now results in a
compiler error. Creating them was previously allowed, but the
compiler could crash when such incomplete nodes appear in macro
output.

## Details

* all node kinds where the initial state is not valid (`nkError`,
  `nkIdent`, `nkSym`, and `nkType`) are forbidden
* the `opcNNewNimNode` implementation guards against the node kinds
* a VM event, diagnostic, and report is added for the error
* to not introduce a new variant, the `msg` variant is re-used for the
  new VM event
* the untyped `nnkType` test case is removed from `tempty_type_nodes`;
  macros cannot create untyped `nnkType` nodes anymore
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants