> To clarify: it's only used in > http://mxr.mozilla.org/mozilla-central/source/config/Preprocessor.py#132, > which is "a very primitive line based preprocessor, for times when > using a C preprocessor isn't an option." > > Even better: Benjamin tells me the "atline" option isn't set in the > browser!
I looked into this a few months ago because I was interested in getting proper line numbers for errors in chrome code. When I enabled the @line stuff in the browser, it caused crashes on startup. The problem didn't seem to be specific to the browser code in question; I think this feature is just broken. There's one extremely simple test for @line in the test suite. Aside from that, I can't imagine anyone can be using it. Boris told me that someone tried to enable @line for browser code a while ago. However, there's an existing feature where errors in the error console have hyperlinks to the error location, and for chrome code they link directly to the preprocessed output that's packaged in the Firefox omnijar. So if we enabled @line, we'd get the right line numbers for the original source code but the wrong ones for the omnijar versions, which would break the hyperlinks. That's why @line was disabled. I suspect that source maps would have the same problem as @line did, so it probably isn't worth the trouble of fixing the preprocessor to generate them. Unless somebody can think of a solution for the hyperlinks. -Bill _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
