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

go/printer: consider using last position for nodes with no position #28988

Open
griesemer opened this issue Nov 28, 2018 · 1 comment
Open

go/printer: consider using last position for nodes with no position #28988

griesemer opened this issue Nov 28, 2018 · 1 comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@griesemer
Copy link
Contributor

Reminder issue to experiment with using the last known (end) position for nodes where we don't have a position (and where NoPos is not used to indicate absence of a token).

From e-mail conversation with @aclements:

On Wed, Nov 28, 2018 at 8:34 AM Austin Clements austin@google.com wrote:
Thanks! Assigning the new Specs I created in the const block to the position of the const worked perfectly.

Is there a reason we don't treat NoPos nodes as having the position of the nearest ancestor when printing?

NoPos sometimes indicates that a token is absent (e.g., the position of '(' or ')' is NoPos if those parentheses are missing).

But I suppose in other cases it might work - interesting thought. I'm slightly worried that making such a change might break existing carefully tuned code though. But worthwhile an experiment.

@griesemer griesemer added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Nov 28, 2018
@griesemer griesemer added this to the Unplanned milestone Nov 28, 2018
@griesemer griesemer self-assigned this Nov 28, 2018
@aclements
Copy link
Member

I was discussing this a bit with @rsc and the thought we had was that since NoPos indicates (usually) that you don't know the position of the token, then the printer should also think of that token as consuming no space. Hence, the printer simply shouldn't update its notion of where it is in the output file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

2 participants