Strange behaviour of 0.17.3 (working ok in 0.17.2)

[narimiran]

When running this script with this input file, in stable 0.17.2 version I get the (correct) answer:

kgdchlfniambejop
fjpmholcibdgeakn

in about 0.15 seconds.

---

Compiling the same thing in devel 0.17.3 version gives a lot of random characters (this is just a few first lines):

ffppjppffpocccapohbbpaapphaabgabjalclaplaappdapadlpadaaaalaaaalaaladalabadaladadaffikpadaapklaaaapaakkpkamaaaaaaaaaaaaaaaaeaaaabnaaaaaaaaaaaaaaaaaaaaapkjdeaaaealaaaaaapaaaeaaaaaaachhhhhhhhhhhhhhhhhhkhhajhhhhfhhhhhhahhhhhahhaheehhfhhahhhhdhhbahdhdhhadhhahhhjhlhhhhadgahhhhfhhhdhhhdhhhhhhdfehadhhdhddekdgcchdppdolboadagddaadhahdhahaddddddgddhdcdddcadedapdddadadddagdahahddhhdddhahddanhebbcbebdeeeppehehefhhhhfhdphplhampfpphpfppophokfoofogfgpgooopagfhfofoppfofbofpfopoldfofffeddogpdpdpdkpdkfpedpopdneknknnndnopnoooonononoodoooknkkkohooooooooookooooooooooooojooopoaoooocooooodoepofolooobebooobobdoboboookooobbbbooooobobbobnobebbbobobhbolakopobbhboonoooobbobookoboboboobdodbdbdadododoooddooaoeobooooaododgdodooondoododoodooooobooookoojoogooojojgbogoooofooooofoaogaoogooggggeldkkjkbkkfbdbc

and after a minute I had to manually stop it.

[Araq]

OS, CPU and C compiler?

[narimiran]

OS, CPU and C compiler?

OS: Manjaro Linux
CPU: Intel i7-970
C compiler: gcc (GCC) 7.2.1 20171128

Both 0.17.2 and 0.17.3 were installed via choosenim.

Same random output on Arch Linux with Clang 5.0.1
Intel i5 4460

[Araq]

It works with this line

      result = result[result.len - rot .. result.high] & result[0 ..< result.len - rot]

Investigations continue...

[skilchen]

It also works with this insertion before proc dance

when compiles(BackwardsIndex(1)):
  proc pred*(x: BackwardsIndex, y = 1): BackwardsIndex =
    BackwardsIndex(x.int + y)
  template `..<`*(a, b: untyped): untyped =
    ## a shortcut for 'a..pred(b)'.
    a .. pred(b)

somehow in the template ..< in system.nim the call pred(b) erases the property (type) of b being a BackwardsIndex.

[dom96]

This seems possibly related: #6992

[narimiran]

Any news on this one?

[skilchen]

I now think that there is no misterious type erasure problem at work here. During the introduction of BackwardsIndexit was simply overlooked that the logic for pred and succ has to be reverted for backwards indices. Currently there is only one generic implementation of pred and succ for any ordinal type.
Maybe it would be enough to add overloads for BackwardsIndex like so:

proc succ*(x: BackwardsIndex, y = 1): T {.magic: "Pred", noSideEffect.}
proc pred*(x: BackwardsIndex, y = 1): T {.magic: "Succ", noSideEffect.}

I didn't investigate if there are other places, where backwards indices should be handled separately.