What's the bullet point for this issue?
Not to allow #include in code if it contains a relative path?

Would love to work on it if @shivakumargn isn't

Yes, look at the cgo preamble comment and the C/C++ files (including header files) in the directory, and warn about uses of #include "" (not #include <>, <> is always OK) with a relative path that contains at least one path separator.

I'm on it!
@ianlancetaylor BTW, why check the files in the directory? I can just throw every include that contains the / char.
Or am I missing something?

I can just throw every include that contains the / char.

Includes that fall outside the Go source tree aren't our responsibility to warn about: #include "/usr/include/blah.h" is not usually a good idea, but not for the same reason as #include "subdir/blah.h".

OK, so I throw an error only when the include is in a subdir of the project, but not when it is directly in the same dir as the go file, and not when it's outside the src tree.

Got you right?

Should I throw a warning for the third case or just leave it be?

If it's outside the source tree, just leave it be. (It's not portable, but that is likely intentional: for example, the Go program may be a command-line tool for managing some aspect of a particular OS or distribution.)

Change https://golang.org/cl/126375 mentions this issue: vet: check for invalid Cincludes in cgo code

Hello @iamoryanmoshe, thank you for sending the CL and for taking this on!

As @mvdan and @thepudds had mentioned in the CL, these checks have moved from the standard library to https://godoc.org/golang.org/x/tools/go/analysis/cmd/vet aka https://github.com/golang/tools/tree/master/go/analysis/cmd/vet perhaps we can close the original CL and resurrect it by sending a CL to x/tools but also then I'll retitle this issue and we can even no longer tie it down to a specific release.