Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4 |
|
#
834dfd23 |
| 18-Nov-2024 |
Kazu Hirata <kazu@google.com> |
[Parse] Remove ParseDiagnostic.h (#116496)
This patch removes clang/Parse/ParseDiagnostic.h because it just
forwards to clang/Basic/DiagnosticParse.h.
|
Revision tags: llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init |
|
#
280b04f6 |
| 22-Jul-2024 |
Utkarsh Saxena <usx@google.com> |
Record mainfile name in the Frontend time trace (#99866)
|
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4 |
|
#
6d688055 |
| 04-May-2023 |
David Stone <davidfromonline@gmail.com> |
[clang][Sema][NFC] Move `EnterExpressionEvaluationContext` to its own file
Sema.h is huge. This makes a small reduction to it by moving EnterExpressionEvaluationContext into a new header, since it i
[clang][Sema][NFC] Move `EnterExpressionEvaluationContext` to its own file
Sema.h is huge. This makes a small reduction to it by moving EnterExpressionEvaluationContext into a new header, since it is an independent component.
Differential Revision: https://reviews.llvm.org/D149796
show more ...
|
Revision tags: llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3 |
|
#
24ecd998 |
| 13-Feb-2023 |
Chuanqi Xu <yedeng.yd@linux.alibaba.com> |
[NFC] Set C++20 Named Modules for CodeGen in ASTContext in the early place
Previously we'll set the named modules for ASTContext in ParseAST. But this is not intuitive and we need comments to tell t
[NFC] Set C++20 Named Modules for CodeGen in ASTContext in the early place
Previously we'll set the named modules for ASTContext in ParseAST. But this is not intuitive and we need comments to tell the intuition. This patch moves the code the right the place, where the corrresponding module is first created/loaded. Now it is more intuitive and we can use the value in the earlier places.
show more ...
|
Revision tags: llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1 |
|
#
b76da14b |
| 19-Sep-2022 |
Chuanqi Xu <yedeng.yd@linux.alibaba.com> |
[C++] [Modules] Generate the initializer for modules if we compile a module unit directly
Previously we lack a test which ensures that the module unit will generate initializer if it is compiled dir
[C++] [Modules] Generate the initializer for modules if we compile a module unit directly
Previously we lack a test which ensures that the module unit will generate initializer if it is compiled directly (instead of from a pcm file). Now we add the test back.
show more ...
|
#
76296217 |
| 18-Sep-2022 |
Chuanqi Xu <yedeng.yd@linux.alibaba.com> |
[Modules] Don't judge if we're compiling a module unit by LangOpts::CurrentModule.empty()
Closing https://github.com/llvm/llvm-project/issues/57778.
Previously it judge if we're compiling a module
[Modules] Don't judge if we're compiling a module unit by LangOpts::CurrentModule.empty()
Closing https://github.com/llvm/llvm-project/issues/57778.
Previously it judge if we're compiling a module unit by LangOpts::CurrentModule.empty(). But it is not true since we can specify the module name by `-fmodule-name` option for arbitrary module unit. Then this patch adjuest the judgement properly.
show more ...
|
Revision tags: llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4 |
|
#
afda39a5 |
| 15-May-2022 |
Iain Sandoe <iain@sandoe.co.uk> |
re-land [C++20][Modules] Build module static initializers per P1874R1.
The re-land fixes module map module dependencies seen on Greendragon, but not in the clang test suite.
---
Currently we only
re-land [C++20][Modules] Build module static initializers per P1874R1.
The re-land fixes module map module dependencies seen on Greendragon, but not in the clang test suite.
---
Currently we only implement this for the Itanium ABI since the correct mangling for the initializers in other ABIs is not yet known.
Intended result:
For a module interface [which includes partition interface and implementation units] (instead of the generic CXX initializer) we emit a module init that:
- wraps the contained initializations in a control variable to ensure that the inits only happen once, even if a module is imported many times by imports of the main unit.
- calls module initializers for imported modules first. Note that the order of module import is not significant, and therefore neither is the order of imported module initializers.
- We then call initializers for the Global Module Fragment (if present) - We then call initializers for the current module. - We then call initializers for the Private Module Fragment (if present)
For a module implementation unit, or a non-module TU that imports at least one module we emit a regular CXX init that:
- Calls the initializers for any imported modules first. - Then proceeds as normal with remaining inits.
For all module unit kinds we include a global constructor entry, this allows for the (in most cases unusual) possibility that a module object could be included in a final binary without a specific call to its initializer.
Implementation:
- We provide the module pointer in the AST Context so that CodeGen can act on it and its sub-modules.
- We need to account for module build lines like this: ` clang -cc1 -std=c++20 Foo.pcm -emit-obj -o Foo.o` or ` clang -cc1 -std=c++20 -xc++-module Foo.cpp -emit-obj -o Foo.o`
- in order to do this, we add to ParseAST to set the module pointer in the ASTContext, once we establish that this is a module build and we know the module pointer. To be able to do this, we make the query for current module public in Sema.
- In CodeGen, we determine if the current build requires a CXX20-style module init and, if so, we defer any module initializers during the "Eagerly Emitted" phase.
- We then walk the module initializers at the end of the TU but before emitting deferred inits (which adds any hidden and static ones, fixing https://github.com/llvm/llvm-project/issues/51873 ).
- We then proceed to emit the deferred inits and continue to emit the CXX init function.
Differential Revision: https://reviews.llvm.org/D126189
show more ...
|
#
b19d3ee7 |
| 11-Jul-2022 |
Iain Sandoe <iain@sandoe.co.uk> |
Revert "[C++20][Modules] Build module static initializers per P1874R1."
This reverts commit ac507102d258b6fc0cb57eb60c9dfabd57ff562f.
reverting while we figuere out why one of the green dragon lldb
Revert "[C++20][Modules] Build module static initializers per P1874R1."
This reverts commit ac507102d258b6fc0cb57eb60c9dfabd57ff562f.
reverting while we figuere out why one of the green dragon lldb test fails.
show more ...
|
#
ac507102 |
| 15-May-2022 |
Iain Sandoe <iain@sandoe.co.uk> |
[C++20][Modules] Build module static initializers per P1874R1.
Currently we only implement this for the Itanium ABI since the correct mangling for the initializers in other ABIs is not yet known.
I
[C++20][Modules] Build module static initializers per P1874R1.
Currently we only implement this for the Itanium ABI since the correct mangling for the initializers in other ABIs is not yet known.
Intended result:
For a module interface [which includes partition interface and implementation units] (instead of the generic CXX initializer) we emit a module init that:
- wraps the contained initializations in a control variable to ensure that the inits only happen once, even if a module is imported many times by imports of the main unit.
- calls module initializers for imported modules first. Note that the order of module import is not significant, and therefore neither is the order of imported module initializers.
- We then call initializers for the Global Module Fragment (if present) - We then call initializers for the current module. - We then call initializers for the Private Module Fragment (if present)
For a module implementation unit, or a non-module TU that imports at least one module we emit a regular CXX init that:
- Calls the initializers for any imported modules first. - Then proceeds as normal with remaining inits.
For all module unit kinds we include a global constructor entry, this allows for the (in most cases unusual) possibility that a module object could be included in a final binary without a specific call to its initializer.
Implementation:
- We provide the module pointer in the AST Context so that CodeGen can act on it and its sub-modules.
- We need to account for module build lines like this: ` clang -cc1 -std=c++20 Foo.pcm -emit-obj -o Foo.o` or ` clang -cc1 -std=c++20 -xc++-module Foo.cpp -emit-obj -o Foo.o`
- in order to do this, we add to ParseAST to set the module pointer in the ASTContext, once we establish that this is a module build and we know the module pointer. To be able to do this, we make the query for current module public in Sema.
- In CodeGen, we determine if the current build requires a CXX20-style module init and, if so, we defer any module initializers during the "Eagerly Emitted" phase.
- We then walk the module initializers at the end of the TU but before emitting deferred inits (which adds any hidden and static ones, fixing https://github.com/llvm/llvm-project/issues/51873 ).
- We then proceed to emit the deferred inits and continue to emit the CXX init function.
Differential Revision: https://reviews.llvm.org/D126189
show more ...
|
Revision tags: llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3 |
|
#
1c55f05c |
| 08-Mar-2022 |
Aaron Ballman <aaron@aaronballman.com> |
Properly diagnose constant evaluation issues at TU scope
We were not creating an evaluation context for the TU scope, so we never popped an evaluation context for it. Popping the evaluation context
Properly diagnose constant evaluation issues at TU scope
We were not creating an evaluation context for the TU scope, so we never popped an evaluation context for it. Popping the evaluation context triggers a number of diagnostics, including warnings about immediate invocations that we were previously missing.
Note: I think we have an additional issue that we should solve, but not as part of this patch. I don't think Clang is properly modeling static initialization as happening before constant expression evaluation. I think structure members members are zero initialized per http://eel.is/c++draft/basic.start.static#1, https://eel.is/c++draft/basic.start.static#2.sentence-2, and http://eel.is/c++draft/dcl.init#general-6.2 and the new test case actually should be accepted. However, it's also worth noting that other compilers behave the way this patch makes Clang behave: https://godbolt.org/z/T7noqhdPr
show more ...
|
Revision tags: llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2 |
|
#
ab28488e |
| 11-Feb-2021 |
Iain Sandoe <iain@sandoe.co.uk> |
[C++20][Modules][1/8] Track valid import state.
In C++20 modules imports must be together and at the start of the module. Rather than growing more ad-hoc flags to test state, this keeps track of the
[C++20][Modules][1/8] Track valid import state.
In C++20 modules imports must be together and at the start of the module. Rather than growing more ad-hoc flags to test state, this keeps track of the phase of of a valid module TU (first decl, global module frag, module, private module frag). If the phasing is broken (with some diagnostic) the pattern does not conform to a valid C++20 module, and we set the state accordingly.
We can thus issue diagnostics when imports appear in the wrong places and decouple the C++20 modules state from other module variants (modules-ts and clang modules). Additionally, we attempt to diagnose wrong imports before trying to find the module where possible (the latter will generally emit an unhelpful diagnostic about the module not being available).
Although this generally simplifies the handling of C++20 module import diagnostics, the motivation was that, in particular, it allows detecting invalid imports like:
import module A;
int some_decl();
import module B;
where being in a module purview is insufficient to identify them.
Differential Revision: https://reviews.llvm.org/D118893
show more ...
|
#
67387924 |
| 20-Feb-2022 |
Iain Sandoe <iain@sandoe.co.uk> |
Revert "[C++20][Modules][1/8] Track valid import state."
This reverts commit 8a3f9a584ad43369cf6a034dc875ebfca76d9033.
need to investigate build failures that do not show on CI or local testing.
|
#
8a3f9a58 |
| 11-Feb-2021 |
Iain Sandoe <iain@sandoe.co.uk> |
[C++20][Modules][1/8] Track valid import state.
In C++20 modules imports must be together and at the start of the module. Rather than growing more ad-hoc flags to test state, this keeps track of the
[C++20][Modules][1/8] Track valid import state.
In C++20 modules imports must be together and at the start of the module. Rather than growing more ad-hoc flags to test state, this keeps track of the phase of of a valid module TU (first decl, global module frag, module, private module frag). If the phasing is broken (with some diagnostic) the pattern does not conform to a valid C++20 module, and we set the state accordingly.
We can thus issue diagnostics when imports appear in the wrong places and decouple the C++20 modules state from other module variants (modules-ts and clang modules). Additionally, we attempt to diagnose wrong imports before trying to find the module where possible (the latter will generally emit an unhelpful diagnostic about the module not being available).
Although this generally simplifies the handling of C++20 module import diagnostics, the motivation was that, in particular, it allows detecting invalid imports like:
import module A;
int some_decl();
import module B;
where being in a module purview is insufficient to identify them.
Differential Revision: https://reviews.llvm.org/D118893
show more ...
|
Revision tags: llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3 |
|
#
df494f75 |
| 11-Dec-2019 |
Russell Gallop <russell.gallop@sony.com> |
[Support] Add TimeTraceScope constructor without detail arg
This simplifies code where no extra details are required Also don't write out detail when it is empty.
Differential Revision: https://rev
[Support] Add TimeTraceScope constructor without detail arg
This simplifies code where no extra details are required Also don't write out detail when it is empty.
Differential Revision: https://reviews.llvm.org/D71347
show more ...
|
Revision tags: llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1 |
|
#
d880de2d |
| 30-Mar-2019 |
Anton Afanasyev <anton.a.afanasyev@gmail.com> |
Adds `-ftime-trace` option to clang that produces Chrome `chrome://tracing` compatible JSON profiling output dumps.
This change adds hierarchical "time trace" profiling blocks that can be visualized
Adds `-ftime-trace` option to clang that produces Chrome `chrome://tracing` compatible JSON profiling output dumps.
This change adds hierarchical "time trace" profiling blocks that can be visualized in Chrome, in a "flame chart" style. Each profiling block can have a "detail" string that for example indicates the file being processed, template name being instantiated, function being optimized etc.
This is taken from GitHub PR: https://github.com/aras-p/llvm-project-20170507/pull/2
Patch by Aras Pranckevičius.
Differential Revision: https://reviews.llvm.org/D58675
llvm-svn: 357340
show more ...
|
Revision tags: llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
#
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <chandlerc@gmail.com> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository.
llvm-svn: 351636
show more ...
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0 |
|
#
58df1aff |
| 11-Sep-2018 |
Mike Rice <michael.p.rice@intel.com> |
[clang-cl, PCH] Support for /Yc and /Yu without filename and #pragma hdrstop
With clang-cl, when the user specifies /Yc or /Yu without a filename the compiler uses a #pragma hdrstop in the main sour
[clang-cl, PCH] Support for /Yc and /Yu without filename and #pragma hdrstop
With clang-cl, when the user specifies /Yc or /Yu without a filename the compiler uses a #pragma hdrstop in the main source file to determine the end of the PCH. If a header is specified with /Yc or /Yu #pragma hdrstop has no effect.
The optional #pragma hdrstop filename argument is not yet supported.
Differential Revision: https://reviews.llvm.org/D51391
llvm-svn: 341963
show more ...
|
Revision tags: llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2 |
|
#
da4c67f0 |
| 14-Aug-2018 |
Kevin P. Neal <kevin.neal@sas.com> |
Revert test commit
llvm-svn: 339691
|
#
51f6e7ef |
| 14-Aug-2018 |
Kevin P. Neal <kevin.neal@sas.com> |
Test commit
llvm-svn: 339690
|
Revision tags: llvmorg-7.0.0-rc1 |
|
#
6907ce2f |
| 30-Jul-2018 |
Fangrui Song <maskray@google.com> |
Remove trailing space
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h}
llvm-svn: 338291
|
#
76675de1 |
| 05-Jul-2018 |
Erich Keane <erich.keane@intel.com> |
[clang-cl, PCH] Implement support for MS-style PCH through headers
Implement support for MS-style PCH through headers.
This enables support for /Yc and /Yu where the through header is either on the
[clang-cl, PCH] Implement support for MS-style PCH through headers
Implement support for MS-style PCH through headers.
This enables support for /Yc and /Yu where the through header is either on the command line or included in the source. It replaces the current support the requires the header also be specified with /FI.
This change adds a -cc1 option -pch-through-header that is used to either start or stop compilation during PCH create or use.
When creating a PCH, the compilation ends after compilation of the through header.
When using a PCH, tokens are skipped until after the through header is seen.
Patch By: mikerice Differential Revision: https://reviews.llvm.org/D46652
llvm-svn: 336379
show more ...
|
Revision tags: llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3 |
|
#
207e7b1f |
| 10-Feb-2018 |
Gabor Horvath <xazax.hun@gmail.com> |
[Templight] Template Instantiation Observer
This patch adds a base-class called TemplateInstantiationObserver which gets notified whenever a template instantiation is entered or exited during semant
[Templight] Template Instantiation Observer
This patch adds a base-class called TemplateInstantiationObserver which gets notified whenever a template instantiation is entered or exited during semantic analysis. This is a base class used to implement the template profiling and debugging tool called Templight (https://github.com/mikael-s-persson/templight).
The patch also makes a few more changes:
* ActiveTemplateInstantiation class is moved out of the Sema class (so it can be used with inclusion of Sema.h). * CreateFrontendAction function in front-end utilities is given external linkage (not longer a hidden static function). * TemplateInstObserverChain data member added to Sema class to hold the list of template-inst observers. * Notifications to the template-inst observer are added at the key places where templates are instantiated.
Patch by: Abel Sinkovics!
Differential Revision: https://reviews.llvm.org/D5767
llvm-svn: 324808
show more ...
|
Revision tags: llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2, llvmorg-4.0.1-rc1, llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1, llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1 |
|
#
bbcc9f04 |
| 26-Aug-2016 |
Richard Smith <richard-llvm@metafoo.co.uk> |
C++ Modules TS: add frontend support for building pcm files from module interface files. At the moment, all declarations (and no macros) are exported, and 'export' declarations are not supported yet.
C++ Modules TS: add frontend support for building pcm files from module interface files. At the moment, all declarations (and no macros) are exported, and 'export' declarations are not supported yet.
llvm-svn: 279794
show more ...
|
Revision tags: llvmorg-3.9.0, llvmorg-3.9.0-rc3 |
|
#
964cc53d |
| 19-Aug-2016 |
Richard Smith <richard-llvm@metafoo.co.uk> |
C++ Modules TS: support parsing the 'module' declaration (including extensions from p0273r0 approved by EWG). We'll eventually need to handle this from the lexer as well, in order to disallow preproc
C++ Modules TS: support parsing the 'module' declaration (including extensions from p0273r0 approved by EWG). We'll eventually need to handle this from the lexer as well, in order to disallow preprocessor directives preceding the module declaration and to support macro import.
llvm-svn: 279196
show more ...
|
Revision tags: llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1, llvmorg-3.8.1, llvmorg-3.8.1-rc1 |
|
#
5c716175 |
| 13-May-2016 |
Yaron Keren <yaron.keren@gmail.com> |
Prune four superfluous ExternalSemaSource.h includes and one forward declaration in Sema.h where ExternalSemaSource.h was already included due to ExternalSemaSource:: member uses.
llvm-svn: 269423
|