[-v] cmd/compile: incorrect package initialization order for spec example

Picking up from #1 ...
Todo

[x] determine state needed in walk in order to generate lout properly
[x] populate the state!
[ ] generate lout properly
[ ] clean up any code elsewhere in Go that depends on this buggy behavior

Then

[ ] find a nicer way to initialize Deps
[ ] consider bool instead of struct{} for deps
[ ] unit test Deps
[ ] I guess static variables are added directly so shouldn't be included?
[ ] ensure all sorts of assignments are covered, expand test suite
[ ] make sure pointer usage is correct
[ ] protect against infinite looping
[ ] check performance
[ ] sort dcls by number of deps?
[ ] test traversing across multiple functions

Meanwhile

[ ] https://tour.golang.org/methods/18
[ ] https://golang.org/doc/code.html
[ ] https://golang.org/doc/effective_go.html
[ ] https://github.com/golang/go/wiki/SliceTricks

Finally

[ ] https://github.com/golang/go/wiki/CodeReviewComments
[ ] https://golang.org/doc/contribute.html

Further

[ ] investigate OAS2 and OASOP—what happens if I x,y = 1,2 or x = 1; x += 1 in xtop?
[ ] investigate Ninit—does initreorder ever actually recurse? Can we get some test coverage reporting?
[ ] investigate nf—what if we have init functions but no statements? really return early?

Are there some side-effects to initreorder (beyond sinit.go)? If not then I am thinking about maybe starting a rewrite there. Can we store state in some intermediate data structure (a la initplans), which we update while walking and then use to generate the final lout?

Here are the functions in sinit.go:
addMapEntries
addvalue
anylit
fixedlit
foundinitloop
genAsStatic
getdyn
getlit
init1
init2
init2list
initfix
initplan
initreorder
isLiteral
isStaticCompositeLiteral
isZero
isvaluelit
litas
maplit
oaslit
slicelit
stataddr
staticassign
staticcopy
staticinit
staticname

Just looking at the requirements, my first thought is to keep a) a deque of
variable names in declaration order, and b) a map of variable names to stacks
of requirements for each variable. When we see a LHS we push the variable name
onto (a) and file an empty stack under the variable name in (b). During RHS
processing we push dependencies onto the stack in (b). After processing a
complete declaration we flatten (a) and (b) by recursing through them and
appending to the out list when we find an empty stack in (b).

https://github.com/chadwhitacre/go/issues/1#issuecomment-341645348

Here is global state:
initlist
initplans
inittemps

And here is the call graph ( ↺ indicates a nested recursion):
initfix
  initreorder
    initreorder
    init1
      init1
      init2
        init1 ↺
          init2list
            init2 ↺
      init2list
        init2
      foundinitloop
      staticinit
        staticassign
          staticassign
          initplan
            addvalue
              initplan ↺
              isZero
                isZero
              isvaluelit
          isZero
            isZero
          stataddr
            getlit
          staticcopy
            staticcopy
            isZero
              isZero
            staticassign ↺
          staticname

Aaaand here is a call graph coming in from walk.go(!) ( ↺ indicates a nested recursion):
oaslit
  anylit
    anylit
    slicelit
      fixedlit
        fixedlit
        genAsStatic
          stataddr
        isLiteral
        slicelit ↺
      getdyn
        getdyn
        isLiteral
      isLiteral
      stataddr
        stataddr
        getlit
      staticname
    fixedlit
    staticname
  maplit
    addMapEntries
    isStaticCompositeLiteral
      isStaticCompositeLiteral
    litas
    fixedlit
    staticname

Yeah, okay, getting back into it: right now declarations are sorted by a) reverse dependency and b) RHS appearance (i.e., usage or reference), but they need to be sorted by a) reverse dependency and b) LHS appearance (i.e., declaration).
That is, b and c still need to come before a, but b needs to come before c.

 I expected a b c d. 🤔

With 9e14150:
# go run run.go -- ../test/fixedbugs/issue22326.go
exit status 1
# command-line-arguments
seeing a
declaring a
declaring c
declaring d
declaring b
seeing b
seeing c
seeing d
panic: b is 5 not 4

goroutine 1 [running]:
main.expect(...)
        /Users/whit537/workbench/go/src/github.com/golang/go/test/fixedbugs/issue22326.go:21
main.main()
        /Users/whit537/workbench/go/src/github.com/golang/go/test/fixedbugs/issue22326.go:26 +0x267
exit status 2

FAIL    ../test/fixedbugs/issue22326.go 1.083s
exit status 1
$

36d9e34
0 declaring a
first time using a
first time using c
first time using d
first time using b
0 declaring b
0 declaring c
0 declaring d

Here's a sketch of data structures and an algorithm to add to initfix:
dcls: [a,b,c,d]

deps:
	a: [c,b]
	b: [d]
	c: [d]
	d: []

depsback:
	d: [c,b]
	c: [a]
	b: [a]
	a: []

while dcls:
	for n in dcls:
		if deps[n]:
			continue

		lout.append(n)
		dcls.remove(n)

		for o in depsback[n]:
			deps[o].remove(n)

c2cebfe:
declaring a at depth 0
first time using a
first time using c
first time using d
first time using b
declaring b at depth 0
declaring c at depth 0
declaring d at depth 0
 out: a, b, c, d
lout: c, b, a

Here's logging that includes the d = 3 assignment: 02a1c00.
declaring a at depth 0
expecting a
expecting c
expecting d
s'initing d
appending c at point (1)
expecting b
appending b at point (1)
appending a at point (1)
declaring b at depth 0
declaring c at depth 0
declaring d at depth 0
dcls: a, b, c, d
 out: a, b, c, d
lout: c, b, a

Alright, sooo ... I'm pretty sure expecting always comes before appending/s'initing. I think that's the time to populate keys in dep/depsback. But ... values?

Progress! Now how about b expecting d? That's the one we need!
4e75238
declaring a at depth 0
root is expecting a
a is expecting c
c is expecting d
s'initing d
appending c at point (1)
a is expecting b
appending b at point (1)
appending a at point (1)
declaring b at depth 0
declaring c at depth 0
declaring d at depth 0
dcls: a, b, c, d
 out: a, b, c, d
lout: c, b, a

I'm referring to https://github.com/golang/go/issues/22326#issuecomment-443085177 in another tab through all of this, btw.

ea56f22 🤔
declaring a at depth 0
root is expecting a
a is expecting c
c is expecting d
s'initing d
already done: d
already done: d
already done: d
already done: f
appending c at point (1)
a is expecting b
already done: f
appending b at point (1)
already done: c
already done: b
appending a at point (1)
declaring b at depth 0
declaring c at depth 0
declaring d at depth 0
dcls: a, b, c, d
 out: a, b, c, d
lout: c, b, a

7c1eca0 💃
declaring a at depth 0
root is expecting a
a is expecting c
c is expecting function f
f is expecting d
s'initing d
already done: d
already done: d
already done: d
already done: f
appending c at point (1)
a is expecting b
already done: f
appending b at point (1)
already done: c
already done: b
appending a at point (1)
declaring b at depth 0
declaring c at depth 0
declaring d at depth 0
dcls: a, b, c, d
 out: a, b, c, d
lout: c, b, a

Alright, so we can get from c to d through f, but still where is b is expecting function f?

Got it! 😍 💃
6504037
declaring a at depth 0
root is expecting a
a is expecting c
c is expecting f
f is expecting d
s'initing d
f is expecting d
f is expecting d
f is expecting d
f is expecting d
appending c at point (1)
a is expecting b
b is expecting f
appending b at point (1)
appending a at point (1)
root is expecting c
root is expecting b
declaring b at depth 0
root is expecting b
root is expecting f
declaring c at depth 0
root is expecting c
root is expecting f
declaring d at depth 0
root is expecting d
dcls: a, b, c, d
 out: a, b, c, d
lout: c, b, a

💃💃💃💃💃💃
81f01ab
fwd:
        a: [c, b]
        c: [f]
        f: [d]
        b: [f]
bck:
        f: [c, b]
        d: [f]
        b: [a]
        a: []
        c: [a]

cb6308f
dcls: a, b, c, d
fwd:
        a: [c, b]
        c: [f]
        f: [d]
        b: [f]
bck:
        a: []
        c: [a]
        f: [b, c]
        d: [f]
        b: [a]
out:
processing a (=) ... skipped!
processing b (=) ... skipped!
processing c (=) ... skipped!
processing d (=) ... go!
dcls: a, b, c, d
fwd:
        a: [b, c]
        c: [f]
        f: [d]
        b: [f]
bck:
        a: []
        c: [a]
        f: [c, b]
        d: [f]
        b: [a]
 out: d
lout: c, b, a
panic: b is 5 not 4

f5cdd46
dcls: a, b, c, d
fwd:
        a: [c, b]
        c: [f]
        f: [d]
        b: [f]
bck:
        a: []
        c: [a]
        f: [c, b]
        d: [f]
        b: [a]
out:
f is a NAME and Func is &{<S>    [] [] [] 0 map[] <nil> <N> 0 <N> <N> <nil> 0xc000086bc0 0 {0 0} {0 0} 0 128 <nil>}
dcls: a, b, c
fwd:
        a: [c, b]
        c: [f]
        f: [d]
        b: [f]
bck:
        a: []
        c: [a]
        f: [b, c]
        d: [f]
        b: [a]
 out: d
lout: c, b, a
panic: b is 5 not 4

!!!!!!
removing c
removing c from fwd[a]
removing a from bck[c]
 dcls: a
  fwd:
        a: []
        c: []
        f: []
        b: []
  bck:
        a: []
        c: []
        f: []
        d: []
        b: []
  out: d, b, c
a ready? true
removing a
 dcls:
  fwd:
        a: []
        c: []
        f: []
        b: []
  bck:
        d: []
        b: []
        a: []
        c: []
        f: []
  out: d, b, c, a
 lout: c, b, a
panic: b is 5 not 4

😍 😍 😍 😍 😍 😍 😍 😍 😍 😍 😍
  out: b (=), c (=), a (=)
 lout: c (=), b (=), a (=)

That's acbf979. Still a ways to go, apparently a) lout != out for other cases, and b) there are some infinite loops.

Okay, trying to button together out and lout. Level-set with master 048c916:
$ make.bash
Building Go cmd/dist using /usr/local/Cellar/go/1.10.1/libexec.
Building Go toolchain1 using /usr/local/Cellar/go/1.10.1/libexec.

Building Go toolchain2 using go_bootstrap and Go toolchain1.
Building Go toolchain3 using go_bootstrap and Go toolchain2.
Building packages and commands for darwin/amd64.
---
Installed Go for darwin/amd64 in /Users/whit537/workbench/go/src/github.com/golang/go
Installed commands in /Users/whit537/workbench/go/src/github.com/golang/go/bin

Building out some logging on master bbc8369849e890edae3a1eb7dfbee5e04894744d:
https://github.com/chadwhitacre/go/blob/bbc8369849e890edae3a1eb7dfbee5e04894744d/src/make.log

Okay, I have lined up logging between the 22326 (this one) and 22326-alt branches. That shows that this 22326 branch is able to generate lout just like on master.

Getting there! Looks like something is up with deps removal? 🤔
686c59a
$ grep '^final' make.log | sort | uniq -c
 106 final result: infloop and mismatch!
 406 final result: match!
 105 final result: reordered!
$

