Opened 3 years ago

Last modified 3 weeks ago

#1215 new enhancement

Warn about too specific type declarations

Reported by: syn Owned by:
Priority: minor Milestone: someday
Component: scrutinizer Version: 4.10.x
Keywords: Cc:
Estimated difficulty: hard

Description

The following program produces code that may segfault when compiled with specialization:

(: foo (-> string))

(define (foo) (read))

(print (string-ref (foo) 0))
$ csc -specialize foo.scm
echo '"foo"' | ./foo
f

$ echo 123 | ./foo             

Error: segmentation violation

	Call history:

	baz.scm:5: foo	  
	baz.scm:3: read	  	<--

I think the root cause is that the declared return type of foo is more specific than that of read. Perhaps this could be detected by the scrutinizer and warned about accordingly.

Change History (2)

comment:1 Changed 21 months ago by sjamaan

  • Estimated difficulty set to hard

comment:2 Changed 3 weeks ago by evhan

I added this feature, but it produces far too many warnings. Stuff like this:

Note: at toplevel:
  declared type `(procedure chicken.base#error (* #!rest *) noreturn)' of toplevel variable `chicken.base#error' is more specific than inferred type `(procedure chicken.base#error (#!rest) . *)'

Note: at toplevel:
  declared type `(procedure chicken.base#void (#!rest *) undefined)' of toplevel variable `chicken.base#void' is more specific than inferred type `(procedure chicken.base#void (#!rest) *)'

Note: at toplevel:
  declared type `(procedure chicken.base#sleep (fixnum) undefined)' of toplevel variable `chicken.base#sleep' is more specific than inferred type `(procedure chicken.base#sleep (*) *)'

We could add all sorts of rules about whether to issue a warning or not in order to cut down on the noise, but I'm not sure this feature would be worth the added complexity. Plus, we already issue a warning when the types are incompatible, so I'm more inclined to just close this wontfix.

Note: See TracTickets for help on using tickets.