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

Missing source file information in parsed data #89

Open
hs-apotell opened this issue Nov 9, 2019 · 5 comments
Open

Missing source file information in parsed data #89

hs-apotell opened this issue Nov 9, 2019 · 5 comments

Comments

@hs-apotell
Copy link
Contributor

When parsing multiple files in the same context, the "Position" should include the source file context as well.

@Thomasb81
Copy link
Contributor

Thomasb81 commented Nov 9, 2019

I guess #88 and #89
are the same. If not, you should provide example, otherwise we won't understand each other.

What you complain is that the original position of the token is lost, right ?

The parser is a 2 step processing. First preprocessing is executed, during this step token are correctly annotate by filename, line / pos.
But the result of preprocessing is send to the SV parser as a std::string without those information.

In an old and closed ticket #46 (comment) I proposed that preprocessor produce line directive that allow to keep track of file and line. So the SV Parser is able to correct filename and line number in the processed token.

@Nic30
Copy link
Owner

Nic30 commented Nov 9, 2019

@hs-apotell , True. The filename is required to resolve actual position in code.
But there is another problem. The preprocessor takes the code from the files and generates new string out of them and parser itself works with this string.
The solution is to put line directives in to preprocessed string.

`line line_number "file_name" level

And then use it in parser.
It should be easy, but I did not have a time to implement it yet. I can not promisse but I will look in to it in 2 weeks as I am currently in ultimately bad situation.

@hs-apotell
Copy link
Contributor Author

I guess #88 and #89 are the same.

I consider them different. #88 is a bug (parsed values aren't propagated correctly) whereas #89 is a missing feature (nothing in the current exposed API holds the source filename).

I am planning on using this for intellisense (Ctrl+Click) functionality in my tool and both #88 and #89 are crucial to get it working correctly.

@Thomasb81
Copy link
Contributor

Patch and tests are welcome.

@Nic30
Copy link
Owner

Nic30 commented Aug 26, 2020

#134

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

No branches or pull requests

3 participants