The issue is with function transitivity. If a variable depends only on functions that do not themselves depend on non-functions, it is "ready".
----------------------------------------------------
file: src/hash/crc32/crc32.go
 dcls: IEEETable (= CALLFUNC)
  fwd:
        IEEETable: [simpleMakeTable]
        simpleMakeTable: [simplePopulateTable]
  bck:
        IEEETable: []
        simpleMakeTable: [IEEETable]
        simplePopulateTable: [simpleMakeTable]
  out:
IEEETable ready? false

Could we get simplePopulateTable: [] in fwd?

Closer with ceb4a7a ...
   5 final: infloop and mismatch!
 437 final: match!
 175 final: reordered!

... but the spec example is reordered incorrectly. 🤔
  out: c (= CALLFUNC), a (= +), b (= CALLFUNC)
 lout: c (= CALLFUNC), b (= CALLFUNC), a (= +)

a33bed0
  51 final: infloop and mismatch!
 428 final: match!
 138 final: reordered!

  out:
 lout: c (= CALLFUNC), b (= CALLFUNC), a (= +)

^^^ That handles the IEE case correctly, new one to fix is globalRand/rngCooked ...

76214da
  16 final: infloop and mismatch!
 437 final: match!
 164 final: reordered!

  out: c (= CALLFUNC), a (= +), b (= CALLFUNC)
 lout: c (= CALLFUNC), b (= CALLFUNC), a (= +)

I guess I'm trying to squeeze out the infloops and then think about proper ordering? Or maybe I should shake out the ordering bug next?

The two seem linked! ☺
 file: test/fixedbugs/issue22326.go
 dcls: c (= CALLFUNC), b (= CALLFUNC), a (= +)
  fwd:
	d: []
	b: [f]
	a: [c, b]
	c: [f]
	f: [d]
  bck:
	a: []
	c: [a]
	f: [c, b]
	d: [f]
	b: [a]
pruning to map[a = c + b:{} b = f():{} c = f():{}]
removing d
removing d from fwd[f]
removing f from bck[d]
removing f
removing f from fwd[c]
removing c from bck[f]
removing f from fwd[b]
removing b from bck[f]
removing b
removing b from fwd[a]
removing a from bck[b]
done pruning
 dcls: c (= CALLFUNC), b (= CALLFUNC), a (= +)
  fwd:
	c: []
	f: []
	d: []
	b: []
	a: [c]
  bck:
	a: []
	c: [a]
	f: []
	d: []
	b: []
  out:
c ready? true
removing c
removing c from fwd[a]
removing a from bck[c]
a ready? true
removing a
b ready? true
removing b
 dcls:
  fwd:
	a: []
	c: []
	f: []
	d: []
	b: []
  bck:
	a: []
	c: []
	f: []
	d: []
	b: []
final: reordered!
  out: c (= CALLFUNC), a (= +), b (= CALLFUNC)
 lout: c (= CALLFUNC), b (= CALLFUNC), a (= +)
panic: b is 5 not 4

goroutine 1 [running]:
main.expect(...)
	/Users/whit537/workbench/go/src/github.com/golang/go/test/fixedbugs/issue22326.go:21
main.main()
	/Users/whit537/workbench/go/src/github.com/golang/go/test/fixedbugs/issue22326.go:26 +0x267
exit status 2

FAIL	../test/fixedbugs/issue22326.go	0.514s
exit status 1

need an ordering in declaration order: is reverse(lout) that?
if b is removed why isn't c?

We need two things: declaration order and dependency order. We have declaration order in l. We the dependency graph in deps.

Huh. 5ebf2e1 is close to 76214da but not exactly the same. ¯\_(ツ)_/¯
  15 final: infloop and mismatch!
 437 final: match!
 167 final: reordered!

  out: c (= CALLFUNC), a (= +), b (= CALLFUNC)
 lout: c (= CALLFUNC), b (= CALLFUNC), a (= +)

162dd86
Subtle differences!
  17 final: infloop and mismatch!
 437 final: match!
 165 final: reordered!

  out: c (= CALLFUNC), a (= +), b (= CALLFUNC)
 lout: c (= CALLFUNC), b (= CALLFUNC), a (= +)

87e4534
Looks like sorted as implemented is not adequate, because it doesn't include nodes that are created under staticinit. 😖
  70 final: infloop and mismatch!
 308 final: match!
 149 final: mismatch!
  32 final: reordered!

go tool dist: FAILED: /Users/whit537/workbench/go/src/github.com/golang/go/pkg/tool/darwin_amd64/go_bootstrap install -gcflags=all= -ldflags=all= std cmd: exit status 2

If they're all static then they don't depend on anything, right? So we can just front-load them?

260df4c
  13 final: infloop and mismatch!
 388 final: match!
 158 final: reordered!

go tool dist: FAILED: /Users/whit537/workbench/go/src/github.com/golang/go/pkg/tool/darwin_amd64/go_bootstrap install -gcflags=all= -ldflags=all= std cmd: exit status 2

OAS2!

1e94a32
 387 final: match!
 172 final: reordered!

Phew! But still ...
go tool dist: FAILED: /Users/whit537/workbench/go/src/github.com/golang/go/pkg/tool/darwin_amd64/go_bootstrap install -gcflags=all= -ldflags=all= std cmd: exit status 2

f3099b5
 424 final: match!
 195 final: reordered!

Getting an order but it's a bad order:
  out: a = c + b, c = f(), b = f()
 lout: c = f(), b = f(), a = c + b

Maybe just reversed tho?

Ready is wrong?

Hah! One or the other! 😆
3574108
  11 final: infloop and mismatch!
 424 final: match!
 184 final: reordered!

  out: b = f(), c = f(), a = c + b
 lout: c = f(), b = f(), a = c + b

Pick up with defaultExpstring in src/cmd/internal/objabi/util.go ...

95724ba
   5 final: infloop and mismatch!
 425 final: match!
 189 final: reordered!

  out: b = f(), c = f(), a = c + b
 lout: c = f(), b = f(), a = c + b

Circular!
fwd:
        commands: [cmdbootstrap, cmdinstall]
bck:
        cmdinstall: [commands]
        cmdbootstrap: [commands]

cmdbootstrap and cmdinstall are functions ... why aren't they pruned?

Alright so we want to prune recursive functions.

7bc8f67
   5 final: infloop and mismatch!
 427 final: match!
 187 final: reordered!

  out: b = f(), c = f(), a = c + b
 lout: c = f(), b = f(), a = c + b

dc336f4
   5 final: infloop and mismatch!
 427 final: match!
 187 final: reordered!

  out: b = f(), c = f(), a = c + b
 lout: c = f(), b = f(), a = c + b

1dbd689
   5 final: infloop and mismatch!
 427 final: match!
 187 final: reordered!

  out: b = f(), c = f(), a = c + b
 lout: c = f(), b = f(), a = c + b

☺
0b4795d
 427 final: match!
 192 final: reordered!

  out: b = f(), c = f(), a = c + b
 lout: c = f(), b = f(), a = c + b

Ready!?

P.S. Max recursion was 43.

compile: location lists requested but register mapping not available on amd64

Tap, tap, tap ...

Okay! Back in it ... what's this bug?

Here's the failure:
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/compile/internal/gc/main.go#L345-L347

There are a few type Archs. Not obvious to me which one we have here ... the linker one (ld) I think? It doesn't define a Name attribute afaict but a Name attribute is referenced in a situation where it clearly is the linker Arch.
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/link/internal/ld/lib.go#L94-L147
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/link/internal/ld/lib.go#L1581-L1585
🤔

There's also this reference to LinkArch.Name:
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/compile/internal/gc/ssa.go#L57-L60

Alright, so let's say we have a LinkArch. Now what? It's supposed to have DWARFRegisters set but it doesn't

