Created attachment 284399 [details] [review]
don't write line directives when not needed

Does this fix your issues?

I did the following: 

git clone https://github.com/GNOME/vala.git
cd vala
<applied the patch>
sudo apt-get install flex
sudo apt-get install bison
./autogen.sh
./configure 
sudo make install

And make clean && make on my application

And it didn't change anything.

But you shouldn't see the #line without the path anymore, right?

As a sidenote, the correct sequence to build vala is 

git clone https://github.com/GNOME/vala.git
cd vala
sudo apt-get install valac
sudo apt-get install flex
sudo apt-get install bison
./autogen.sh
./configure 
sudo make install
sudo ldconfig

Here a sample of C file generated http://pastie.org/9590367

There is still a directive 

line #line 91 "error_colors.c"

Can you please paste the Vala file?

http://pastie.org/9590441

valac --version
Vala 0.26.0.11-a47f-dirty

Repasting here to avoid pastebin expire:

private void this_will_crash ()
{
	var hi = "johnny !" ;
	assert (hi == "wiseau");
    message ("I haven't crashed") ;
}

int main (string[] args) {
	// Soothing, uh?
	Stacktrace.default_highlight_color = Stacktrace.Color.GREEN ;
	Stacktrace.default_error_background = Stacktrace.Color.WHITE ;
    Stacktrace.register_handlers () ;

	stdout.printf("  This program will crash with fancy colors!\n" ) ;

    this_will_crash () ;
    return 0 ;
}

Complete file and project here :
https://github.com/PerfectCarl/vala-stacktrace/blob/master/samples/error_colors.vala

This is still an issue!

I just (like... spend half a day on this) installed Visual Studio Code and was happy that I could debug (step through) Vala code with VSC. Then I became a bit disappointed that VSC would report that it could not find c-files. I debugged the issue and came to the same conclusion... The Vala compiler emits full paths for #line-statements for .vala files, but only filename (or relative paths?) for .c-files.

I was about to file a bug, when I decided to search a bit.... and yes... a 3 year old bug report! It seems to me to be such a simple fix (if you know your way around the codebase) and still it has not gotten any attention.

Valac version: 0.36.6

(In reply to Jørn Christensen from comment #10)
> I just (like... spend half a day on this) installed Visual Studio Code and
> was happy that I could debug (step through) Vala code with VSC.

That sounds good. How easy was it to get that working? I assume the half day includes investigating the #line problem? A blog post or some details on how you set this up would be helpful to add to our wiki about tools.

> Then I became a bit disappointed that VSC would report that it could not find
> c-files. I debugged the issue and came to the same conclusion... The Vala
> compiler emits full paths for #line-statements for .vala files, but only
> filename (or relative paths?) for .c-files.

It's the filename only. I've just done a test build with Meson. Meson now uses the --basedir switch with valac and only the filename is output. See https://github.com/mesonbuild/meson/pull/2413 for details on that change to Meson. A Meson developer did ask at the time for the C filenames to be flat instead of output to directories.

The filenames should be relative in order to generate reproducible builds (https://reproducible-builds.org/). This is already in our bug tracking - see https://bugzilla.gnome.org/show_bug.cgi?id=769935 How do relative paths work with tools like VSC? Although I note MSVC has the /FC switch (https://msdn.microsoft.com/en-us/library/027c4t2s.aspx) for including full paths in diagnostics.

At the moment my understanding is the #line to the C file is printed at the end of the C function. What use case do have for this? At the moment it looks like people have tried to use this for breakpoints in gdb (https://bugzilla.gnome.org/show_bug.cgi?id=664922) and symbol translation for stack traces (https://bugzilla.gnome.org/show_bug.cgi?id=738784).

In terms of writing tests for the Vala compiler test suite. We could use assert with __LINE__ and __FILE__ to check the values are as expected. At present we don't have bindings for __LINE__ or __FILE__. Something like this works:

void main () {
    print ("%d\n",Debug.LINE_NUMBER);
    print (Debug.FILE + "\n");
}

namespace Debug {
    [CCode (cname = "__LINE__")]
    extern const int LINE_NUMBER;

    [CCode (cname = "__FILE__")]
    extern const string FILE;
}

> I was about to file a bug, when I decided to search a bit.... and yes... a 3
> year old bug report! It seems to me to be such a simple fix (if you know
> your way around the codebase) and still it has not gotten any attention.

Vala is currently maintained by a small team, who only have so much time to work on it. The number of open bugs has gone down significantly over the past year or two thanks to the efforts of one or two core people. Getting additional contributors on board is a goal for us. So if you have any insights about how this could work better that would be helpful. Including the use of the #line C pre-processor directive in Vala's generated C.

(In reply to Al Thomas from comment #11)
> (In reply to Jørn Christensen from comment #10)
> > I just (like... spend half a day on this) installed Visual Studio Code and
> > was happy that I could debug (step through) Vala code with VSC.
> 
> That sounds good. How easy was it to get that working? I assume the half day

The initial set was actually very straight forward and worked out of the box.

1) I installed Visual Studio Code
2) I build the project (Shotwell in this case) outside MSC with debug option.
3) MSC saw that I opened vala files and suggested me to install the Vala Code plugin.
4) Pressing F5 (Debug) MSC guided me how to configure a debug session
5) Stepping through Vala code just worked, but I got errors about not-found C-files.

