next_error is opening the wrong file.c

[rowbearto]

See attached project: samefile.tgz

The SE project is configured so that when you do a build it will do a 'cat build.log'

The build.log has the following error in it:

Code: [Select]

/samefile/dir2/file.c:3:11: warning: Null pointer dereference: (int*)0 [nullPointer]
When I do 'next_error', I am expecting SE to open the file.c in directory 'dir2', but instead it is opening the file.c that is in 'dir1'.

I know this issue was fixed in a previous version of SlickEdit and there was a thread in this forum about it, but I can't find that post.

This happens with 25.0.2, clean config, Linux x64, CentOS 7.7.

[patrick]

I can see this, but it's happening for me because the path /samefile/dir2/file.c is a absolute path that does not exist on my system.  So it falls back on looking for a file with the same base name in the project.   It will pick the right file if the path is correct.

I do see some fixes that are for improving the case where the path is relative and could match multiple files, which may be the fix you're thinking of.  Without diving too deeply, I don't think it would work with an absolute path.  I don't see anything that says "this absolute path is wrong, can we treat it as a valid relative path if we peel items off the lhs?". 

So to make sure I'm seeing the same thing:  Does that absolute path (/samefile/dir2/file.c) exist on your system?   Or is it not supposed to be absolute?  Or is some tool working under a chroot and reporting absolute paths that would be different for our view of the filesystem?

[rowbearto]

/samefile/dir2/file.c does not exist on my system either.

There are actually directories above the /samefile/dir2/file.c, but the tool that outputs this cuts out the upper directories when it reports the error message. Without going into details it would be difficult to modify this tool to not cut out the upper directories.

It would be nice if SE could look at the path starting from the right side, so if it sees the basename of "file.c" and it knows there are multiple "file.c" then it could check to see which file.c in the project has "more of a match"

[patrick]

There are other cases outside of tooling producing truncated paths that this can help with, so I'm testing a fix for this.  If all goes well, I'll check it in for the next hotfix.

[rowbearto]

Thanks Patrick!