Opened 13 years ago
Closed 10 years ago
#759 closed defect (fixed)
scrutinizer: extend special case for result-type of "list-ref"/"list-tail" to handle nested "(pair ...)" types
Reported by: | felix winkelmann | Owned by: | evhan |
---|---|---|---|
Priority: | not urgent at all | Milestone: | |
Component: | compiler | Version: | 4.7.x |
Keywords: | scrutinizer list-ref list-tail | Cc: | |
Estimated difficulty: |
Description
As pointed out by sjamaan, changeset f335156a069b4be8c3ec90c1c3f5bddb076f2759 doesn't handle nested pair types. This should be added.
Change History (2)
comment:1 Changed 10 years ago by
Owner: | changed from felix winkelmann to evhan |
---|---|
Status: | new → assigned |
comment:2 Changed 10 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Fixed by b946076726a7800301dbf1deac0463829e2498db and more generally/for a few other procedures by the changesets immediately following it.
Note: See
TracTickets for help on using
tickets.
As of 504ec7a30debc416d300157ffb542e660231f08b, nested pair types that have an equivalent
(list ...)
form are handled correctly (since they're rewritten as such during simplification).What isn't handled are nested pair types that we can't safely rewrite to
(list ...)
type forms. So, I think this ticket now boils down to extending the special case s.t. it walks pair type forms as far as possible, too. For example, iffoo
has type(pair fixnum (pair fixnum *))
,(list-ref foo 1)
should resolve to typefixnum
(even though we don't know for sure whetherfoo
is a proper list).