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

Assert failure with warning 34 on pre-processed file #5805

Closed
vicuna opened this issue Oct 31, 2012 · 4 comments
Closed

Assert failure with warning 34 on pre-processed file #5805

vicuna opened this issue Oct 31, 2012 · 4 comments
Assignees

Comments

@vicuna
Copy link

vicuna commented Oct 31, 2012

Original bug ID: 5805
Reporter: turpin
Assigned to: @alainfrisch
Status: closed (set by @alainfrisch on 2012-11-07T16:28:24Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 4.00.1
Fixed in version: 4.01.0+dev
Category: typing
Has duplicate: #5961

Bug description

Env.set_type_used_callback raises an assert failure with warning 34 enabled, for a pre-processed source file. However, maybe the OCaml Ast that I generate (not a Camlp4 AST) doesn't respect some implicit assumption, because after unparsing with pprintast (which I have modified), the error disappears.

Steps to reproduce

I doubt the ast file will be usefull.

Additional information

Tried with latest svn trunk too.

File attachments

@vicuna
Copy link
Author

vicuna commented Nov 1, 2012

Comment author: @alainfrisch

Could it be the case that your AST contains a ghost location for the type declaration (ptype_loc field)?

@vicuna
Copy link
Author

vicuna commented Nov 1, 2012

Comment author: turpin

Definitely. Many modifications that I do on the ast are not properly located yet, so there are "Location.none" everywhere.

@vicuna
Copy link
Author

vicuna commented Nov 6, 2012

Comment author: @alainfrisch

Can you try with the current trunk? Commit 13065 should fix this issue (the warning will never be raised for declarations without locations, though).

@vicuna
Copy link
Author

vicuna commented Nov 6, 2012

Comment author: turpin

Yes, it is fixed. Thanks.

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

2 participants