Uuuuhhhhh ... where are these set?!
$ ag '\.DWARFRegisters'
src/cmd/compile/internal/ssa/debug.go
966:                            regnum := state.ctxt.Arch.DWARFRegisters[state.registers[firstReg(loc.Register

src/cmd/compile/internal/gc/main.go
345:    if Ctxt.Flag_locationlists && len(Ctxt.Arch.DWARFRegisters) == 0 {
lines 1-5/5 (END)

I have a hunch (from bashing around towards the end of last time) that there's some code generation going on. I guess I need a compilers class! 😆

What's in here?
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/compile/internal/gc/main.go#L15

https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/internal/dwarf/dwarf.go#L5-L7

Here's where DWARFRegisters is declared, and yes it's on a LinkArch:
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/internal/obj/link.go#L667-L676

But where is it populated?

I think this is indicative?
cmd/internal/obj/x86/obj6.go
1283:   DWARFRegisters: AMD64DWARFRegisters,
1293:   DWARFRegisters: AMD64DWARFRegisters,
1303:   DWARFRegisters: X86DWARFRegisters,

cmd/internal/obj/x86/a.out.go
280:var AMD64DWARFRegisters = map[int16]int16{
376:var X86DWARFRegisters = map[int16]int16{

💃
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/internal/obj/x86/a.out.go#L279-L373

Alright, sooooooo ... hypothesis ... something about AMD64DWARFRegisters not being initialized when needed due to reordering ...

out snippet:
final: reordered!
  out: Linkamd64 = sys.ArchAMD64, Linkamd64 = unaryDst, Linkamd64 = AMD64DWARFRegisters, Linkamd64p32 = sys.Ar
 lout: AMD64DWARFRegisters = map[int16]int16 literal, X86DWARFRegisters = map[int16]int16 literal, isAndroid =
# cmd/asm/internal/arch

🤔
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/asm/internal/arch/arch.go

Sorry ... back in src/cmd/internal/obj/x86/a.out.go actually.

  out: Linkamd64 = sys.ArchAMD64, Linkamd64 = unaryDst, Linkamd64 = AMD64DWARFRegisters, Linkamd64p32 = sys.ArchAMD64P32, Linkamd64p32 = unaryDst, Linkamd64p32 = AMD64DWARFRegisters, Link386 = sys.Arch386, Link386 = unaryDst, Link386 = X86DWARFRegisters, AMD64DWARFRegisters = map[int16]int16 literal, unaryDst = map[obj.As]bool literal, isAndroid = objabi.GOOS == "android", X86DWARFRegisters = map[int16]int16 literal
 lout: AMD64DWARFRegisters = map[int16]int16 literal, X86DWARFRegisters = map[int16]int16 literal, isAndroid = objabi.GOOS == "android", unaryDst = map[obj.As]bool literal, Linkamd64 = sys.ArchAMD64, Linkamd64 = unaryDst, Linkamd64 = AMD64DWARFRegisters, Linkamd64p32 = sys.ArchAMD64P32, Linkamd64p32 = unaryDst, Linkamd64p32 = AMD64DWARFRegisters, Link386 = sys.Arch386, Link386 = unaryDst, Link386 = X86DWARFRegisters

Here's where AMD64DWARFRegisters is referenced:
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/internal/obj/x86/obj6.go#L1276-L1284

Alright, well, Linkamd64 depends on AMD64DWARFRegisters, and in lout for x86/a.out.go AMD64DWARFRegisters appears first, whereas in out Linkamd64 appears first.
But why is there a Linkamd64 assignment at all in a.out.go? There's no such in the source code.

Also it's weird to see Linkamd64 = AMD64DAWARFRegisters ... but I guess that's the way a sub-assignment gets represented:
out:
  Linkamd64 = sys.ArchAMD64
  Linkamd64 = unaryDst
  Linkamd64 = AMD64DWARFRegisters
  Linkamd64p32 = sys.ArchAMD64P32
  Linkamd64p32 = unaryDst
  Linkamd64p32 = AMD64DWARFRegisters
  Link386 = sys.Arch386
  Link386 = unaryDst
  Link386 = X86DWARFRegisters
  AMD64DWARFRegisters = map[int16]int16 literal
  unaryDst = map[obj.As]bool literal
  isAndroid = objabi.GOOS == "android"
  X86DWARFRegisters = map[int16]int16 literal

lout:
  AMD64DWARFRegisters = map[int16]int16 literal
  X86DWARFRegisters = map[int16]int16 literal
  isAndroid = objabi.GOOS == "android"
  unaryDst = map[obj.As]bool literal
  Linkamd64 = sys.ArchAMD64
  Linkamd64 = unaryDst
  Linkamd64 = AMD64DWARFRegisters
  Linkamd64p32 = sys.ArchAMD64P32
  Linkamd64p32 = unaryDst
  Linkamd64p32 = AMD64DWARFRegisters
  Link386 = sys.Arch386
  Link386 = unaryDst
  Link386 = X86DWARFRegisters

So which is right in this case? out or lout?

Ooooh ... we're not going to have to rewrite programs, are we? 🙈
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/internal/obj/x86/obj6.go#L299
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/internal/obj/x86/obj6.go#L488

Also note that the bug surfaces inside of func Main ... before we descend into fninit!
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/compile/internal/gc/main.go#L345-L347
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/compile/internal/gc/main.go#L677-L679

galign.go imports obj/x86
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/compile/internal/amd64/galign.go#L9
And that's where Linkamd64 and AMD64DWARFRegisters are defined:
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/internal/obj/x86/obj6.go#L31
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/internal/obj/x86/obj6.go#L1276
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/internal/obj/x86/a.out.go#L31
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/internal/obj/x86/a.out.go#L280

So which is right in this case? out or lout?

I believe the scope of the question is the cmd/internal/obj/x86 package, which according to out is the only place where Linkamd64 and AMD64DWARFRegisters appear.

There's a meta thing going on here.

Why is out6.go not in ./out (the logfile) at all?

Latest run was with return lout ...

P.S. Here is the command I'm running:
./make.bash > out 2>&1 && ../bin/go run ../test/run.go -- ../test/fixedbugs/issue22326.go >> out 2>&1

Logging tweaks in 93d14d0 (and drop back to lout).
 270 empty!
 156 match!
 189 reordered!

Still no obj6 in out. 🤔

What is the value of Ctxt.Arch.DWARFRegisters? nil?

Do I need to understand the bootstrapping process?

https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/make.bash#L6
golang.org/s/go15bootstrap → Google Doc

Like, which go is it that's failing the DWARF check? And when? Which of the five boostrapping steps is this in?

Build cmd/dist with Go 1.4.

Using dist, rebuild Go 1.x compiler toolchain with itself.

Using go_bootstrap, build the remaining Go 1.x standard library and commands.

Building Go toolchain3 using go_bootstrap and Go toolchain2.
# errors
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# internal/race
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# internal/cpu
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# runtime/internal/sys
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# sync/atomic
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# runtime/internal/atomic
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# unicode/utf8
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# unicode
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# math/bits
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# encoding
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# unicode/utf16
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
go tool dist: FAILED: /Users/whit537/workbench/go/src/github.com/golang/go/pkg/tool/darwin_amd64/go_bootstrap install -gcflags=all= -ldflags=all= -a -i cmd/asm cmd/cgo cmd/compile cmd/link: exit status 2

https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/dist/build.go#L1297
Appears to be the last toolchain (there is no toolchain4).

Alright, so does that mean that go_bootstrap is defective? Do we have that lying around somewhere we could poke at it?

$ find . -name go_bootstrap
./pkg/tool/darwin_amd64/go_bootstrap
$

$ ./pkg/tool/darwin_amd64/go_bootstrap env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/whit537/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/whit537/workbench/go"
GOPROXY=""
GORACE=""
GOROOT="/Users/whit537/workbench/go/src/github.com/golang/go"
GOTMPDIR=""
GOTOOLDIR="/Users/whit537/workbench/go/src/github.com/golang/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/77/7_nmc1957dv3rqv5l1wr5shh0000gn/T/go-build092131945=/tmp/go-build -gno-record-gcc-switches -fno-common"
$

I guess is it a problem with go_bootstrap itself or with toolchain3?

It's something wrong with go_bootstrap. 👍
$ cat foo.go
package main

func main() {
        println("Greetings, program!")
}
$ ./pkg/tool/darwin_amd64/go_bootstrap build foo.go
# runtime/internal/sys
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# internal/cpu
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# runtime/internal/atomic
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
$

Alright so then is the problem something with go_bootstrap when it is running? Or when it is itself being built?

Using fe82e88, btw.

Alright, soooo step 4 of bootstrapping completes, right? Because we have a go_bootstrap. The failure shows up in step 5 when we try to use go_bootstrap.

But why don't we fail building toolchain2?

How do I set this debug flag? With GODEBUG?
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/dist/build.go#L1186-L1189
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/dist/build.go#L1097

I think these are what I want to test?
/Users/whit537/workbench/go/src/github.com/golang/go/pkg/bootstrap/bin
total 30532
-rwxr-xr-x  1 whit537  wheel   4702496 Dec 26 16:06 asm*
-rwxr-xr-x  1 whit537  wheel   4668656 Dec 26 16:06 cgo*
-rwxr-xr-x  1 whit537  wheel  16152432 Dec 26 16:06 compile*
-rwxr-xr-x  1 whit537  wheel   5734400 Dec 26 16:06 link*
$

Building Go cmd/dist using /usr/local/Cellar/go/1.10.1/libexec.
Building Go toolchain1 using /usr/local/Cellar/go/1.10.1/libexec.

How is DWARF an empty map? It's not nil!

Do some archs indeed have empty DWARFReg? Did I see something about using other architectures when rebuilding?

Okay, this is potentially interesting. There are seven-ish architectures:

One—wasm—has no DWARFRegisters. ¯\_(ツ)_/¯
Some of them—arm, arm64 and amd ≈ x86 (mine)—populate DWARFRegisters right in the declaration.
The other three architectures—mips, ppc64, and s390x—declare DWARFRegisters as an empty map, and then populate it in an init function(!):

https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/internal/obj/mips/a.out.go#L207-L220
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/internal/obj/ppc64/a.out.go#L260-L279
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/internal/obj/s390x/a.out.go#L154-L176

But the name in the error message is amd64, not one of those other three. :-/

Alright so am I getting checkpoint executables now? Can I test those to see which one has the failing empty map?

$ ag '^[A-Z0-9]*DWARF' src/out.borked
35405:MIPSDWARFRegisters = map[int16]int16 literal ready? true
35814:ARMDWARFRegisters = map[int16]int16 literal ready? true
36560:ARM64DWARFRegisters = map[int16]int16 literal ready? true
37033:PPC64DWARFRegisters = map[int16]int16 literal ready? true
37542:S390XDWARFRegisters = map[int16]int16 literal ready? true
40331:AMD64DWARFRegisters = map[int16]int16 literal ready? true
40406:X86DWARFRegisters = map[int16]int16 literal ready? true

$ ag '^[A-Z0-9]*DWARF' src/out.working
35470:ARMDWARFRegisters = map[int16]int16 literal ready? true
35760:MIPSDWARFRegisters = map[int16]int16 literal ready? true
36496:ARM64DWARFRegisters = map[int16]int16 literal ready? true
37029:S390XDWARFRegisters = map[int16]int16 literal ready? true
37541:PPC64DWARFRegisters = map[int16]int16 literal ready? true
40318:AMD64DWARFRegisters = map[int16]int16 literal ready? true
40393:X86DWARFRegisters = map[int16]int16 literal ready? true
67133:ARMDWARFRegisters = map[int16]int16 literal ready? true
67423:MIPSDWARFRegisters = map[int16]int16 literal ready? true
68159:ARM64DWARFRegisters = map[int16]int16 literal ready? true
68692:S390XDWARFRegisters = map[int16]int16 literal ready? true
69153:PPC64DWARFRegisters = map[int16]int16 literal ready? true
71930:AMD64DWARFRegisters = map[int16]int16 literal ready? true
72005:X86DWARFRegisters = map[int16]int16 literal ready? true

I guess that's expected, the second batch is from the toolchain3 build.

Okay, I need to understand whether there are multiple go_bootstraps being created, and if so which one it is that's failing. Then I need to understand whether that's a runtime failure (doubt?) or a compile-time failure. If a compile-time failure then I need to go back one step in the bootstrapping process to understand why the compilation of go_bootstrap is seeing an empty DWARF map ... oooohh ... maybe it's a flag flipped off? No the flag is on ... but there is a flag, don't forget.

More code gen:
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/dist/buildruntime.go#L14-L100

Alright, I've found were go_bootstrap is (first?) built, and I am bailing out right afterwards in d69f671. Then I am testing a small build with it:
$ ./pkg/tool/darwin_amd64/go_bootstrap build foo.go
[...]
$ ./foo
Greetings, program!
$ cat foo.go

package main

func main() {
	println("Greetings, program!")
}

So far so good. 👍
Aaaaand, the same process with return out instead of return lout fails to build ... with an infinite loop!?!?!?!? 🙈
$ ./pkg/tool/darwin_amd64/go_bootstrap build foo.go > build-foo.out 2>&1
^C
$

Okay wow. Not infinite ... and it seems to work! 😳
I wanted it to fail on DWARF for a more minimal test case.

/me rm -rf pkg/ and try again ...

May as well use the spec example as foo.go here ...

Yeah, this sucker works. I guess that's cool? :D

So let's move forward until we see go_bootstrap fail ... that's when using toolchain2 to build toolchain3, right?

Right so the problem is going to be not with go_bootstrap but with one of the tools:
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/dist/build.go#L1165
That explains why we can build toolchain2 just fine, because toolchain1 is the toolchain from urgo.

With fc124ea: 👍
$ ./foo
panic: b is 5 not 4

goroutine 1 [running]:
main.expect(...)
        /Users/whit537/workbench/go/src/github.com/golang/go/foo.go:19
main.main()
        /Users/whit537/workbench/go/src/github.com/golang/go/foo.go:24 +0x267
$

Rebuilding go_bootstrap + toolchain2 with return out. I expect that build to succeed, and building foo.go using that build to fail with an empty DWARF map ...

Blam! Okay! Pick up there next time ...
$ ./pkg/tool/darwin_amd64/go_bootstrap build foo.go
# runtime/internal/sys
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# errors
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# unicode/utf8
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# math/bits
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# internal/race
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# internal/cpu
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# unicode
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# runtime/internal/atomic
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# sync/atomic
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
$

It's something outside of the pkg/tool directory. I've built and captured pkg-working and pkg-borked, and if I use go_bootstrap from one but have the other linked to pkg, then I get the behavior of the linked pkg, not the go_bootstrap.
$ ls -FGl | grep pkg
lrwxr-xr-x    1 whit537  wheel       11 Dec 27 07:25 pkg@ -> pkg-working
drwxr-xr-x    7 whit537  wheel      224 Dec 27 07:16 pkg-borked/
drwxr-xr-x    7 whit537  wheel      224 Dec 27 07:20 pkg-working/
$ rm foo && ./pkg-borked/tool/darwin_amd64/go_bootstrap build foo.go
[...]
$ ./foo
panic: b is 5 not 4

goroutine 1 [running]:
main.expect(...)
        /Volumes/workbench/go/src/github.com/golang/go/foo.go:19
main.main()
        /Volumes/workbench/go/src/github.com/golang/go/foo.go:24 +0x267
$ rm pkg && ln -s pkg-borked pkg
$ ls -FGl | grep pkg
lrwxr-xr-x    1 whit537  wheel       10 Dec 27 07:33 pkg@ -> pkg-borked
drwxr-xr-x    7 whit537  wheel      224 Dec 27 07:16 pkg-borked/
drwxr-xr-x    7 whit537  wheel      224 Dec 27 07:33 pkg-working/
$ rm foo && ./pkg-borked/tool/darwin_amd64/go_bootstrap build foo.go
# runtime/internal/sys
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# errors
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# math/bits
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# unicode/utf8
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# internal/race
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# internal/cpu
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# sync/atomic
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# unicode
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
# runtime/internal/atomic
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
$

🤔
diff -rub pkg-borked/bootstrap/src/bootstrap/cmd/compile/internal/gc/sinit.go pkg-working/bootstrap/src/bootst
--- pkg-borked/bootstrap/src/bootstrap/cmd/compile/internal/gc/sinit.go 2018-12-27 07:16:29.000000000 -0500
+++ pkg-working/bootstrap/src/bootstrap/cmd/compile/internal/gc/sinit.go        2018-12-27 07:20:21.000000000
@@ -571,7 +571,7 @@
        logarr("  out", out)
        logarr(" lout", lout)

-       return out
+       return lout
 }

 // compilation of top-level (static) assignments

Nevermind, that's the only discrepancy in src. The architecture files are all the same I guess.
Back to diffing in practice:
/Volumes/workbench/go/src/github.com/golang/go/pkg
$ ln -s ../pkg-working/
bootstrap/    darwin_amd64/ include/      obj/          tool/
$ ln -s ../pkg-working/bootstrap
$ ln -s ../pkg-working/darwin_amd64
$ ln -s ../pkg-working/include
$ ln -s ../pkg-working/obj
$ ln -s ../pkg-working/tool
$

Sike! Only tool matters:
$ ls -FGl pkg
total 0
lrwxr-xr-x  1 whit537  wheel  19 Dec 27 07:39 tool@ -> ../pkg-working/tool
$ rm foo && ./pkg/tool/darwin_amd64/go_bootstrap build foo.go > /dev/null 2>&1 && ./foo
panic: b is 5 not 4

goroutine 1 [running]:
main.expect(...)
        /Volumes/workbench/go/src/github.com/golang/go/foo.go:19
main.main()
        /Volumes/workbench/go/src/github.com/golang/go/foo.go:24 +0x267
$

Right, sorry. It's the specific tools in tool that matter.

Huh. Linking asm, compile, link, and go_bootstrap from pkg-working results in something I can use:
/Users/whit537/workbench/go/src/github.com/golang/go/pkg/tool/darwin_amd64
total 0
lrwxr-xr-x  1 whit537  wheel  42 Dec 27 07:47 asm@ -> ../../../pkg-working/tool/darwin_amd64/asm
lrwxr-xr-x  1 whit537  wheel  46 Dec 27 07:45 compile@ -> ../../../pkg-working/tool/darwin_amd64/compile
lrwxr-xr-x  1 whit537  wheel  51 Dec 27 07:44 go_bootstrap@ -> ../../../pkg-working/tool/darwin_amd64/go_bootstrap
lrwxr-xr-x  1 whit537  wheel  43 Dec 27 07:45 link@ -> ../../../pkg-working/tool/darwin_amd64/link
$

$ rm -f foo && ./pkg/tool/darwin_amd64/go_bootstrap build foo.go > /dev/null 2>&1 && ./foo
panic: b is 5 not 4

goroutine 1 [running]:
main.expect(...)
        /Volumes/workbench/go/src/github.com/golang/go/foo.go:19
main.main()
        /Volumes/workbench/go/src/github.com/golang/go/foo.go:24 +0x267
$

And if I link link from borked then go_bootstrap still builds foo:
/Users/whit537/workbench/go/src/github.com/golang/go/pkg/tool/darwin_amd64
total 0
lrwxr-xr-x  1 whit537  wheel  42 Dec 27 07:47 asm@ -> ../../../pkg-working/tool/darwin_amd64/asm
lrwxr-xr-x  1 whit537  wheel  46 Dec 27 07:45 compile@ -> ../../../pkg-working/tool/darwin_amd64/compile
lrwxr-xr-x  1 whit537  wheel  51 Dec 27 07:44 go_bootstrap@ -> ../../../pkg-working/tool/darwin_amd64/go_bootstrap
lrwxr-xr-x  1 whit537  wheel  42 Dec 27 07:50 link@ -> ../../../pkg-borked/tool/darwin_amd64/link
$

But if I link asm from borked then I get an error that it can't find the include directory. 🤔
/Users/whit537/workbench/go/src/github.com/golang/go/pkg/tool/darwin_amd64
total 0
lrwxr-xr-x  1 whit537  wheel  41 Dec 27 07:51 asm@ -> ../../../pkg-borked/tool/darwin_amd64/asm
lrwxr-xr-x  1 whit537  wheel  46 Dec 27 07:45 compile@ -> ../../../pkg-working/tool/darwin_amd64/compile
lrwxr-xr-x  1 whit537  wheel  51 Dec 27 07:44 go_bootstrap@ -> ../../../pkg-working/tool/darwin_amd64/go_bootstrap
lrwxr-xr-x  1 whit537  wheel  43 Dec 27 07:51 link@ -> ../../../pkg-working/tool/darwin_amd64/link
$

$ $ rm -f foo && ./pkg/tool/darwin_amd64/go_bootstrap build foo.go
[...]
final: reordered!
  out:
        FoldScript = map[string]*RangeTable literal
        FoldCategory = map[string]*RangeTable literal
        Properties = map[string]*RangeTable literal
        Scripts = map[string]*RangeTable literal
        Categories = map[string]*RangeTable literal
 lout:
        Categories = map[string]*RangeTable literal
        Scripts = map[string]*RangeTable literal
        Properties = map[string]*RangeTable literal
        FoldCategory = map[string]*RangeTable literal
        FoldScript = map[string]*RangeTable literal
# runtime/internal/atomic
/Users/whit537/workbench/go/src/github.com/golang/go/src/runtime/internal/atomic/asm_amd64.s:9: #include: open /Users/whit537/workbench/go/src/github.com/golang/go/pkg/include/textflag.h: no such file or directory
# internal/cpu
/Users/whit537/workbench/go/src/github.com/golang/go/src/internal/cpu/cpu_x86.s:8: #include: open /Users/whit537/workbench/go/src/github.com/golang/go/pkg/include/textflag.h: no such file or directory
# sync/atomic
/Users/whit537/workbench/go/src/github.com/golang/go/src/sync/atomic/asm.s:8: #include: open /Users/whit537/workbench/go/src/github.com/golang/go/pkg/include/textflag.h: no such file or directory
$

Same if link is from borked, too. 🤔
/Users/whit537/workbench/go/src/github.com/golang/go/pkg/tool/darwin_amd64
total 0
lrwxr-xr-x  1 whit537  wheel  41 Dec 27 07:51 asm@ -> ../../../pkg-borked/tool/darwin_amd64/asm
lrwxr-xr-x  1 whit537  wheel  46 Dec 27 07:45 compile@ -> ../../../pkg-working/tool/darwin_amd64/compile
lrwxr-xr-x  1 whit537  wheel  51 Dec 27 07:44 go_bootstrap@ -> ../../../pkg-working/tool/darwin_amd64/go_bootstrap
lrwxr-xr-x  1 whit537  wheel  42 Dec 27 07:56 link@ -> ../../../pkg-borked/tool/darwin_amd64/link
$

Right. I guess I can't assemble using borked asm things emitted by working compiler.
https://courses.cs.washington.edu/courses/cse378/97au/help/compilation.html
# runtime/internal/atomic
asm: asmand: bad address
asm: asmand: bad address
asm: asmand: bad address
asm: assembly failed

Alright, so the compiler, assembler, and linker all go together. But I guess go_bootstrap is decoupled, and simply runs the other programs.

Alright! What next?

The Main that is failing is the compiler, right?

Alright, I'm down into src/cmd/go/internal/. What am I doing?

 I believe the error is under the compile calls.

Okay now this is interesting. I ran compile using apparently an intermediary step, and it is more successful!
$ ./pkg/tool/darwin_amd64/compile foo.go
dwarf: map[2097:46 2205:52 2212:63 2133:76 2107:125 2078:14 2089:38 2206:53 2129:72 2106:124 2120:29 2069:6 2088:37 2087:36 2209:55 2239:62 2072:8 2110:19 2118:27 2121:30 2123:32 2125:68 2126:69 2136:79 2100:118 2077:13 2108:17 2116:25 2090:39 2095:44 2122:31 2092:41 2104:122 2066:1 2071:5 2124:67 2127:70 2103:121 2094:43 2138:81 2139:82 2068:7 2075:11 2076:12 2079:15 2114:23 2102:120 2111:20 2117:26 2130:73 2067:3 2115:24 2096:45 2131:74 2086:35 2204:51 2132:75 2135:78 2109:18 2208:54 2137:80 2105:123 2070:4 2112:21 2093:42 2098:47 2207:50 2128:71 2101:119 2064:0 2073:9 2074:10 2084:33 2099:48 2134:77 2065:2 2113:22 2119:28 2085:34 2091:40]
foo.go:3:8: can't find import: "fmt"
$

The "final" compile is borked:
$ ./pkg/tool/darwin_amd64/compile foo.go
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
$

Fits with the toolchain1 / toolchain2 / toolchain3 setup.

Alright so what's going on with Ctxt.Arch between the working and borked cases?

Let's go back to how Arch is initialized ...

Are we getting the expected archInit?
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/compile/main.go#L45

working 1ab2fac
$ ./pkg/tool/darwin_amd64/compile foo.go
objabi.GOARCH: amd64
archInit: 0x18aa4c0
archInit: 0x18aa4c0
dwarf: map[2064:0 2065:2 2066:1 2067:3 2068:7 2069:6 2070:4 2071:5 2072:8 2073:9 2074:10 2075:11 2076:12 2077:13 2078:14 2079:15 2084:33 2085:34 2086:35 2087:36 2088:37 2089:38 2090:39 2091:40 2092:41 2093:42 2094:43 2095:44 2096:45 2097:46 2098:47 2099:48 2100:118 2101:119 2102:120 2103:121 2104:122 2105:123 2106:124 2107:125 2108:17 2109:18 2110:19 2111:20 2112:21 2113:22 2114:23 2115:24 2116:25 2117:26 2118:27 2119:28 2120:29 2121:30 2122:31 2123:32 2124:67 2125:68 2126:69 2127:70 2128:71 2129:72 2130:73 2131:74 2132:75 2133:76 2134:77 2135:78 2136:79 2137:80 2138:81 2139:82 2204:51 2205:52 2206:53 2207:50 2208:54 2209:55 2212:63 2239:62]
 lout:
	c = f()
	b = f()
	a = c + b
srted:
	a = c + b
	b = f()
	c = f()
	d = 3
dfnst:
	c = f()
	b = f()
	a = c + b
  fwd:
	d: []
	b: [f]
	a: [c, b]
	c: [f]
	f: [d]
  fwd:
	d: []
	b: [f]
	a: [b, c]
	c: [f]
	f: [d]
prune: to map[a = c + b:{} b = f():{} c = f():{}]
removing d from fwd[f]
removing f from bck[d]
removing f from fwd[b]
removing b from bck[f]
removing f from fwd[c]
removing c from bck[f]
prune: done
  fwd:
	a: [c, b]
	c: []
	f: []
	d: []
	b: []
srted:
	a = c + b
	b = f()
	c = f()
	d = 3
 defnset:
	c = f()
	b = f()
	a = c + b
  fwd:
	a: [c, b]
	c: []
	f: []
	d: []
	b: []
  out:
a = c + b ready? false
b = f() ready? true
removing b = f()
removing b from fwd[a]
removing a from bck[b]
c = f() ready? true
removing c = f()
removing c from fwd[a]
removing a from bck[c]
srted:
	a = c + b
 defnset:
	a = c + b
  fwd:
	a: []
	c: []
	f: []
	d: []
	b: []
  out:
	b = f()
	c = f()
a = c + b ready? true
removing a = c + b
srted:
dfnst:
  fwd:
	a: []
	c: []
	f: []
	d: []
	b: []
final: reordered!
  out:
	b = f()
	c = f()
	a = c + b
 lout:
	c = f()
	b = f()
	a = c + b

And with return out:
$ ./pkg/tool/darwin_amd64/compile foo.go
objabi.GOARCH: amd64
archInit: 0x18aa590
archInit: 0x18aa590
dwarf: map[]
compile: location lists requested but register mapping not available on amd64
$

Alright, so we know that the bug is due to something about the reordering that we're doing. What's going on?

The a.out.go in pkg has AMD64DWARFRegisters defined as expected.

DWARFRegisters is an empty map because it's declared thus:
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/internal/obj/link.go#L667-L676
Soooo ... the default value is what we're seeing, we're not seeing the result of ... setting DWARFRegisters, which happens in ... obj6, ya?
https://github.com/chadwhitacre/go/blob/048c9164a0c5572df18325e377473e7893dbfb07/src/cmd/internal/obj/x86/obj6.go#L1276-L1284
Wasn't that not showing up earlier? Yes. 🤔

Actually I think that's a lie.

(Regarding the default value.)

Okay maybe it's not a lie:
https://play.golang.org/p/NJrROy3SkSk
package main

import (
	"fmt"
)

type LinkArch struct {
	DWARFRegisters map[int16]int16
}

func main() {
	var arch = new(LinkArch)
	println(fmt.Sprintf("%v", arch.DWARFRegisters))
}

Outputs:
map[]

Alright, so we have something like this:
https://play.golang.org/p/XDuMFzoSM2m
package main

import (
	"fmt"
)

var AMD64DWARFRegisters = map[int16]int16{
	0: 42,
}

type LinkArch struct {
	DWARFRegisters map[int16]int16
}

func main() {
	var arch = LinkArch{
		DWARFRegisters: AMD64DWARFRegisters,
	}
	println(fmt.Sprintf("%v", arch.DWARFRegisters))
}

map[0:42]

Except there is package traversal in there. And it breaks.

71fbcb8 ☺
$ ./foo
$

71fbcb8 ☺
$ ./foo
$

Okay! So why does that work? 🤔
Tune in next time! 😬

Test passing in 81daac1. 👍
/Volumes/workbench/go/src/github.com/golang/go
total 1384
-rw-r--r--    1 whit537  wheel    55297 Nov 25 08:12 AUTHORS
-rw-r--r--    1 whit537  wheel     1339 Nov 25 08:12 CONTRIBUTING.md
-rw-r--r--    1 whit537  wheel    71104 Nov 25 08:12 CONTRIBUTORS
-rw-r--r--    1 whit537  wheel     1479 Nov 25 08:10 LICENSE
-rw-r--r--    1 whit537  wheel     1303 Nov 25 08:10 PATENTS
-rw-r--r--    1 whit537  wheel     1607 Nov 25 08:12 README.md
-rw-r--r--    1 whit537  wheel       45 Dec 27 12:02 VERSION.cache
drwxr-xr-x   17 whit537  wheel      544 Nov 25 08:12 api/
drwxr-xr-x    4 whit537  wheel      128 Dec 27 12:07 bin/
drwxr-xr-x   49 whit537  wheel     1568 Nov 25 08:12 doc/
-rw-r--r--    1 whit537  wheel     5686 Nov 25 08:10 favicon.ico
drwxr-xr-x    3 whit537  wheel       96 Nov 25 08:10 lib/
drwxr-xr-x   16 whit537  wheel      512 Nov 25 08:12 misc/
drwxr-xr-x    7 whit537  wheel      224 Dec 27 12:02 pkg/
-rw-r--r--    1 whit537  wheel       26 Nov 25 08:10 robots.txt
drwxr-xr-x   69 whit537  wheel     2208 Dec 27 12:08 src/
-rw-r--r--    1 whit537  wheel  1249708 Dec 27 12:07 tags
drwxr-xr-x  306 whit537  wheel     9792 Nov 25 08:12 test/
$ which go
./bin/go
$ go run test/run.go -- test/fixedbugs/issue22326.go
$

68db6f2865e8bb8c8e4183d0f4393ec99b5f53fb
$ time (./make.bash -v > out 2>&1 && ../bin/go run ../test/run.go -- ../test/fixedbugs/issue22326.go >> out 2>&1); echo 'final: done!' >> out && say 'yeah'

real    5m13.443s
user    9m4.120s
sys     1m17.023s
$

Significant slowdown relative to 048c916:
$ time (./make.bash -v > out 2>&1 && ../bin/go run ../test/run.go -- ../test/fixedbugs/issue22326.go >> out 2>&1); echo 'final: done!' >> out && say 'yeah'

real    3m40.285s
user    7m41.508s
sys     1m14.226s
$

Squashed! Getting ready to contribute!

Rebased on latest master (af43203).
$ time (./make.bash -v > out 2>&1 && ../bin/go run ../test/run.go -- ../test/fixedbugs/issue22326.go >> out 2>&1); echo 'final: done!' >> out && say 'yeah'

real    5m37.722s
user    10m2.047s
sys     1m18.599s
$

Alright, I'm going to give this a once-over before submitting. Not planning to address any of the big issues in the issue description (out of time! :( ) but just basic reorganization and gofmting ...

Baseline. 👍
$ time (./all.bash -v > out 2>&1); say 'yeah'
real    26m59.555s
user    51m9.112s
sys     20m42.971s
$

Okay! I have a commit! e041f1e
Now, how do I get that into Gerrit? 🤔

I mean, besides letting Gopherbot do it for me. 😆

I've figured out how to convince git codereview change to do something good. Now rerunning the test suite ...

$ time (./all.bash -v > out 2>&1); say 'yeah'

real    16m26.151s
user    30m46.513s
sys     8m16.435s
$

$ tail out
ok      cmd/vendor/github.com/google/pprof/profile      0.165s
ok      cmd/vendor/github.com/ianlancetaylor/demangle   0.051s
ok      cmd/vendor/golang.org/x/arch/arm/armasm 0.039s
ok      cmd/vendor/golang.org/x/arch/arm64/arm64asm     0.334s
ok      cmd/vendor/golang.org/x/arch/ppc64/ppc64asm     0.027s
ok      cmd/vendor/golang.org/x/arch/x86/x86asm 0.179s
ok      cmd/vendor/golang.org/x/crypto/ssh/terminal     0.020s
ok      cmd/vendor/golang.org/x/sys/unix        3.573s
ok      cmd/vet 20.944s
2019/01/03 18:47:00 Failed: exit status 2
$

🤔

Okay the test suite is totally hosed. 😞

💃
$ git codereview mail
remote: Processing changes: refs: 1, new: 1, done
remote:
remote: SUCCESS
remote:
remote: New Changes:
remote:   https://go-review.googlesource.com/c/go/+/156328 cmd/compile: initialize variables in the right order
$

Moving to https://go-review.googlesource.com/c/go/+/156328/! 😍

https://twitter.com/chadwhitacre_/status/1081343832158076935


[IMPROVEMENT]: Try to improve Docker SO with Alpine

Improvement 🔧
Alpine Linux is much smaller than most distribution base images (~5MB), and thus leads to much slimmer images in general.
Maybe Energyplus or other dependencies don't run correctly in this SO, but it is worth to create a branch and test to see if we can change the image based on Ubuntu 22.04 LTS
Checklist

[x] I have checked that there is no similar issue in the repo (required)
[x] I have read the documentation (required)

:pencil: Please, don't forget to include more labels besides enhancement if it is necessary.

I am trying with an image called python:3.10.11-alpine. Unfortunately, it seems that Alpine has problems with some python modules which depend on C  extensions (such as numpy or torch). I will try to do with other light SO's based on Ubuntu or Debian

As is mentioned in v2.4.1, we have several problems with Alpine or slim Debian OS with python v3.10.11.  So this proposal is dismissed for now. This issue will be closed with this message temporally.
Alpine has several problems with modules which depend on C extensions, such as numpy and torch. Debian bullseye slim image has problems with python 3.10.11 (we have currently 3.10.6) with cchardet module. cchardet is not an explicit dependency of Sinergym, but it is a dependency of pytype and opyplus.
There are already libraries that try to fill the gap left by the abandonment of the cchardet project. The one that I have seen more updated and handy is charset_normalizer. The problem is that since it is a dependency of our dependencies, rather than a direct dependency, I can't replace it to fix it.


DIABOLIK LOVERS: LUNATIC PARADE [PCSG00826]

App summary

App name: DIABOLIK LOVERS: LUNATIC PARADE
App serial: PCSG00826
App version: 1.0

Vita3K summary

Version: v0.1.6
Build number: 3029
Commit hash: https://github.com/vita3k/vita3k/commit/#968
CPU backend:  Unicorn and Dynarmic.
GPU backend: OpenGL

Test environment summary

Tested by: spookyblackcats
OS: Windows 11
CPU: Intel
GPU: Intel
RAM: 16.0 GB

Issues
Game runs with noticeable graphical issues, including but not limited to:

character sprites appearing glitched and/or not at all
backgrounds appearing black
characters may appear fully or partially blue/discolored
sprite facial animations may appear alone
characters have the sprite of another character mixed with theirs

Screenshots
sprite shows only eyes + mouth

sprite discoloration

background not appearing + sprite discoloration

background not appearing + sprite errors + background not appearing

a character's sprite discolored + parts are replaced w/ another character's + background not appearing

Log
vita3k.txt
Recommended labels

graphics bug
playable

You can can look if surface sync is enable ?

You can can look if surface sync is enable ?

Surface sync was enabled--even when disabled, still the same. Not having any luck playing around with some other settings either.
I'm curious as to what causes this to happen, though. I'm not very knowledgeable on these things, haha.

Using original issue #452


Patching SoftwareVersions

In general patching software versions does work as described in the developer portal:
PATCH /v2/appinstallations/{appInstallationId} HTTP/1.1
Content-Type: application/json

{
  "systemSoftware": {
    "<insert system software id>": {
      "systemSoftwareVersion": "<insert system software version id>",
      "updatePolicy": "patchLevel"
    }
  }
}

However, in the client it is only possible to define the systemSoftwareVersion, but not systemSoftwareId:
/src/Generated/V2/Clients/App/PatchAppinstallation/PatchAppinstallationRequestBodySystemSoftwareItem.php
    private static array $schema = [
        'properties' => [
            'systemSoftwareVersion' => [
                'type' => 'string',
            ],
            'updatePolicy' => [
                '$ref' => '#/components/schemas/de.mittwald.v1.app.SystemSoftwareUpdatePolicy',
            ],
        ],
        'type' => 'object',
    ];

The schema for the request looks like this:
            'systemSoftware' => [
                'additionalProperties' => [
                    'properties' => [
                        'systemSoftwareVersion' => [
                            'type' => 'string',
                        ],
                        'updatePolicy' => [
                            '$ref' => '#/components/schemas/de.mittwald.v1.app.SystemSoftwareUpdatePolicy',
                        ],
                    ],
                    'type' => 'object',
                ],
                'type' => 'object',
            ],

Providing keys with the id to systemSoftware will lead to a JSON validation error.

It's meant to be used as a map, with the systemSoftwareId being used as a key. So, something like this:
$body = new PatchAppinstallationRequestBody();
$body->withSystemSoftware([
    '<uuid>' => (new PatchAppinstallationRequestBodySystemSoftwareItem())
        ->withSystemSoftwareVersion('<uuid>')
        ->withUpdatePolicy(SystemSoftwareUpdatePolicy::patchLevel)
]);

A working example usage may be found in mittwald/deployer-recipes:
https://github.com/mittwald/deployer-recipes/blob/7599e10a1e7d6fe8e51da17dfed0b9c6d9de6c17/src/Client/AppClient.php#L32-L47
Let me know if that helps!

Ah, thanks. Will try this tomorrow! :+1:

works 👍


Upgrade to axios v1+

There are breaking changes and changes in some of the internal code that was copy-pasted/extracted from axios. Will have to go over everything and update.

would you accept a PR with this upgrade?

Not that simple really. It's essentially rewriting this as Axios v1 changed quite throughly...

You can try #7


Update from 2.0.2 to 2.0.3 have non-documented breaking changes

Hello,
The update between version 2.0.2 and version 2.0.3 of your package contains a "breaking change" that has not been documented.
This creates issues if you still use the make() method.
Be careful with semver, it can cause a lot of problems later on.
I think it should at least be documented in the release :)
Your readme.md should be edited too

Ah shit, sorry about that!
Nova 3.1 added their own make() function to the Filter in Nova 3.1 which caused an exception. For some reason, I thought it's okay to remove it from LocaleFilter altogether. I re-added it again, with the Nova 3.1 signature so it doesn't crash.
Sorry about that! Wasn't an intentional breaking change, just a fix I didn't think through.
Fix released in 2.0.4. Good luck!

No problems. Thanks for your fix :)


spec.policy.resolution set to Optional is not honoured for label selectors

What happened?
It seems that spec.policy.resolution set to Optional only applies for EnvironmentConfigs who are selected directly by Reference but does not work for Selectors.
How can we reproduce it?
Create an input to a reference for an EnvironmentConfig that does not exist.
I had an input like this:
  - step: loadEnvironmentConfigs
    functionRef:
      name: function-environment-configs
    input:
      apiVersion: environmentconfigs.fn.crossplane.io/v1beta1
      kind: Input
      spec:
        policy:
          resolution: Optional
        environmentConfigs:
          - type: Selector
            selector:
              matchLabels:
              - key: foo
                type: FromCompositeFieldPath
                valueFromFieldPath: metadata.name

You see the following error in my XR.
   message: 'cannot compose resources: pipeline step "loadEnvironmentConfigs" returned
        a fatal result: cannot get selected environment configs: expected exactly
        one extra resource "environment-config-0", got 0'

I believe this is because the guard is only being applied in the reference case.  Happy to open a PR.
What environment did it happen in?
Function version: 0.0.4

This is because by reference we mean what in the list of selected EnvironmentConfigs previously saved at spec.environmentConfigRefs. So optional means: if it got referenced but is not there anymore, ignore it. But with selectors you have one step before, you have to select what gets in that list first and we decided to error out in the default mode (single) if more or less than one exact match is found, while multiple mode allows selecting the first k matches or erroring out if not enough matches are found.
I know it's convoluted 😅 we should definitely improve this API, but rn we focused on porting the exact upstream API.

Gotcha, thanks for the quick response. Setting this worked in my selector:
          mode: Multiple
          maxMatch: 1
          minMatch: 0


Preview does not open blok in the sidebar after clicking the element in de preview editor.

Hi there, i really hope i didn't overlooked something here. Im currently facing an issue since storyblok version 4.5 after the update for Nuxt 3 Stable. Does everyone else facing this issue?

If clicking on an element inside Storyblok Visual Editor the desired Blok does not open in the sidepanel. The console shows following error:
(anonymous) @ storyblok-v2-latest.js:1 handleOpenBlok @ storyblok-v2-latest.js:1 handleWindowClick @ storyblok-v2-latest.js:1 VM1789:1 Uncaught SyntaxError: "undefined" is not valid JSON     at JSON.parse (<anonymous>)     at storyblok-v2-latest.js:1:11649     at m.handleOpenBlok (storyblok-v2-latest.js:1:11659)     at m.handleWindowClick (storyblok-v2-latest.js:1:11405)
Otherwise, while opening a blok manually and changing the bloks content the visual editor updates his content. The Bug only affects the selecting / clicking on a blok.

Expected Behavior
Expect storyblok to open desired block at sidepanel.
Additional Information
Node: v16.18.0
Package.json:
"@storyblok/nuxt": "^4.6.0",
"nuxt": "^3.0.0",

Implementation:
const storyStore = useStoryStore();
await storyStore.fetchCurrentStory();
const data = ref(storyStore.getCurrentStory);

onMounted(() => {
    const runtimeConfig = useRuntimeConfig();
    const route = useRoute();

    // If version is draft, load the bridge to support storybloks preview
    const version = route.query._storyblok || runtimeConfig.NODE_ENV === 'development' ? 'draft' : 'published';

    if (version === 'draft') {
        useStoryblokBridge(data.value.story.id, (evStory) => {
            data.value.story = evStory;
        });
    }
});

Pinia Store for stories:
export default defineStore('StoryStore', {
    state: () => ({
        data: {},
    }),

    actions: {
        async fetchCurrentStory() {
            const storyblokApi = useStoryblokApi();

            // Get current story based on route path and version
            const route = useRoute();
            const runtimeConfig = useRuntimeConfig();
            const version = route.query._storyblok || runtimeConfig.NODE_ENV === 'development' ? 'draft' : 'published';
            const path = route.path === '/' ? '/home' : route.path;

            try {
                const { data } = await storyblokApi.get(`cdn/stories${path}`, {
                    version,
                });

                this.data = data;
            } catch (e) {
                throw createError({
                    statusCode: res.response.status,
                    message: res.response.status === 404
                        ? 'Diese Seite existiert leider nicht.' : res.response.data,
                });
            }
        },
    },

    getters: {
        getCurrentStory(state) {
            return state.data;
        },
    },
});

Nuxt Config
['@storyblok/nuxt', {
    accessToken: process.env.STORYBLOK_TOKEN,
    bridge: true,
    useApiClient: true,
}],

Is the reason behind not using useStoryblok() to be able to store the story outside of the page and in the pinia store?

I have the same issue on storyblok-nuxt-2

Last comment in this issue has the fix https://github.com/storyblok/storyblok-nuxt-2/issues/62
You are probably in "published" mode while editing the page. The bridge could probably throw a meaningful error in that case.

Since this is no longer an issue in the up-to-date projects, I'm closing the issue. If someone ever faces a problem with the Visual Preview you can always open a new issue with the version you are using currently! 🎉


Unify backend builders, adding allocate to server builders

Builds on #2239.

Introduces an internal BackendBuilder trait, which improves API cohesion through inheritance.
Puts the type parameter on the builder, not the resource/stream/allocate methods
Adds allocate to the servers, per popular request.  I still don't like it.
Doesn't yet apply to JettyClient or AsyncHttpClient, which aren't builders

I anticipate this might make @ChristopherDavenport slightly grumpy, so I'll hold off a little bit in case he wants to have an OOP fight.


ui-router v1.0.0-rc.1 - uiCanExit/OnBefore/OnStateChanged canceling removes the url history

Bug Report
Current Behavior:
When clicking the Back button in the browser and using the uiCanExit/OnBefore Transition event function and returning false or if i'm using the legacy state events (https://ui-router.github.io/ng1/docs/latest/modules/ng1_state_events.html)
It will keep me in the same page.
But in the next Back click (when returning true so the Transition can pass normally), it will go back 2 times.
For example:
If you go to the plunker below you can reproduce it by doing the following:

now you are the home state, go to the home.foo state.
go to the other state.
click the back browser button (you will see the cancellation event and you should stay in the same page).
click the back browser button again.
you will be redirected to the home state.

I also noticed that after the first back cancel the browser will remove the previous history url.
Expected Behavior:
It should go back to the home.foo state.
Link to Plunker that reproduces the issue:
http://plnkr.co/edit/i15fdSEL5q632qGxOE91?p=preview

thanks for the plunker.  I agree it would be ideal to detect the back button and choose {location: true} instead of { location: true }.


Linter fixes

One notable lint:
https://rust-lang.github.io/rust-clippy/master/index.html#init_numbered_fields
Which was why I made the AccountStep enum more consistent. I did that work as a separate commit because it's a bit more involved change.
There were a couple of other cases where I could've tried fixing the lint by adding named fields instead of a positional tuple struct to the enum member, which would fix the issue, but I became concerned it was indicative of an oversight in the strict encoding portion of the client side validation library. I've made an issue for that here:
https://github.com/LNP-BP/client_side_validation/issues/54

I explicitly pegged the toolchain in the rust-toolchain.toml to 1.59 in case folks forget to rustup update. It passes linter on stable, but I had to leave in the clippy allow for init_numbered_fields.

@dr-orlovsky I just noticed that some additional commits were pushed to the master branch. What's going on there? And should we go back to using nightly due to the try trait v2 feature?

I merged previous work on taproot support since we've got rust-bitcoin release candidate out. Now it will be finalized.
We should not regress to nightly since nightly with try_trait_v2 feature is required only for libbitcoin and not the rest of the code. That is why in CI they are build separately


jacdac-Accelerometer gesture in Makecode

Status of jacdac-Accelerometer in dashboard，values are correct

When I write a program in makecode and download it，I found out that the gesture state is exactly reversed
tilt up should be swapped with tilt down
tilt left should be swapped with tilt right
face up should be swapped with face down
https://makecode.microbit.org/_Ahi9Fe8WV8T4

very related to this, also when using the Accelerometer Jacdac module: The cube in the live view behaves not as expected.

When I tilt the accelerometer to the right, the cube tilts to the left and vice versa
When I tilt the accelerometer to the front, the cube tilts to the front and vice versa
So the behavior is not consistent, it would be consistent if either of the two is flipped. Also I observe, that the cube often spins multiple times with only small movements of the accelerometer.
Still enjoying Jacdac a lot!


Rename variable from 'vm' to virtual_machine'

Tests failed on Jenkins due to an undefined variable.

Ping @miguelaferreira @remibergsma @borisroman @bheuvel
Apologies, guys! All the internal LB tests failed due to:
Failed to ssh into vm: 123b869c-4709-4e03-9750-3c246a663fe8 due to global name 'vm' is not defined

Could you please merge this once the build is done?
Cheers,
Wilder


PowerShell WebJob that throws exception marked "Success"

If I create a powershell script run.ps1:
$ErrorActionPreference = 'Stop'
throw 'error!'

And run it from the command line the same way I think the webjob framework runs it, it returns a non-zero result code:
C:\ > powershell.exe -ExecutionPolicy RemoteSigned -File run.ps1
error!
At C:\run.ps1:2
char:1
+ throw 'error!'
+ ~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (error!:String) [], RuntimeException
    + FullyQualifiedErrorId : error!
c:\ > echo %ERRORLEVEL%
1

However, when uploaded as a triggered webjob, the job is marked as successful.  It should fail, right?

I would also expect that a non-zero exit code would be a failure, OR otherwise what would be the "correct" way to mark a job as failed from within a PowerShell script?

@christianrondeau when you run the script from a command prompt the exit code is 1 (see original post).

So, a script failure is considered a webjob success? How can I make the webjob report a failure then?!

Interesting. From Kudu Console, try running it directly (the exact script above):
D:\home\site\wwwroot\app_data\jobs\triggered\Bar>powershell -ExecutionPolicy RemoteSigned -file ./run.ps1
error!
At D:\home\site\wwwroot\app_data\jobs\triggered\Bar\run.ps1:2 char:1
+ throw 'error!'
+ ~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (error!:String) [], RuntimeExc
   eption
    + FullyQualifiedErrorId : error!

D:\home\site\wwwroot\app_data\jobs\triggered\Bar>echo %errorlevel%
0

Note how the errorlevel is 0, indicating success, even though it failed! That's why Kudu thinks it worked.
Not sure why it behaves that way.

Looks like you're right. I thought I checked this before, looks like I was wrong.
try {
	throw 'oops'
} catch {
	echo $_.Exception | format-list -force
	exit 1
}

or the old-school trap:
trap {
	echo $_.Exception | format-list -force
	exit 1
}

throw 'oops'

When I run powershell -file .\oops.ps1; echo Code: $LASTEXITCODE I can see the code is 1, so I guess this'll work. It's a shame we have to wrap every script in something like this just for Kudu to fail... Though I agree it's really PowerShell's fault, that's not something I noticed before dealing with in Kudu :(

You should test in Kudu console. I wonder if there may be sandbox issues that somehow affect the return code.

Yes, try/catch and trap work if you put an exit 1 in the catch/trap when run through the Kudu console or a web job, but I really wish you didn't have to do that because it is not intuitive.

Well looks like using trap works fine, and fails the webjob. I don't know where this could be documented to help other people in the future, but at least my own issue is "solved" :) Now we just need to remember to add this everywhere.

Hi
If the problem persists and is related to running it on Azure App Service, please open a support incident in Azure:
https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request
This way we can better track and assist you on this case
Thanks,
Joaquin Vano
Azure App Service


chore: add generation file to npm_translate_lock and npm_import

Looks like the fix for #1412 release in v1.39.1 requires the npm_import repository rules to re-run with the fix in-place but just upgrading to rules_js 1.39.1 doesn't invalidate the npm_import repository rules.
This PR adds a generated _generation file to npm_import and npm_translate_lock so that on upgrade we can guarantee that these repository rules are re-run to pick up the fix. After this lands I'll cut a 1.39.2.

Type of change

Bug fix (change which fixes an issue)

Test plan

Covered by existing test cases

Do you think this is worth it? If the issue requiring the cache bust is rare enough maybe users can just do a clean themselves?


enable l3ha on 3 node ci envs.

Enables l3ha on example envs with 3 node deployments.

ok to test

ok to test

ok to test

retest

ok to test

retest

@nirajdp76 This is failing to reach the floating ip because it doesn't know where the master router is. I will discuss with you on the alternative fixes, as there are multiple.

retest

closing this PR as is being replaces by https://github.com/blueboxgroup/ursula/pull/2605


add some project cleanup functions

We need to implement the individual project cleanup functions in the services we support
Best way to test in CLI mode is with https://review.opendev.org/#/c/734485/ (install OSC from this change, install OTCE from this branch and trigger project cleanup)

let's please merge it ASAP and then extend in future PRs


Implement autosquash for homebrew-core pull requests

The motivation for the feature
Contributors are often confused by maintainer requests to reword, squash, or rebase their commits, as it's possible in the GitHub UI to do all of these things while merging a pull request, but our workflow does not permit core maintainers to use the GitHub UI for this purpose.
If the contributor doesn't know how to squash and rebase, the maintainer will have to run brew pr-pull locally and do the rebase themselves. This takes up valuable maintainer time, as they not only have to muck around with modifying Git history, in the case of large bottles, they will have to use their personal Internet connection to upload to Bintray rather than relying on the direct transfer from GitHub Actions.
If the contributor does know how to squash and rebase, the force-push back to the pull request branch will run our continuous integration again, taking up valuable time on our runners that could have been saved.
Finally, maintainers may sometimes accidentally merge pull requests that do not conform to our commit message guidelines. This makes it harder to understand git history.
A detailed description of the proposed feature

BrewTestBot should be able to identify pull requests where the commits do not follow our commit message standards. This would take the form of an additional GitHub Actions check, perhaps as a new brew test-bot option, which flags that the pull request contains commits not following style guidelines.
All other formula changes look like foo: ...

BrewTestBot should, when merging formulae, be able to automatically squash and rebase the commits to conform to our style. This could start off as relatively simple cases, such as pull requests that change only a single formula, and gradually evolve to more complex cases with e.g. multiple version changes and revision bumps.

How the feature would be relevant to at least 90% of Homebrew users
Saving maintainer time means more time for maintainers to work on other things. Saving contributor time and preventing confusion means it's easier for the Homebrew community to start and continue contributing to Homebrew, ensuring the long-term health of the project.
What alternatives to the feature have been considered
Maintainers continue to use brew pr-pull to squash and rebase commits themselves, or ask contributors to squash and force push their pull requests.
cc @Homebrew/core for their input on how this could affect or improve their workflow.

BrewTestBot should be able to identify pull requests where the commits do not follow our commit message standards. This would take the form of an additional GitHub Actions check

If I understand you correctly, this feature is being designed with the not-so-rebase-savvy contributor in mind. What concrete action would we expect the contributor to take when they see the failed check?

BrewTestBot should, when merging formulae, be able to automatically squash and rebase the commits to conform to our style.

Just for clarification: the commits would be cleaned up when the maintainer presses Merge, i. e. at the last possible moment before the changes get pushed to master, right?
What happens if the commits can’t be cleaned up automatically? How would maintainers be able to tell before pressing Merge?

BrewTestBot should be able to identify pull requests where the commits do not follow our commit message standards. This would take the form of an additional GitHub Actions check

If I understand you correctly, this feature is being designed with the not-so-rebase-savvy contributor in mind. What concrete action would we expect the contributor to take when they see the failed check?

f a contributor doesn't know how to rebase their pull request, there's little we can do except to have BrewTestBot do an autosquash, which is the goal of this feature. If BrewTestBot doesn't know how to do the autosquash, the maintainer would have to do so. Either way, maintainers need to know whether a pull request could be autosquashed when BrewTestBot performs the merge, or if they will need to take manual action via brew pr-pull or similar.

BrewTestBot should, when merging formulae, be able to automatically squash and rebase the commits to conform to our style.

Just for clarification: the commits would be cleaned up when the maintainer presses Merge, i. e. at the last possible moment before the changes get pushed to master, right?

Merging is disabled on homebrew-core, and squash-merges only apply for changes that don't need bottles. The commits would get cleaned up by BrewTestBot before it pushes to homebrew-core.

What happens if the commits can’t be cleaned up automatically? How would maintainers be able to tell before pressing Merge?

The GitHub Actions check would tell them.

@jonchang Oh now I see. Thanks for elaborating!
In that case, I’d suggest that we map the following conclusions in order to be in line with user expectations:

Failure (red ❌) for when commits aren’t compliant and the action finds out it can’t clean them up;

Success (green ✅) for when commits are compliant as they are.

Success (green ✅) for when commits aren’t compliant but the action has figured out it can clean them up automatically. If Github supports it, it would be nice if the check result would also hint on the fact that something’s not quite perfect right there on the main pull request view:

Commit messages will be fixed automatically on merge.

I think it's good to have some sort of warning that commits were formatting incorrectly, even if they can be automatically fixed. This could be a message in the CI window (if there's a way to have an e.g. "commit format" check that can be in a failed state without blocking completion of the PR), automated comment on the PR, label etc...
We still want people to be in the habit of formatting their commits correctly. Otherwise, it will be even more painful when maintainers need to do some manual work and more confusing for contributors who are trying to understand why the commit history on master doesn't match what they did.

I think it's good to have some sort of warning that commits were formatting incorrectly, even if they can be automatically fixed. This could be a message in the CI window (if there's a way to have an e.g. "commit format" check that can be in a failed state without blocking completion of the PR), automated comment on the PR, label etc...

If the commit style violation is going to be fixed automatically, then a failure state may confuse both maintainers and contributors.
A failure state confuses contributors: upon seeing the failure, they will be in the same place as today when a maintainer asks them to reword, squash or rebase.
A failure state also confuses maintainers: even if they happen to know and remember that it’s not a critical failure, it may dilute other failures, which abound even today, including false positives from CI.
I think a failure state is also going to pile even more cognitive baggage onto an already complex decision tree that is merging a homebrew-core PR.

We still want people to be in the habit of formatting their commits correctly.

Even if a contributor is 100 % in that habit, violations may occur for reasons outside their control (e. g. applying review suggestions, maintainer commits) or by accident.
Either way, assuming they have no Git history rewriting skills, they find themselves trapped in the failed state without undo, which I feel is poor UX.

Otherwise, it will be even more painful when maintainers need to do some manual work

Can you elaborate about the manual work? I’m failing to imagine an example here.

and more confusing for contributors who are trying to understand why the commit history on master doesn't match what they did.

That’s a good reason for stating this in the check result, visible right from the pull request tab. But please in green.

Yes, after thinking about this more I think you're right.

A failure state confuses contributors: upon seeing the failure, they will be in the same place as today when a maintainer asks them to reword, squash or rebase.
A failure state also confuses maintainers: even if they happen to know and remember that it’s not a critical failure, it may dilute other failures, which abound even today, including false positives from CI.
I think a failure state is also going to pile even more cognitive baggage onto an already complex decision tree that is merging a homebrew-core PR.

Good point. I was assuming maintainers would be aware and could ignore the issue, but that doesn't really make sense. If the intention is to show an error that will only confuse people and be ignored by maintainers, there really isn't a point in showing the error at all.

Can you elaborate about the manual work? I’m failing to imagine an example here.

I was thinking about instances where a maintainer would need to adjust e.g. the commit structure or message of the PR (using pr-pull) but I forgot that this becomes irrelevant if this is implemented. I wasn't thinking hard enough about what I was typing... 😳

That’s a good reason for stating this in the check result, visible right from the pull request tab. But please in green.

100% agree. There are other ways to address the issue of contributers being confused by our merge process (e.g. add a link to the docs that explain our process to the comment that BrewTestBot adds to closed PRs)

Let me rephrase my concern as a question: If auto squashing is enabled and works most of the time, is there a point to requesting commits in the current style? I'd argue yes, but I don't think I have a concrete reason why. I think the best argument is that it's easier to follow if you're comparing commit history to PRs, but maybe this isn't an issue. If so, we can come up with the best way to display that information is an automated way that's clear to the contributor, but also is not a failed state that would confuse anyone.

Let me rephrase my concern as a question: If auto squashing is enabled and works most of the time, is there a point to requesting commits in the current style?

Good question.
Requesting it feels right to me but I can’t figure out why either 🤔

I wonder if it would be interesting that we add bottle commit into the PR and merge as it is.
NOTE, lots of image compression actions can do in that way.

If I recall correctly, pushing someone else's branch requires non-standard GitHub token and when using this token, workflows are triggered again. Might workaround it by skipping workflow jobs if GitHub actor == BrewTestBot tho, but it feels more hacky than it is right now.

Yeah, so if we can figure out the checks to detect where we can auto-squash, you can imagine a feature where BrewTestBot (for single formula changes) pushes up the bottle commit then does a squash and merge. Contributors will finally be able to see purple pull requests.
We've tended to avoid workflows that modify contributor branches because it can be confusing, but if it happens right before a merge it's probably not going to be a big problem.

If I recall correctly, pushing someone else's branch requires non-standard GitHub token and when using this token, workflows are triggered again.

Would that mean the decision whether or not to trigger a workflow depends on the push method (tokens vs. SSH)?
I regularly use SSH to push my changes to other people’s feature branches. Like so:
git push git@github.com:other_user/homebrew-core @:other_users_branch

I just tested and it triggered the checks anyway.

No, Dawid is referring to the default GITHUB_TOKEN that is automatically provisioned for all Actions workflows and is attributed to github[bot]. Pushes using this token do not trigger additional workflow runs. Compare to our personal access token HOMEBREW_GITHUB_API_TOKEN that gets attributed to BrewTestBot, and pushes with this token do trigger additional workflow runs.

No matter which push method is used, workflows are triggered anyway. I just tested pushing with default GITHUB_TOKEN and:
remote: Permission to pack-bot/homebrew-test.git denied to github-actions[bot].
fatal: unable to access 'https://github.com/pack-bot/homebrew-test.git/': The requested URL returned error: 403

Success (green ✅) for when commits aren’t compliant but the action has figured out it can clean them up automatically.

Note: doing this for brew style would also be nice. I think this would just be a matter of replacing all our calls of brew style with brew style --fix and making @BrewTestBot commit the results.

If the commit style violation is going to be fixed automatically, then a failure state may confuse both maintainers and contributors.

Agreed. No reason to make humans do what machines can.

We've tended to avoid workflows that modify contributor branches because it can be confusing, but if it happens right before a merge it's probably not going to be a big problem.

We're not also guaranteed to have permissions (depending on user settings).
Something like https://github.com/veggiemonk/skip-commit/issues/5 could be useful to allow us to push and have it skip CI automatically in this (and perhaps other cases). This might also be useful for doing "manual review but don't run CI" PRs with changing many formulae at once.

I guess one question we could ask is how, uh, committed we are to having bottle commits vs squashing together the version change + bottle update.

I guess one question we could ask is how, uh, committed we are to having bottle commits vs squashing together the version change + bottle update.

I think separate bottle commits are nice. They have a different author and clearly differentiate between the user change and the @BrewTestBot change. I do think e.g. a brew style --fix commit could be part of the bottle commit, though?

I do think e.g. a brew style --fix commit could be part of the bottle commit, though?

That means we’d lose a little luxury: today, I can be pretty confident that whenever I look at an already-merged commit, I can trust that what the commit did doesn’t break the style rules of that time.
If we choose to squash the style --fix result into the bottle commit, then the contributor’s squashed commit would now introduce the original style violations to the linear Git history.
I’m sure I’d eventually cope but having style fixes engrained in the linear history doesn’t feel right.

That means we’d lose a little luxury: today, I can be pretty confident that whenever I look at an already-merged commit, I can trust that what the commit did doesn’t break the style rules of that time.

Yes, that's a fair point (particularly if we're altering the commit message anyway).

