Primitive return type of loop and try is lost

Description

Generates the following warnings:

This is interesting for several reasons. For one, if the arg to recur is a let form, there is no warning:

Also, the compiler appears to understand the return type of loop forms just fine:

The problem can of course be worked around using an explicit cast on the loop form:

Reported by leafw in IRC: http://clojure-log.n01se.net/date/2011-01-03.html#10:31

See Also:

Patch: 0001-CLJ-701-add-HoistedMethod-to-the-compiler-for-hoisti-v2.patch

Environment

Clojure commit 9052ca1854b7b6202dba21fe2a45183a4534c501, version 1.3.0-master-SNAPSHOT

Activity

Show:
Kevin Downey
January 20, 2016, 6:05 AM

the latest patch applied to master is causing some test failures for data.xml

Nicola Mometto
January 20, 2016, 11:54 AM

that's still an invalid type hint. Clojure is inconsistent all over the place with enforcing valid type hints, so even though I think we should handle the VerifyError explicitly, I don't think we need to care about making that code work.

WRT ^boolean type hints going to be common because clojurescript uses them – I don't think we should accept invalid code for the sake of interoparability. See CLJ-1883 for an instance of such a wrong type hint being used in Om, the solution was to fix Om, not to make the clojure compiler ignore yet another wrong type hint.

Kevin Downey
April 19, 2016, 7:17 PM

I've just got around to trying to dig in to the data.xml failures I mentioned above.

Both those tests are related to head holding on a lazy seq. Both tests reliably fail with 0002-CLJ-701-add-HoistedMethod-to-the-compiler-for-hoisti.patch

So I suspect the hoisted method isn't properly clearing locals.

Kevin Downey
April 19, 2016, 11:56 PM

so I don't forget, I realized the issue with data.xml is because the 'is' macro in the test expands in to a try/catch in an expression context, which is hoisted, and the hoist causes the whole environment not to be cleared until the hoisted method returns, which is obviously not correct.

Alex Miller
November 23, 2020, 2:32 PM

Adding another example provided by user:

It appears that a boolean literal does not match a primitive boolean when recurring:

Using (boolean false) makes the error disappear.

Assignee

Unassigned

Reporter

chouser

Labels

None

Approval

Vetted

Patch

Code and Test

Affects versions

Priority

Major
Configure