Tags give the ability to mark specific points in history as being important
-
-
-
v0.30.0
protected7370976c · ·OctoGo v0.30.0 Two silent wrong answers on the board, and the last hole in the lifetime rules. A constant on the LEFT of an unsigned operand was typed signed by the C backend. The value it produced was right, which is what hid it: nothing looked wrong until a division, a shift or an ordering comparison read the type, and then each took the signed branch and answered wrongly. The same expression with the operands the other way round had been right all along. And a guarded division read the type of its own left operand, so `3 / b` for a 64-bit b was typed int, chose a 32-bit zero-guard, and aborted a program that divides by a perfectly good number. Neither was visible on the host, whose C compiler is correct about both. Both are now covered by generated crosses that run on the board. A reference could still outlive its frame through a method on a LOCAL receiver -- the last receiver shape the crossing summary could not name. With it the escape matrix closes: every reference kind, against every sink, through every receiver a call can be made on. Elsewhere: a Builder may live in a struct field, a package array literal may have computed elements instead of failing to build at all, a method may be called on a parenthesised expression, and p2.WaitUntil makes the drift-free control loop expressible.
-
v0.29.0
protectedebe1186a · ·OctoGo v0.29.0 Lifetime rules that hold at every spelling, and the array as a value. A reference could still reach storage that had gone, by routes the rules did not recognise: nested in a composite literal, carried out by an append, stored into a method's receiver, stored through a pointer parameter, and -- past all of them -- through an interface, where the call names no function and so nothing was asked at all. Each was a build that succeeded and then read a dead frame. Two of them change what compiles rather than only what is caught. A call through an interface is judged against every implementation at once, so one that keeps its argument constrains the calls even where the value assigned is one that does not. And a reference may no longer outlive the block of the variable it points at, which is what makes Go's per-iteration loop variable mean here what it means in Go rather than quietly meaning what it meant before Go 1.22. The second arc is the array reached by a longer route than its own name: a method may return one, be called on an element, yield several results from one, run on a cog and survive a defer, and a package array variable may be initialized by anything a local can be.
-
v0.28.0
protected29c3f86a · ·OctoGo v0.28.0 References that outlive their frame, and arrays reached by a longer route.
-
v0.27.0
protectedf0df93ac · ·OctoGo v0.27.0 A nil pointer dereference stops the program. Address zero on this target is ordinary Hub RAM, not a trap, so a read through a nil pointer used to yield whatever lives at 0 and a WRITE stored into the boot area, both silently, where Go panics for each. It joins the runtime-check family -- out-of-range index and slice, division and remainder by zero, negative shift, append past capacity, cog exhaustion -- with the same "panic: <what>" and the same halt, and --unchecked omits it with the rest. A pointer to an ARRAY is the exception, and it is the C backend's doing rather than a decision: flexcc drops a store made through a pointer-to-array that came out of a function, so the guard would cost the write it guards. Reduced in doc/ptr-to-array-through-call.c. Two documentation claims did not survive being tested: ogo help build named four of the six runtime checks, and a defined type over a struct is not distinct from that struct, though specs.go said every defined type was. Verified on a P2-EDGE.
-
-
-
-
-
-
-
v0.20.0
protectedbd050a21 · ·v0.20.0 Arrays as element types: a slice or a channel may have an array element of any rank, [][2]int, chan [3]int, chan [2][3]int, with make, indexing, range, append, copy, reslicing, literals, struct fields and select over them. The slice half shipped in v0.18.0 and was withdrawn in v0.19.0. That withdrawal was right about the code and wrong about the reason: a pointer to a typedef'd array is fine on this target, and what corrupted the program was a generated helper taking the element by value -- a parameter whose TYPE is a typedef'd array corrupts unrelated code elsewhere in the same translation unit. doc/array-param-corrupts.c reduces it to thirty lines. Every such helper takes a pointer now, which is what made the channel forms possible too.
-
v0.19.0
protected2fc547ff · ·v0.19.0 The release that went looking for miscompiles and found seven. A struct holding a field narrower than a machine word was mishandled in five places on the target, silently, and two functions whose result lists spelled the same struct name shared one struct. All are fixed; doc/return-nonword-struct.c records which positions the backend warned about and which were actually broken. One feature was withdrawn: a slice whose element is an array shipped in v0.18.0 and is gone, the target's compiler mismodelling a pointer to an array in a way that is wrong for some programs and not others. Added: an array result used like any other value, go through a function value, a for header declaring and assigning several names, array literals where array variables go. Every function-valued form now works. All three documents were re-measured; eight claims were stale or never true. No prebuilt binaries with this tag.
-
v0.18.0
protectedd116c2dc · ·v0.18.0 A release about what a value may be and where it may stand: an array as a function result, an array literal wherever the position copies, a channel in a struct field, methods on a defined channel type, and a multi-result function as a value. The p2 package is embedded OctoGo source rather than a table taken on trust, so a misspelt intrinsic is a compiler error; cross-package calls are checked against real signatures. The parser gained a rule of its own: where an LL(1) grammar cannot describe a spelling, the parenthesised form may be required -- ([]int)(xs) works, []int(xs) does not, and both are valid Go. No prebuilt binaries with this tag.
-
-
-
-
-