I’m sure I’d eventually cope but having style fixes engrained in the linear history doesn’t feel right.

Agreed 👍🏻

Inspired by what @claui just said: I would say that once we end up going down the "automatically modifying users' commits" I'm a lot less against (and, given enough time, may be actively for) merging the bottle commits into their commits. It's a bit annoying jumping around in Git history and ending up on the commit changing a formula but which doesn't have the new bottle SHAs yet (so bottle downloads will fail).


[Design] The return type of get_api_version and supported_api_version is not homogeneous

The return type used to be str for get_api_version and bool for supported_api_version. However it gets complicated after #4983 introduces operation group api version. Both functions will return a namedtuple (later changed to _ApiVersion by me for performance reason) when the specific command module supported SDKProfile.
It makes the API misleading and confusing. For example,
if self.supported_api_version(...):
    pass

Above condition will always render True for compute SDK because it returns an instance now. The consumer of the APIs need to take care of the type before the test the condition.
It is a bad design.
Following is a PR intends to address the issue:
https://github.com/Azure/azure-cli/pull/5167

No a critical item and we have no resources on this


CU-85zryq7wu_Solve-java125-code-smell-code-in-IssueRequestjava

CU-85zryq7wu - Solve java:125 code smell code in IssueRequest.java

Task linked: CU-85zryq7wu Solve java:125 code smell code in IssueRequest.java


