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

Parsetree.row_field.Rtag should have constructor location #6499

Closed
vicuna opened this issue Jul 26, 2014 · 7 comments
Closed

Parsetree.row_field.Rtag should have constructor location #6499

vicuna opened this issue Jul 26, 2014 · 7 comments

Comments

@vicuna
Copy link

vicuna commented Jul 26, 2014

Original bug ID: 6499
Reporter: @whitequark
Assigned to: @diml
Status: assigned (set by @whitequark on 2017-01-06T21:26:21Z)
Resolution: open
Priority: normal
Severity: feature
Version: 4.02.0+beta1 / +rc1
Category: lexing and parsing

Bug description

There's a TODO in parsetree.mli about that, but I'll file a bug for posterity anyway, since this is quite annoying.

@vicuna
Copy link
Author

vicuna commented Jul 30, 2014

Comment author: @damiendoligez

It's a good idea to file a report here. TODO in source file is largely ignored, PRs here have more visibility.

@vicuna
Copy link
Author

vicuna commented Jan 5, 2017

Comment author: @diml

I second this request, not having a location here is annoying. Although it seems to me that [Rinherit _] should have a location as well, for consistency. Maybe we should split the [row_field] type between a wrapper record and a [row_field_desc] type as it is done for the other nodes?

@vicuna
Copy link
Author

vicuna commented Jan 6, 2017

Comment author: @whitequark

Maybe we should split the [row_field] type between a wrapper record and a [row_field_desc] type as it is done for the other nodes?

I agree that this makes sense.

@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.

@github-actions github-actions bot added the Stale label May 11, 2020
@whitequark
Copy link
Member

Still an issue.

@Octachron
Copy link
Member

This was fixed by #1903 as far as I can see.

@whitequark
Copy link
Member

Ah, I missed that! 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

3 participants