On Tue, Sep 7, 2010 at 4:04 AM, Dave Abrahams <dave@boostpro.com> wrote:
On Sun, Sep 5, 2010 at 12:35 PM, Doug Gregor <doug.gregor@gmail.com> wrote:
On Fri, Sep 3, 2010 at 3:57 PM, Dave Abrahams <dave@boostpro.com> wrote:
On Fri, Sep 3, 2010 at 6:22 PM, Florian Goujeon <florian.goujeon@42ndart.org> wrote:
All competition is stimulating. It's beneficial for everyone. All competitors are different from each other and aim to bring a surplus value. As I said, Scalpel brings high homogeneity with Boost. It has its own unique design and I also plan to endow it with round-trip engineering capabilities.
One area that scalpel could conceivably find a niche, depending on how you do it, would be in analyzing source code without seeing the full translation unit (as you might for syntax-coloring purposes). Since CLANG is really built to be a compiler, I don't think it can do that.
Clang does syntax coloring [*], although it does so with knowledge of the full translation unit.
And you know I know that ;-)
:)
Of course I realize you can't always get a correct analysis if you don't see the whole TU, but especially if you're willing to do nondeterministic parsing/backtracking, you could very easily do a really good job.
Perhaps, although I completely disagree with the "very easily" bit. C++ is a ridiculously ambiguous language.
Perhaps I overstated the case a *wee little* bit ;-)
Note that a compiler could implement these same techniques along its recovery path to both improve diagnostics and improve support for syntax coloring.
Now it's my turn to be a little skeptical. I can't imagine a compiler would ever try to do error recovery by throwing out all the information from #include files you had already processed.
Heck no! But in the absence of information (e.g., an #include couldn't be found, or an identifier is horribly mis-typed), such approaches could drastically improve recovery. - Doug