Vickel: Watch justanotherpanel.com

Vickel requests the watch of the watch_keyword justanotherpanel\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

justanotherpanel\.com has been seen in 1 true positive, 1 false positive, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


Update setup.sh notation cli commands to be compatible with RC.1

Resolves issue #53
I also removed the notation cert add command because it's not used to verify the certificate in the tutorials and the changes made in RC1 broke the previous syntax. If you'd like to add it back in, please let me know.

Hi @patrickzheng200, would you be able to review this PR?

Closing this PR since setup.sh was removed.


Reset.less missing very important div/span styles?

Ok, I know you guys modified Eric Meyer's Reset Script to remove some elements that were never used (as stated in the comments). So I can understand dfn, samp, etc...
But why in god's name would you remove the margin: 0 / padding: 0 on div & span? I could understand if you didn't want the other parts of the 'catch all' reset on them, but browsers have REALLY INCONSISTENT div/span support (especially in older versions of IE/FF).
Also, the zoom: 1 for hasLayout I've had trouble with in IE7. I keep getting mystery padding at the top of some of my divs with paragraphs/headers in them. The only way I could solve this was with the following hasLayout fix.
div { display: inline-block; }
div { display: block; }

It's the older form I've seen around the net.
Am I on crack? Is there good reasoning, because so far I've seen it do nothing but totally break the consistency between IE7&8 compared to FF/Chrome.

