Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix ocamldebug module source lookup #6562

Closed
vicuna opened this issue Sep 17, 2014 · 8 comments

Comments

Projects
None yet
2 participants
@vicuna
Copy link

commented Sep 17, 2014

Original bug ID: 6562
Reporter: @lpw25
Assigned to: @damiendoligez
Status: closed (set by @damiendoligez on 2014-10-03T15:28:23Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 4.02.0
Target version: 4.02.1+dev
Fixed in version: 4.02.1+dev
Category: tools (ocaml{lex,yacc,dep,debug,...})
Tags: patch
Monitored by: @gasche

Bug description

The attached patch fixes the following issues with ocamldebug's module source lookup:

  • Source file names in pos_fname can be relative to the compilation directory, in which case the compilation directory should be included in debug_dirs.

  • Relative filenames (e.g. "../foo.ml") were being treated as relative to the directory in which the debugger was run, instead they should be looked-up from the path.

  • If an absolute source filename is used and the file is removed then the debugger raises an uncaught exception about a missing file.

Since these fixes are very small I include them in a single patch. They are also probably worth including in 4.02.1.

File attachments

@vicuna

This comment has been minimized.

Copy link
Author

commented Sep 17, 2014

Comment author: @garrigue

These look like reasonable bug fixes, and I buy everything that improves ocamldebug usability, so I would like to commit this one.
Anyone sees a problem?

@vicuna

This comment has been minimized.

Copy link
Author

commented Sep 18, 2014

Comment author: @gasche

Why does the implementation of find_in_path_rel try to normalize path in its "simplify" function? I'm surprised that this logic would be necessary. I understand that find_in_path cannot be used directly because it only looks in the path for "implicit" filenames¹.

I think we could just generalize find_in_path to abstract over the test used in the branch (implicit or relative; over a function or a boolean deciding which function to use, as you prefer), and then call that directly from source.ml -- this would also include the "if not (Sys.file_exists ...) then raise Not_found" logic.

¹ note to others: a filename of the form ./path or ../path is relative but not implicit, and supporting relative-but-not-implicit paths is also the reason for the proposed change in source.ml.

@vicuna

This comment has been minimized.

Copy link
Author

commented Sep 18, 2014

Comment author: @lpw25

Why does the implementation of find_in_path_rel try to normalize path in its "simplify" function?

So that the filenames displayed by ocamldebug do not look like:

foo/bar/.././baz.ml

The logic was copied from Location.absolute_path.

We could provide a "Location.simplify_path" function and then call that from source_of_module instead if you prefer.

@vicuna

This comment has been minimized.

Copy link
Author

commented Sep 18, 2014

Comment author: @lpw25

We could provide a "Location.simplify_path" function and then call that from source_of_module instead if you prefer.

Or just drop it, it doesn't really matter if the names are displayed badly since they are only really used by emacs -- which probably won't even display the full path.

@vicuna

This comment has been minimized.

Copy link
Author

commented Sep 22, 2014

Comment author: @damiendoligez

I don't agree with the simplify function.

Do this:

cd /tmp
mkdir foo
ln -s . foo/bar
ls /tmp/foo/bar/..

You will notice that /tmp/foo/bar/.. is /tmp, while the simplify function returns /tmp/foo.

We should drop it.

@vicuna

This comment has been minimized.

Copy link
Author

commented Sep 23, 2014

Comment author: @lpw25

I'm away this week, so cannot test it, but this probably means that Location.absolute_path is broken as well.

@vicuna

This comment has been minimized.

Copy link
Author

commented Sep 28, 2014

Comment author: @damiendoligez

I'm away this week, so cannot test it, but this probably means that Location.absolute_path is broken as well.

Yes it is. Good catch!

@vicuna

This comment has been minimized.

Copy link
Author

commented Oct 3, 2014

Comment author: @damiendoligez

Patch applied after removing the .. case in simplify (branch 4.02, rev 15455).

I've also opened a new PR for Location.absolute_path (#6595).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.