I think I saw somewhere that MSC was listed as having a bit of Vala compatibility, so I am not sure how much of a guide is needed.

I *think* that the modules responsible for being able to debug Vala is actually not the Vala Code plugin (I think it only does the syntax highlighting) but the pre-installed C/C++ plugin. I *think* it is actually just the interaction with GDB that works any file marked as source file.

> > Then I became a bit disappointed that VSC would report that it could not find
> > c-files. I debugged the issue and came to the same conclusion... The Vala
> > compiler emits full paths for #line-statements for .vala files, but only
> > filename (or relative paths?) for .c-files.
> 
> It's the filename only. I've just done a test build with Meson. Meson now
> uses the --basedir switch with valac and only the filename is output. See
> https://github.com/mesonbuild/meson/pull/2413 for details on that change to
> Meson. A Meson developer did ask at the time for the C filenames to be flat
> instead of output to directories.
> 
> The filenames should be relative in order to generate reproducible builds
> (https://reproducible-builds.org/). This is already in our bug tracking -
> see https://bugzilla.gnome.org/show_bug.cgi?id=769935 How do relative paths
> work with tools like VSC? Although I note MSVC has the /FC switch

Relative to what?

I tried making all the paths relative to the build dir (*) and it worked fine with VSC – but why it works, I don't know. According to the launch configuration, the CWD should not be the build dir, but the project dir (i.e. the parent dir of build/). So there is some link here I am missing.

(*) Is this standard for meson / ninja? To have a dir names build/ and all generated output there? I am still very new to Meson / Ninja, which also was part of my half day trying to understand whether the bug was theirs, and when not, if it was possible to add a (scripting) step between Valac and CC. In the end, I wrote a valac wrapper and put it first in path!


> (https://msdn.microsoft.com/en-us/library/027c4t2s.aspx) for including full
> paths in diagnostics.

This is for Microsoft Visual Studio (i.e. the full edition with compiler and all). I am working with the free open source Visual Studio Code. No compiler included here. 

But perhaps your point with that link was another one...?

> At the moment my understanding is the #line to the C file is printed at the
> end of the C function. What use case do have for this? At the moment it

It is much more comprehensive than that. It is for each code line in the c-file. If the line matches a vala code line, then that is added as a comment. If it is auto generated code / hidden code, then the C-line is added.

See my attachment for a screenshot of a code file. You can see how vala references are absolute, while c-references are filename only. And you can see my scripting changes to the file.

I am not sure why the c-lines are needed. I mean... normal C-programs do not have these #line comments and they are debugable just fine. Perhaps it is because Vala code lines are marked and thus it confuses the debugger (-parser) if C-lines are not marked?

> looks like people have tried to use this for breakpoints in gdb
> (https://bugzilla.gnome.org/show_bug.cgi?id=664922) and symbol translation
> for stack traces (https://bugzilla.gnome.org/show_bug.cgi?id=738784).

I think that is how GDB / VSC uses those as well.

> > I was about to file a bug, when I decided to search a bit.... and yes... a 3
> > year old bug report! It seems to me to be such a simple fix (if you know
> > your way around the codebase) and still it has not gotten any attention.
> 
> Vala is currently maintained by a small team, who only have so much time to
> work on it. The number of open bugs has gone down significantly over the

Fair enough.

Sorry for my outcry. I was just feeling a bit frustrated. I have been pondering the last couple of days whether I should dive into Shotwell (but was frustrated with the lack of good IDEs for Valac), dive into Darktable (which I like for the photo editing but not for the photo management) or try to start something new (in Qt / C++ which seems to have good tool support).

> past year or two thanks to the efforts of one or two core people. Getting
> additional contributors on board is a goal for us. So if you have any
> insights about how this could work better that would be helpful. Including
> the use of the #line C pre-processor directive in Vala's generated C.

I do not have a lot of insights. I just hacked a bit on my computer.

~Jørn

Created attachment 369786 [details]
Screenshot of code changes for file paths

Hi Jørn,

Thanks for your comments, they are helpful.

(In reply to Jørn Christensen from comment #12)
> I *think* that the modules responsible for being able to debug Vala is
> actually not the Vala Code plugin (I think it only does the syntax
> highlighting) but the pre-installed C/C++ plugin. I *think* it is actually
> just the interaction with GDB that works any file marked as source file.

Sounds reasonable. I read that C/C++ plugin also supports LLDB and Visual Studio Windows Debugger (https://code.visualstudio.com/docs/languages/cpp#_debugging). From the Vala perspective we want to find if there is a de facto standard for filenames. 


> Relative to what?

I'm not sure yet. I was thinking relative to the project root directory. So all Vala files are in that directory or below. This would meet the reproducible build requirement.


> I tried making all the paths relative to the build dir (*) and it worked
> fine with VSC – but why it works, I don't know. According to the launch
> configuration, the CWD should not be the build dir, but the project dir
> (i.e. the parent dir of build/). So there is some link here I am missing.
> 
> (*) Is this standard for meson / ninja? To have a dir names build/ and all
> generated output there?

Meson is designed for out of source tree builds. So yes it is standard. Ninja can be invoked with the -C switch to change to the build directory.

It looks like `directory` is the GDB command to set a project root directory. `show directories` prints the source paths in GDB. `directory /home/me/my_project/` would add the project root to GDB. For more: https://sourceware.org/gdb/onlinedocs/gdb/Source-Path.html

I'm not sure if there is a way for Visual Studio Code to pass that to GDB. Maybe there is something about that in https://code.visualstudio.com/docs/extensions/example-debuggers. From a Vala perspective a simple filename relative to the project root would be good. This may need an option to valac to specify the project root, but otherwise it would be down to the debugger to be informed of the source directory. Not sure about LLDB or the Windows Debugger.


> > (https://msdn.microsoft.com/en-us/library/027c4t2s.aspx) for including full
> > paths in diagnostics.
> 
> This is for Microsoft Visual Studio (i.e. the full edition with compiler and
> all). I am working with the free open source Visual Studio Code. No compiler
> included here. 
> 
> But perhaps your point with that link was another one...?

Yeah, I meant we could add an option to valac to include full source file paths. Only if necessary in my view.


> It is much more comprehensive than that. It is for each code line in the
> c-file. If the line matches a vala code line, then that is added as a
> comment. If it is auto generated code / hidden code, then the C-line is
> added.
> 
> I am not sure why the c-lines are needed. I mean... normal C-programs do not
> have these #line comments and they are debugable just fine. Perhaps it is
> because Vala code lines are marked and thus it confuses the debugger
> (-parser) if C-lines are not marked?

Hmmm, it would make it easier if they were not needed because I think C filenames should be relative to the build directory. Then again with GDB the directory could be passed with the `directory` command.

> I do not have a lot of insights. I just hacked a bit on my computer.

Your comments have given me some useful insights. Thanks. Swapping the project path for ../ in your screenshot was useful. I'm hoping the `directory` command will be enough to no longer need the ../ as well.

Hi :-)

(In reply to Al Thomas from comment #14)
> (In reply to Jørn Christensen from comment #12)
> (https://code.visualstudio.com/docs/languages/cpp#_debugging). From the Vala
> perspective we want to find if there is a de facto standard for filenames. 

Searching a bit, I found this:
https://stackoverflow.com/questions/9607155/make-gcc-put-relative-filenames-in-debug-information

In the comments to the original question, it is indicated that gcc puts the path of the code file as it gets it. I don't know if it is standard, but it sounds like a good solution.

> It looks like `directory` is the GDB command to set a project root
> directory. `show directories` prints the source paths in GDB. `directory
> /home/me/my_project/` would add the project root to GDB. For more:
> https://sourceware.org/gdb/onlinedocs/gdb/Source-Path.html

Again, this is where my knowledge falls short. I *thought* that gdb would just spit out line information that it got from the debug section put in by gcc. Why would gdb need to know source directory? I thought it was VSC (or other graphical IDE) 's responsibility to take that information and open the correct file on the correct line number. The IDE may then need a source code search path.

But clearly, I am missing something here.

> I'm not sure if there is a way for Visual Studio Code to pass that to GDB.
> Maybe there is something about that in
> https://code.visualstudio.com/docs/extensions/example-debuggers. From a Vala

My immediate bet is that it could be added to the C/C++ debugger adapter – which is open source as well. But again... I don't see why that is needed.

> perspective a simple filename relative to the project root would be good.
> This may need an option to valac to specify the project root, but otherwise

I think, like gdb, just relative to working directory of valac in the first place. And if that is not enough, then options to valac to set project root and/or use absolute paths.

> Yeah, I meant we could add an option to valac to include full source file
> paths. Only if necessary in my view.

On one hand, I think it will be fine with the relative-to-invocation path. On the other hand, if the code impact is not big, it would not hurt to implement the other options as well.

> > I am not sure why the c-lines are needed. I mean... normal C-programs do not
> > have these #line comments and they are debugable just fine. Perhaps it is
> > because Vala code lines are marked and thus it confuses the debugger
> > (-parser) if C-lines are not marked?
> 
> Hmmm, it would make it easier if they were not needed because I think C
> filenames should be relative to the build directory. Then again with GDB the
> directory could be passed with the `directory` command.

If found the line control documentation of gcc:
https://gcc.gnu.org/onlinedocs/cpp/Line-Control.html

This clears it up a bit. Line control is needed because valac is a source-to-source compiler and thus automatic line-enumeration of the code does not work. When #line is used, all the following statements are attributed to that line. 

It also means that if the c-line enumeration were to be omitted, then (according to the documentation) multiple c-lines would be attributed to the same vala lines. Trying this, did unfortunately not work. The stepping then suddenly jumped all over the code base and my 10 minutes investigation could not figure out why.

But... for future functionality, it would be feasible if the user could choose whether to
  a) stay in vala code
  b) stay in c-code
  c) jump back and forth (which is the current behaviour, when paths are correct).

It would be nice if the debugger / IDE could do this on the fly, but otherwise, a re-compilation (perhaps of a subset of files) could be a work-around. This would require a options to valac, though (to either omit c-enumeration or vala-enumeration).


> > I do not have a lot of insights. I just hacked a bit on my computer.
> 
> Your comments have given me some useful insights. Thanks. Swapping the

Glad they did :-)

~Jørn

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vala/issues/469.