Necolas is correct.


Running Scenarios with Manual Control

Describe your question or idea
Hello Scenario_Runner developers! I'm pretty new to scenario_runner and am trying to reproduce the simple scenario that you show at the 1:08 minute mark in the CARLA Talks 2020 - Introducing ScenarioRunner video.
I'm issuing the following commands (as suggested at the 3:31 time mark in the same video)
python3 scenario_runner.py --scenario DynamicObjectCrossing_1
python3 manual_control.py
I'm finding that I'm getting 2 ego vehicles in different parts of the map. scenario_runner.py produces an ego vehicle and manual_control.py also produces its own separate ego vehicle.
Expected behavior
I would have expected that manual_control.py would be able to find the existing ego vehicle and apply manual control to it.
Insead, it looks like one option is to run the commands in the following order
python3 manual_control.py
python3 scenario_runner.py --scenario DynamicObjectCrossing_1 --waitForEgo
In this case, manual_control.py spawns the ego and then scenario_runner.py moves the ego to the start location of the scenario.
What is the correct way to do this? Is there a way to have manual_control.py find an existing ego vehicle and apply manual control to it?
Desktop (please complete the following information):

OS: [e.g. Ubuntu 18.04]
CARLA Version [e.g. CARLA 0.9.10]
Python version [e.g. 3.6.9]
Scenario Runner Version [e.g. 0.9.10]

