Errors at wrong location when using #line directive

[skaller]

OSX, C++ code, using absolute path name of containing directory.

Sourcetrail can't find any files at all. Yet here they are:

~/felix>ls /Users/skaller/felix/build/release/share/lib/rtl/
Judy.h					flx_exceptions.hpp
demux_demuxer.hpp			flx_exceptions_config.hpp
demux_epoll_demuxer.hpp			flx_executil.hpp
demux_evtport_demuxer.hpp		flx_faio_config.hpp
demux_iocp_demuxer.hpp			flx_gc.hpp
demux_kqueue_demuxer.hpp		flx_gc_config.hpp
demux_overlapped.hpp			flx_gc_private.hpp
demux_poll_demuxer.hpp			flx_i18n.hpp
demux_posix_demuxer.hpp			flx_ioutil.hpp
demux_posix_timer_queue.hpp		flx_judy_scanner.hpp
demux_quitter.hpp			flx_pthread_config.hpp
demux_select_demuxer.hpp		flx_re2_config.hpp
demux_self_piper.hpp			flx_rtl.hpp
demux_sockety.hpp			flx_rtl_config.h
demux_timer_queue.hpp			flx_rtl_config.hpp
demux_ts_poll_demuxer.hpp		flx_rtl_shapes.hpp
demux_ts_select_demuxer.hpp		flx_run.hpp
demux_win_timer_queue.hpp		flx_serialisers.hpp
demux_wself_piper.hpp			flx_strutil.hpp
faio_drv.hpp				flx_strutil_config.hpp
faio_posixio.hpp			flx_sync.hpp
faio_timer.hpp				flx_ts_collector.hpp
faio_winio.hpp				flx_udp_trace.hpp
flx_async.hpp				flx_world.hpp
flx_async_world.hpp			flx_world_config.hpp
flx_collector.hpp			plat_linux.hpp
flx_compiler_support_bodies.hpp		pthread_bound_queue.hpp
flx_compiler_support_headers.hpp	pthread_condv.hpp
flx_continuation.hpp			pthread_counter.hpp
flx_demux.hpp				pthread_fast_lock.hpp
flx_demux_config.hpp			pthread_lf_bag.hpp
flx_dl.h				pthread_monitor.hpp
flx_dlopen.hpp				pthread_thread.hpp
flx_dynlink.hpp				pthread_thread_control_base.hpp
flx_dynlink_config.hpp			pthread_waitable_bool.hpp
flx_eh.hpp				re2

[egraether]

Header files are not indexed by default, only if included in a source file. We don't index header files by default, because some users had old and unused header files within their source directory, which caused errors and a lot of confusion for them.

You have 2 options:

• add a main.cpp file that includes all of those headers and add it to Files & Directories to Index in the project settings.
• add .hpp and .h to the list of Source File Extensions in the project settings.

[skaller]

I see, that explains it! Thanks!

One may note though, a lot of C++ libraries are header only.
(Mine aren't though).

[skaller]

OK, it finds files. But there's a bug. I get an error in one file, it appears to be a legitimate error in my code. Great! However the file is generated. There's a #line directive at the top.

The error panel shows the generated file .. not the original source .. but the error line number refers to the original source. So the system can't find the line with the error.

Interestingly the error is "unknown type name" and indeed I put

async_hooker *async;

and the type name async_hooker does appear undefined. The question is why do clang AND gcc accept this code? Of course, the type is incomplete, and there is no ambiguity processing the code, but still .. its an error.

Nice work on that!

I got a few other errors, unfound header files <Windows.h> .. not surprising on OSX :-)
Apart from that .. I hope your analysis is good and there's no error in my code :-)

[egraether]

We use clang libTooling for C++ indexing, so if it compiles on clang, then it works with Sourcetrail.
However, you need to make sure that you configure your Sourcetrail project with the exact same build settings you use for compilation. Please watch our recent video on Project Setup for C++, which also explains clang Compilation Database use: https://www.youtube.com/watch?v=7fguPwKR_7Y

[skaller]

The settings should be the same. I'm not worried about the error. Glad it was found.
I am more worried about the generated file thing. At least for errors, it means the display of the error line doesn't work. The actual line in the displayed file is the reported error minus the #line line number.

[skaller]

BTW: generated files pose a really hard problem. All my C++ sources are generated. Of course you can only analyse the generated files. Probably you should report errors with references to the generated file and some indication of the location in the file that generated it. For my system the generator just dumps sub parts of the original source to make the source (that is, each line in the generated file exists in the original). My system is a simple "literate programming" system.

[egraether]

We don't quite understand your line number issue. Can you please provide a screenshot or some sample code that shows the issue?

[skaller]

Sure: The actual error is on line 26 of the displayed file not line 707.
It is on line 707 of the generator file embed.fdoc.

You can't see well on the picture below, but the error message shows the generated
file flx_async_world.hpp but the line number if from the generator file.

Its inconsistent. If you keep the generated file you have to put the line number in
the generated file. For MY system, you could alternatively show the generator
file name (embed.fdoc) and line 707 and display that. You could also show
both somehow, or allow to jump between them or something.

In my build system the generated *.cpp files are logically transient, that is, they're
ephemeral can can be deleted after the build. The header files are not transient,
they have to be kept.

[mlangkabel]

Fixed with Sourcetrail version 2018.3.35

[skaller]

Thanks! Curious, how it was fixed? I guess the line number is changed to the line in the generated file. Please consider the possibility of also finding the location in the generating file. In particular if one desired to fix an error, one has to do it in the generating file, not the generated file. Of course this is only possible if the generated file is embedded in the generator (i.e. there's an injective map from non #line lines in the generated file into the generator). This is the case for most (but not quite all) of my generated files.