<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Jan 25, 2016 at 6:52 PM Milian Wolff <<a href="mailto:mail@milianw.de">mail@milianw.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Monday, January 25, 2016 5:40:01 PM CET Manuel Klimek wrote:<br>
> On Mon, Jan 25, 2016 at 5:58 PM Milian Wolff <<a href="mailto:mail@milianw.de" target="_blank">mail@milianw.de</a>> wrote:<br>
> > On Monday, January 25, 2016 4:49:39 PM CET Manuel Klimek wrote:<br>
> > > On Mon, Jan 25, 2016 at 5:45 PM Milian Wolff via cfe-dev <<br>
> > ><br>
> > > <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
> > > > On Monday, January 25, 2016 11:25:22 AM CET Halfdan Ingvarsson wrote:<br>
> > > > > If you ignore the existence of UTF16 surrogate pairs, then the<br>
> ><br>
> > mapping<br>
> ><br>
> > > > > is quite trivial and can be done very quickly.<br>
> > > > ><br>
> > > > > E.g. Certain range blocks of UTF16 code units map to a certain<br>
> ><br>
> > number of<br>
> ><br>
> > > > > UTF8 code units:<br>
> > > > ><br>
> > > > > 0x0000 - 0x007F -> 1 code unit<br>
> > > > > 0x0080 - 0x07FF -> 2 code units<br>
> > > > > 0x0800 - 0xFFFF -> 3 code units<br>
> > > > ><br>
> > > > > This allows you to quickly walk a line of UTF16 code units and get a<br>
> > > > > corresponding UTF8 code unit location.<br>
> > > > ><br>
> > > > > The converse is to check the high-order bits of the leading UTF8<br>
> > > > > code<br>
> > > > > unit to see how many to skip over to walk across a single UTF16 code<br>
> > > ><br>
> > > > unit.<br>
> > > ><br>
> > > > Thanks for the input!<br>
> > > ><br>
> > > > The missing step then for me is an efficient way to access the<br>
> ><br>
> > contents of<br>
> ><br>
> > > > a<br>
> > > > line. With clang-c, the only way I see is a costly clang_tokenize<br>
> ><br>
> > call. Is<br>
> ><br>
> > > > there an on the C++ side of clang? I see<br>
> ><br>
> > SourceManager::getCharacterData -<br>
> ><br>
> > > > would that be the right API to use? If so, I'll whip up a patch to<br>
> > > > make<br>
> > > > this<br>
> > > > accessible via clang-c, such that we can build a somewhat efficient<br>
> > > > mapping<br>
> > > > procedure on top of that.<br>
> > ><br>
> > > Don't you already have the file as utf-8 so you can hand it into clang?<br>
> ><br>
> > Is<br>
> ><br>
> > > there a reason not to get the line out of that format?<br>
> ><br>
> > Only those files I pass in via CXUnsavedFile I have access to. All others<br>
> > are<br>
> > opened directly by clang. Considering that Clang already has access to the<br>
> > string contents of any file in the TU, that seems like the best approach<br>
> > for<br>
> > me to access it, no?<br>
> ><br>
> > From my quick glance over <a href="https://code.woboq.org/llvm/clang/include/clang/" rel="noreferrer" target="_blank">https://code.woboq.org/llvm/clang/include/clang/</a><br>
> > Basic/SourceManager.h.html#clang::SourceManager<br>
> > <<a href="https://code.woboq.org/llvm/clang/include/clang/Basic/SourceManager.h.htm" rel="noreferrer" target="_blank">https://code.woboq.org/llvm/clang/include/clang/Basic/SourceManager.h.htm</a><br>
> > l#clang::SourceManager>><br>
> > I see the following potential candidates:<br>
> >   SourceManager::getBufferData<br>
> >   SourceManager::getCharacterData<br>
> >   SourceManager::getBuffer + MemoryBuffer API<br>
> ><br>
> > Wouldn't those fill the gap? Or do you think I (and any other IDE) should<br>
> > duplicate the code to find the contents of a given CXFile inside the TU,<br>
> > based<br>
> > on either the CXUnsavedFile or an mmapped file from disk.<br>
><br>
> I'd have expected that you just read the files from disk yourself. I'd<br>
> expect that to give fewer different code paths to do the same thing, so I'd<br>
> hope it reduces complexity. But in reality I have no idea what I'm talking<br>
> about as I don't know your codebase :)  I don't think that those design<br>
> decisions can or should be made for all IDEs, so I'm not sure what other<br>
> IDEs do is really relevant.<br>
<br>
We do read the file ourselves when the user opens a file in the editor, but<br>
that is only a small fraction of those files that get parsed via<br>
clang_parseTranslationUnit2. The majority of files will be read directly from<br>
disk from clang itself. The results we obtain from traversing the AST is then<br>
cached, most notably this stores ranges that need to be highlighted if a file<br>
gets opened eventually.<br>
<br>
So that said, would you object against making any of the SourceManager::* API<br>
public via a new clang-c function? Assuming of course they do what I expect<br>
them to do, i.e. give me access to the file buffer (at a given position) that<br>
clang saw while parsing the TU? It would certainly make this task more<br>
efficient to implement for us.<br></blockquote><div><br></div><div>I'm probably still missing something: don't you only need to load the file if there's a result mentioning it and you want the user to open it?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks<br>
--<br>
Milian Wolff<br>
<a href="mailto:mail@milianw.de" target="_blank">mail@milianw.de</a><br>
<a href="http://milianw.de" rel="noreferrer" target="_blank">http://milianw.de</a><br>
</blockquote></div></div>