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

Some error and warning messages are not in the standard format. #6080

Closed
vicuna opened this issue Jul 17, 2013 · 3 comments
Closed

Some error and warning messages are not in the standard format. #6080

vicuna opened this issue Jul 17, 2013 · 3 comments

Comments

@vicuna
Copy link

vicuna commented Jul 17, 2013

Original bug ID: 6080
Reporter: @damiendoligez
Status: confirmed (set by @damiendoligez on 2013-10-08T14:49:44Z)
Resolution: open
Priority: normal
Severity: minor
Platform: all
Version: 4.01.0+dev
Category: compiler driver
Monitored by: @hcarty

Bug description

In some cases, the compiler prints errors or warnings in a format that is not recognized by emacs. For example:

$ ocamlc -pp false foo.ml
Error while running external preprocessor
Command line: false 'foo.ml' > /tmp/ocamlppa92222

$ ocamlc -unsafe -pp camlp4o foo.ml
Warning: option -unsafe used with a preprocessor returning a syntax tree

This is bad because such messages get lost in make's log and then you don't even know that something went wrong.

A related problem, the functions Misc.fatal_error and Compenv.fatal are redundant (and they both do it wrong).

@vicuna
Copy link
Author

vicuna commented Jul 20, 2018

Comment author: @damiendoligez

The second part (non-standard warning) is resolved by commit 3d0299a in #1906.

@vicuna
Copy link
Author

vicuna commented Jul 20, 2018

Comment author: @gasche

The "related problem" part seems related to

#1919

Damien, would you mind giving some feedback there, in case the "related problem" can be solved while we are at it?

@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant