<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in some_frame_module.map</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>5de00f3b - Stopgap fix for finding module for a file mapped in the VFS</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/clang/test/VFS/Inputs/some_frame_module.map#5de00f3b</link>
        <description>Stopgap fix for finding module for a file mapped in the VFSIf we lookup a path using its &apos;real&apos; path first, we need to ensure thatwhen we run header search we still use the VFS-mapped path or we willnot be able to find the corresponding module for the header.The real problem is that we tie the name of a file to its underlyingFileEntry, which is uniqued by inode, so we only ever get the first nameit is looked up by. This doesn&apos;t work with modules, which rely on aspecific file system structure.  I&apos;m hoping to have time to write up aproposal for fixing this more permanently soon, but as a stopgap thispatch updates the name of the file&apos;s directory if it comes from a VFSmapping.llvm-svn: 209534

            List of files:
            /llvm-project-15.0.7/clang/test/VFS/Inputs/some_frame_module.map</description>
        <pubDate>Fri, 23 May 2014 18:15:47 +0000</pubDate>
        <dc:creator>Ben Langmuir &lt;blangmuir@apple.com&gt;</dc:creator>
    </item>
</channel>
</rss>
