Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
1 result
Search by author
  • Any Author
0 authors
  1. Mar 04, 2016
  3. Jul 22, 2015
  5. Jun 23, 2015
  7. Jun 22, 2015
  9. May 04, 2015
  11. May 01, 2015
  13. Apr 11, 2015
  15. Sep 10, 2014
  17. Aug 29, 2014
  19. Aug 27, 2014
  21. Jul 06, 2014
  23. Jun 08, 2014
  25. Jun 04, 2014
  27. May 21, 2014
  29. May 02, 2014
  31. Apr 23, 2014
  33. Oct 24, 2013
    • Manuel Klimek's avatar
      Use the same SourceManager for ModuleMaps and compilations. · ee0cd37f
      Manuel Klimek authored 
      This allows using virtual file mappings on the original SourceManager to
map in virtual module.map files. Without this patch, the ModuleMap
search will find a module.map file (as the FileEntry exists in the
FileManager), but will be unable to get the content from the
SourceManager (as ModuleMap previously created its own SourceManager).

Two problems needed to be fixed which this patch exposed:

1. Storing the inferred module map
When writing out a module, the ASTWriter stores the names of the files
in the main source manager; when loading the AST again, the ASTReader
errs out if such a file is found missing, unless it is overridden.
Previously CompilerInstance's compileModule method would store the
inferred module map to a temporary file; the problem with this approach
is that now that the module map is handled by the main source manager,
the ASTWriter stores the name of the temporary module map as source to
the compilation; later, when the module is loaded, the temporary file
has already been deleted, which leads to a compilation error. This patch
changes the inferred module map to instead inject a virtual file into
the source manager. This both saves some disk IO, and works with how the
ASTWriter/ASTReader handle overridden source files.

2. Changing test input in test/Modules/Inputs/*
Now that the module map file is handled by the main source manager, the
VerifyDiagnosticConsumer will not ignore diagnostics created while
parsing the module map file. The module test test/Modules/renamed.m uses
-I test/Modules/Inputs and triggers recursive loading of all module maps
in test/Modules/Inputs, some of which had conflicting names, thus
leading errors while parsing the module maps. Those diagnostics already
occur on trunk, but before this patch they would not break the test, as
they were ignored by the VerifyDiagnosticConsumer. This patch thus
changes the module maps that have been recently introduced which broke
the invariant of compatible modules maps in test/Modules/Inputs.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193314 91177308-0d34-0410-b5e6-96231b3b80d8
      ee0cd37f
  35. May 04, 2013
  37. Mar 20, 2013
  39. Feb 24, 2013
  41. Feb 01, 2013
  43. Jan 12, 2013
  45. Dec 04, 2012
  47. Nov 30, 2012
  49. Nov 16, 2012
  51. Oct 24, 2012
  53. Oct 17, 2012
  55. Jun 19, 2012
  57. Mar 27, 2012
    • Argyrios Kyrtzidis's avatar
      [preprocessor] Handle correctly inclusion directives that have macro expansions, e.g · db81d38d
      Argyrios Kyrtzidis authored 
      "#include MACRO(STUFF)".

-As an inclusion position for the included file, use the file location of the file where it
was included but *after* the macro expansions. We want the macro expansions to be considered
as before-in-translation-unit for everything in the included file.

-In the preprocessing record take into account that only inclusion directives can be encountered
as "out-of-order" (by comparing the start of the range which for inclusions is the hash location)
and use binary search if there is an extreme number of macro expansions in the include directive.

Fixes rdar://11111779

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153527 91177308-0d34-0410-b5e6-96231b3b80d8
      db81d38d
  59. Feb 20, 2012
  61. Feb 13, 2012
  63. Feb 04, 2012
  65. Jan 30, 2012
  67. Dec 31, 2011