Hi,
did you use the manual_control.py of CARLA or the one next to scenario_runner.py? You have to use the latter.

Hi @fabianoboril , I was indeed using Carla's manual_control.py. Thank you for catching my mistake!

Hello,do you know how to lay out the scenario you created on the route? At the same time ,do you know how to create your own planned route in a town?


Add Update Remove-Item command line options

The cause of this would be my PR from 7/12. It would appear that the Remove-Item now requires the -Recurse and -Force options, since the removal of the TargetFramework which now builds for all targets.
The pipeline that hit this failure was net - identity. I'm running net - identity - ci and net - core - ci, both of which already successfully passed the generation steps.
I've also used Beyond Compare to do binary diff the produced docs and, outside of the file timestamps, the contents are identical.

Because there are no pipelines that directly run against this, I'm going to hit the "merge without waiting for requirement..." checkbox.


feat: 🎸 confidential assets

Description

Breaking Changes

JIRA Link

Checklist

[ ] Updated the Readme.md (if required) ?

@prashantasdeveloper , please fix:

https://github.com/PolymeshAssociation/polymesh-subquery/pull/196/commits/26c96ad0031240198b2806af6ffab22d416fb1c9
https://github.com/PolymeshAssociation/polymesh-subquery/pull/196/commits/8834f4f56456f0defeec5f538ac3b7d259729c49
https://github.com/PolymeshAssociation/polymesh-subquery/pull/196/commits/64349ec039133f2dfa8983ca206ae203a485b16d
https://github.com/PolymeshAssociation/polymesh-subquery/pull/196/commits/ce670c1ecc1c69fbfdfc428fd02ca2cdee8c5a51
https://github.com/PolymeshAssociation/polymesh-subquery/pull/196/commits/30819eeeaf33c761b6d3135fb7d649eeecf9fd33
https://github.com/PolymeshAssociation/polymesh-subquery/pull/196/commits/13f33b6dd199af3e19d708e3498f7b8ed3b820bd
https://github.com/PolymeshAssociation/polymesh-subquery/pull/196/commits/652a4597fc7dffb652206d38d7184d6dfa03c95f

