If I have a template, and it is used, directly or indirectly, in many places, and it has a compile error, is there a 'trick' to find out which call location causes the error? (Beyond commenting out every location until the error is gone) 2017-12-05 11:38:43
Read the "instantation from here" error hints?
2017-12-05 12:22:48

I've seen those, but I was thinking about all the bits that are "red" in VS-Code... Mostly because I cannot immediately see what is wrong with the location where the compiler stops, and hoped I that it might "go away" if I could fix the "other locations" that VS-Code shows. The compiler gives me one error and stops, but VS-Code shows me many errors. I guess I could just try to fix the one error (with context) that the compiler gives me, and repeat until "nothing is red anymore".

But how does VS-Code find multiple "error locations" if the compiler stops after the first error? I just check the compiler "help", and could not see something that tells it to carry on compiling after the first error.

2017-12-05 18:40:04
The "proc []" of my "shared seq" had a return type of "T" instead of "var T". The compiler did give me all the info I needed; I was just unable to understand it.
2017-12-05 19:34:51

nim check mycode.nim

But it is true, if errors are in code with generics, templates or macros it can occur that there is absolutely no useful hint to the real error location. For example as error position code in system.nim is showed. And some hours ago I had a case with generics where there was shown an WRONG line number for error position.

2017-12-05 19:37:39

In rare situations, I compile with --verbosity:2 to get more info.

It is not needed here, but worth remembering.

2017-12-05 20:31:45