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

Correct #line numbers #138

Open
jhoehle opened this issue Jan 31, 2019 · 1 comment
Open

Correct #line numbers #138

jhoehle opened this issue Jan 31, 2019 · 1 comment

Comments

@jhoehle
Copy link
Contributor

jhoehle commented Jan 31, 2019

When #including a file, a preprocessor must generate (at least) two #line directives. One at the beginning to indicate the name and location of the new file, and another one at the end to indicate that we are back in the original source file.

#line 1 "main file"
...
#line 1 "included_file"
...
#line N "main file"
... // The above line is important!

Alas, Céu only generates #line directives for the user-supplied source file, but not for the many definitions and environment that ceu.lua supplies, e.g. main, ceu_trace, ceu_assert etc. Thus compiler and debugger get really confused, and error messages involving __FILE__ and __LINE__ (assertions in particular) report incorrect and confusing origins.

ceu.lua embeds some of the final C code as strings. I don't know whether it would make sense to produce #line numbers matching the ceu.lua compiler source (if feasible at all) or whether to reference the C output file just being generated (which may be temporary, then it's not helpful) that will get loaded into the Arduino IDE.
Referencing "ceu.lua" might help contributors as it shows the precise origin of the code and that is certainly more helpful than any cryptic temporary file name long gone.

Alternatively, some documents on the web mention that the file could be any descriptive string. Hence Céu could output generic #line <num> "run-time" after it resumes from including the user-supplied source. It will be the job of the debugger to cope with this string. Some SW appears to use the format "<run-time>" instead.

BTW, Céu doubles the slashes at some point during output, which is wrong:

#line 1 "C:/Users/.../Documents/Céu-0.40/examples/ceu-arduino/mine.ceu"
#line 9 "C://Users//...//Documents//Céu-0.40//examples//ceu-arduino//mine.ceu"

It is true that #line is itself subject to preprocessing, thus the backslash \ must be escaped for DOS filenames. That's probably why MS invented the @ prefix for their tools, e.g.

#line 25 "C:\\Projects\\MyProject\\MyProject\\Script1"
#line 25 @"C:\Projects\MyProject\MyProject\Script1"

But that doesn't apply to the UNIX style forward slash / that Céu produces even on MS-Windows.

@jhoehle
Copy link
Contributor Author

jhoehle commented Feb 1, 2019

I believe this explains issue ceu-lang/pico-ceu#3

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

1 participant