seems like this version is having trouble starting up in CI
In middleware tests there seems to be an issue with v11+ starting up.
@prashantasdeveloper any ideas: https://github.com/PolymeshAssociation/polymesh-subquery/actions/runs/7564618656/job/20599023280?pr=196

@quinndiggitypolymath we need to remove 41b2779 from here. That is a work in progress https://github.com/PolymeshAssociation/polymesh-subquery/pull/195

@prashantasdeveloper any ideas: https://github.com/PolymeshAssociation/polymesh-subquery/actions/runs/7564618656/job/20599023280?pr=196

@polymath-eric IMO the confidential assets one was a WIP and might be causing the failure.

:tada: This PR is included in version 13.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


added resnet model

I have made changes as per review.

I have deleted the underlying MLH branch as Rohan said it is fine to not use the MLH forks so I will be directly pushing from my fork further on. I know its annoying and I apologize for that but I am closing this here and opening a new one.


Custom Headers Exists, But Not All API Calls Expose Custom Params

What is the current behavior?
Just like the title says... in v3.0.0-rc.1.
Steps to reproduce

To make it faster to diagnose the root problem. Tell us how can we reproduce the bug.

Expected behavior

What would you expect to happen when following the steps above?

Please tell us about your environment

We want to make sure the problem isn't specific to your operating system or programming language.

Operating System/Version: Windows 10
Language: [all | TypeScript | Python | PHP | etc]
Browser: Chrome

Other information

Anything else we should know? (e.g. detailed explanation, stack-traces, related issues, suggestions how to fix, links for us to have context, eg. stack overflow, codepen, etc)

PR merged: https://github.com/deepgram/deepgram-python-sdk/pull/215
Closing!


[ENH] add pyafq support directly

Previously, pyAFQ generated a folder that AFQ-browser could read.
With this, AFQ-browser will read pyAFQ outputs

@arokem this should also fix the errors people were seeing

Hmm. I wonder if we should wait a few days for DIPY release and then upgrade to numpy>=2.0 across all of our projects?

Yes, that makes sense