<div>Ok, that would be a miracle.</div><div>š</div><div>As I understand, unfortunately getting rid of proper source locations causes big problems, yet it's currently hard for me to find some small samples on which everything crashes. I mean, it would be great to reduce the crash code dramatically, for now the examples of misbehavior are huge.š</div><div>š</div><div>I think a good understanding of interactions between SourceManager, Lexer and Parser is needed now because it's somewhere in between their communication, so to say, which turns to be broken after the patch.</div><div>I see a possibility in trying to save proper SourceLocations, yet I'm not sure it will be such an easy feature.š</div><div>š</div><div>I wonder if I can find some person who deeply understands the concept of SourceLocations so that it's possible to discuss the underlying problems?</div><div>Guys, I need your piece of advice :|</div><div>š</div><div>02.06.2016, 12:31, "Yaron Keren" <yaron.keren@gmail.com>:</div><blockquote type="cite"><div><div>Hi,</div><div>š</div><div>After your patch, you can run all clang regresion tests with "ninja check-clang".</div><div>Passing these would be a good start.</div><div>š</div><div>Yaron</div><div>š</div></div><div><br /><div><div><span>2016-06-02 11</span>:59 GMT+03:00 áÎÄÒÅÊ óÅÒÅÂÒÏ <span><<a href="mailto:andy.silv@yandex.ru" target="_blank">andy.silv@yandex.ru</a>></span>:</div><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>Hi,</div><div>š</div><div>Yep, I have noticed several problems with the patch after I have sent it, it's my bad, really: first was with variadic macos, second there was an erroneous ## processing, and also now I'm experiencing some problems with compiling Boost 1.61.š</div><div>Currently I put a gap for the first problem, so that variadics are just not cached and so expanded in a standard way.</div><div>The second I guess was fixed, now I'm struggling with the third one.</div><div>š</div><div><blockquote type="cite"><p>However, I am unable to get your patch to work at all. It seems to totallyš<br />garble the macro expansion, even on simple expansions. And the test-suiteš<br />produces over 200 unexpected fails.</p></blockquote></div><div>That's interesting. Simple samples should definitely work fine (in case there were no variadics). You can share pieces that cause bad behavior, I will try to understand whats wrong with them (probably, it's about that errors with ##).</div><div>Unexpeccted failures I guess are fine since llvm uses Lit to check the test results, and this checking consists of pattern matching the output with the one that is expected. Since I have removed SourceLocation information, the output definitely varies from the expected output that uses them. But I will also look at it in case something not connected with locations also breaks the tests.š</div><div><blockquote type="cite"><p><br />and I see lots of errors relating to supposed redefinitions of macros, whenš<br />they aren't.</p></blockquote></div><div>Can you please attach some code that can reproduce redefinition problems? I hoped I have found all the cases where it happens, however, I could miss something.š</div><div>Thanks a lot for the feedback.š</div><div>š</div><div>02.06.2016, 10:45, "Andy Gibbs" <<a href="mailto:andyg1001@hotmail.co.uk" target="_blank">andyg1001@hotmail.co.uk</a>>:</div><div><div><blockquote type="cite"><p>On Mon, May 16, 2016 at 10:46 AM áÎÄÒÅÊ óÅÒÅÂÒÏ wrote:<br /><br /></p><blockquote>šSo, I have implemented a prototype. For anyone interested, I attach the<br />špatch (I used clang release 38 from github as startup code).<br /><br />šThe prototype consumes 40% less time on preprocessing all boost headers<br />šthan original clang (780 seconds vs 1330). On real-world source code<br />špatched clang seems to be usually faster than original.<br /><br />šThe big problem with it is that it currently doesn't generate proper<br />šsource locations for expanded tokens. It doesn't affect the final code,<br />šbut of course it makes diagnostics hard in case of errors. On the other<br />šhand, this situation is similar with inline functions debugging: without<br />šspecial flag, debugging will not be that easy.<br /><br />šI have also measured timings for patched clang and clean clang, but with<br />šremoved information about expansion locations (for it could happen, that<br />šall the profit came from switching off this info). But it turned out,<br />šthat patched is still 28% faster (1100 seconds vs 780 seconds).<br /><br />šI think, it may be useful probably to have some flag in clang that allows<br />šfast preprocessing, for sometimes profit can reach up to x4 times!<br /><br />šI'm pretty sure there are some bugs now I haven't yet recognized, so any<br />šfeedback is highly appreciated.</blockquote><p><br />Hi,<br /><br />I came across your post rummaging through the mailing list and I am most <br />interested in it, not least because with minimal effort and an albeit fairly <br />pathological macro expansion, I can make clang crash with the message "Ran <br />out of source locations!" (assert inside SourceLocations.cpp). So anything <br />that will help there will be great.<br /><br />However, I am unable to get your patch to work at all. It seems to totally <br />garble the macro expansion, even on simple expansions. And the test-suite <br />produces over 200 unexpected fails. Other problems I see are that it gives <br />an error on the following define (claiming an unterminated function-like <br />macro invocation):<br /><br />#define M1(...) M2(__VA_ARGS__<br /><br />and I see lots of errors relating to supposed redefinitions of macros, when <br />they aren't.<br /><br />Is it possible that you attached an incomplete patch? Do you have a working <br />test-case that I can start with? I would be delighted to test your work <br />further.<br /><br />Cheers,<br />Andy<br /><br /></p></blockquote><div>š</div><div>š</div></div></div><div><div><div>--š</div><div>Regards,<br /> Andrei Serebro</div><div>tel. <span>+79111758381</span></div><div>š</div></div></div></blockquote></div></div></blockquote><div>š</div><div>š</div><div>--š</div><div>Regards,<br /> Andrei Serebro</div><div>tel. +79111758381</div><div>š</div>