PositionableStream>>upTo: anObject

I’m guessing that it is using the read before written tester from the refactoring browser. It treats ifTrue:ifFalse:/ifFalse:ifTrue: blocks and the receiver blocks of whileTrue/False: specially. All other blocks are considered potentially not executed. Therefore, it says that the or: block may not be executed so the “element” reference in the whileFalse: argument block may be read without any assignment.

The RB’s read before written tester is different from the compilers. The compiler’s version lets some things through that it shouldn’t, and I think the compiler should use the RB version instead. Here’s an example where the compiler generates incorrect code for the optimized “v” variable in the whileTrue:

| stream count |
count := 0.
stream := ReadStream on: #(true true true false false).
[ stream next and: [ | v | stream next ifTrue: [ v := 1 ]. v notNil ] ]
        whileTrue: [ count := count + 1 ].
count = 1

This should answer true, but answers false. The compiler should see that “v” may potentially be read before written, and therefore assign it to nil at the beginning of the or: block like would be done for an unoptimized block temporary. If you perform the #whileTrue: instead (to get a real block), you get the correct result:

| stream count |
count := 0.
stream := ReadStream on: #(true true true false false).
[ stream next and: [ | v | stream next ifTrue: [ v := 1 ]. v notNil ] ]
        perform: #whileTrue: with: [ count := count + 1 ].
count = 1


John Brant

> On Aug 16, 2016, at 3:23 PM, Nicolas Cellier <[hidden email]> wrote:
>
> initialization of element is conditional (in the or: block).
> I'm amazed, that's a new behavior, is it a consequence of using AST?
> But a dumb compiler not knowing the semantic of or: (it is a message like others) could conclude that element may be used uninitialized in the whileFalse block...
> A compiler that is inlining or: with a well known semantic has no excuse ;)
>
> 2016-08-16 22:12 GMT+02:00 stepharo <[hidden email]>:
> While browsing the system I saw that the following method raised a temp read before written...
>
> It did not jump to my eyes. Working on something else....
>
>
> PositionableStream>>upTo: anObject
>     "Answer a subcollection from the current access position to the
>     occurrence (if any, but not inclusive) of anObject in the receiver. If
>     anObject is not in the collection, answer the entire rest of the receiver."
>     | newStream element |
>     newStream := (collection species new: 100) writeStream.
>     [self atEnd or: [(element := self next) = anObject]]
>         whileFalse: [newStream nextPut: element].
>     ^newStream contents
>
>
>