| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[modules] Merge ObjC interface ivars with anonymous types. Without the fix ivars with anonymous types can trigger errors like > error: 'TestClass::structIvar' from module 'Target' is not present in definition of 'TestClass' provided earlier > [...] > note: declaration of 'structIvar' does not match It happens because types of ivars from different modules are considered to be different. And it is caused by not merging anonymous TagDecl from different modules. To fix that I've changed serialization::needsAnonymousDeclarationNumber to handle anonymous TagDecl inside ObjCInterfaceDecl. But that's not sufficient as C code inside ObjCInterfaceDecl doesn't use interface decl as a decl context but switches to its parent (TranslationUnit in most cases). I'm changing that to make ObjCContainerDecl the lexical decl context but keeping the semantic decl context intact. Test "check-dup-decls-inside-objc.m" doesn't reflect a change in functionality but captures the existing behavior to prevent regressions. rdar://85563013 Differential Revision: https://reviews.llvm.org/D118525 | 4 年前 | |
[OPENMP 5.0]Add initial support for 'allocate' directive. Added parsing/sema analysis/serialization/deserialization support for 'allocate' directive. llvm-svn: 355614 | 7 年前 | |
[clang] Require strict matches for defines for PCH in GCC style directories When clang includes a PCH, it tolerates some amount of differences between the defines used when creating and when including the PCH - this seems to be intentionally allowed in c379c072405f39bca1d3552408fc0427328e8b6d (and later extended in b63687519610a73dd565be1fec28332211b4df5b). When using a PCH (or when picking a PCH out of a directory containing multiple candidates) Clang used to accept the header if there were defines on the command line when creating the PCH that are missing when using the PCH, or vice versa, defines only set when using the PCH. The only cases where Clang explicitly rejected the use of a PCH is if there was an explicit conflict between the options, e.g. -DFOO=1 vs -DFOO=2, or -DFOO vs -UFOO. The latter commit added a FIXME that we really should check whether mismatched defines actually were used somewhere in the PCH, so that the define would affect the outcome. This FIXME has stood unaddressed since 2012. This differs from GCC, which rejects PCH files if the defines differ at all. When explicitly including a single PCH file, the relaxed policy of allowing minor differences is harmless for correct use cases (but may fail to diagnose mismtaches), and potentially allow using PCHs in wider cases (where the user intentionally know that the differences in defines are harmless for the PCH). However, for GCC style PCH directories, with a directory containing multiple PCH variants and the compiler should pick the correct match out of them, Clang's relaxed logic was problematic. The directory could contain two otherwise identical PCHs, but one built with -DFOO and one without. When attempting to include a PCH and iterating over the candidates in the directory, Clang would essentially pick the first one out of the two, even if there existed a better, exact match in the directory. Keep the relaxed checking when specificlly including one named PCH file, but require strict matches when trying to pick the right candidate out of a GCC style directory with alternatives. This fixes https://github.com/lhmouse/mcfgthread/issues/63. Differential Revision: https://reviews.llvm.org/D126676 (cherry picked from commit c843c921a1a385bb805b2338d980436c94f83f19) | 3 年前 | |
[C++20] [Modules] Disable preferred_name when writing a C++20 Module interface Currently, the use of preferred_name would block implementing std modules in libcxx. See https://github.com/llvm/llvm-project/issues/56490 for example. The problem is pretty hard and it looks like we couldn't solve it in a short time. So we sent this patch as a workaround to avoid blocking us to modularize STL. This is intended to be fixed properly in the future. Reviewed By: erichkeane, aaron.ballman, tahonermann Differential Revision: https://reviews.llvm.org/D130331 | 3 年前 | |
[clang] Remove unused forward declarations (NFC) | 4 年前 | |
[FPEnv] Allow CompoundStmt to keep FP options This is a recommit of b822efc7404bf09ccfdc1ab7657475026966c3b2, reverted in dc34d8df4c48b3a8f474360970cae8a58e6c84f0. The commit caused fails because the test ast-print-fp-pragmas.c did not specify particular target, and it failed on targets which do not support constrained intrinsics. The original commit message is below. AST does not have special nodes for pragmas. Instead a pragma modifies some state variables of Sema, which in turn results in modified attributes of AST nodes. This technique applies to floating point operations as well. Every AST node that can depend on FP options keeps current set of them. This technique works well for options like exception behavior or fast math options. They represent instructions to the compiler how to modify code generation for the affected nodes. However treatment of FP control modes has problems with this technique. Modifying FP control mode (like rounding direction) usually requires operations on hardware, like writing to control registers. It must be done prior to the first operation that depends on the control mode. In particular, such operations are required for implementation of pragma STDC FENV_ROUND, compiler should set up necessary rounding direction at the beginning of compound statement where the pragma occurs. As there is no representation for pragmas in AST, the code generation becomes a complicated task in this case. To solve this issue FP options are kept inside CompoundStmt. Unlike to FP options in expressions, these does not affect any operation on FP values, but only inform the codegen about the FP options that act in the body of the statement. As all pragmas that modify FP environment may occurs only at the start of compound statement or at global level, such solution works for all relevant pragmas. The options are kept as a difference from the options in the enclosing compound statement or default options, it helps codegen to set only changed control modes. Differential Revision: https://reviews.llvm.org/D123952 | 3 年前 | |
[C++20] [Modules] Disable preferred_name when writing a C++20 Module interface Currently, the use of preferred_name would block implementing std modules in libcxx. See https://github.com/llvm/llvm-project/issues/56490 for example. The problem is pretty hard and it looks like we couldn't solve it in a short time. So we sent this patch as a workaround to avoid blocking us to modularize STL. This is intended to be fixed properly in the future. Reviewed By: erichkeane, aaron.ballman, tahonermann Differential Revision: https://reviews.llvm.org/D130331 | 3 年前 | |
[NFC] Start saving InstantiatedFromDecl in non-template functions In cases where a non-template function is defined inside a function template, we don't have information about the original uninstantiated version. In the case of concepts instantiation, we will need the ability to get back to the original template. This patch splits a piece of the deferred concepts instantaition patch off to accomplish the storage of this, with minor runtime overhead, and zero additional storage. | 3 年前 | |
[FPEnv] Allow CompoundStmt to keep FP options This is a recommit of b822efc7404bf09ccfdc1ab7657475026966c3b2, reverted in dc34d8df4c48b3a8f474360970cae8a58e6c84f0. The commit caused fails because the test ast-print-fp-pragmas.c did not specify particular target, and it failed on targets which do not support constrained intrinsics. The original commit message is below. AST does not have special nodes for pragmas. Instead a pragma modifies some state variables of Sema, which in turn results in modified attributes of AST nodes. This technique applies to floating point operations as well. Every AST node that can depend on FP options keeps current set of them. This technique works well for options like exception behavior or fast math options. They represent instructions to the compiler how to modify code generation for the affected nodes. However treatment of FP control modes has problems with this technique. Modifying FP control mode (like rounding direction) usually requires operations on hardware, like writing to control registers. It must be done prior to the first operation that depends on the control mode. In particular, such operations are required for implementation of pragma STDC FENV_ROUND, compiler should set up necessary rounding direction at the beginning of compound statement where the pragma occurs. As there is no representation for pragmas in AST, the code generation becomes a complicated task in this case. To solve this issue FP options are kept inside CompoundStmt. Unlike to FP options in expressions, these does not affect any operation on FP values, but only inform the codegen about the FP options that act in the body of the statement. As all pragmas that modify FP environment may occurs only at the start of compound statement or at global level, such solution works for all relevant pragmas. The options are kept as a difference from the options in the enclosing compound statement or default options, it helps codegen to set only changed control modes. Differential Revision: https://reviews.llvm.org/D123952 | 3 年前 | |
[openmp] Base of tablegen generated OpenMP common declaration Summary: As discussed previously when landing patch for OpenMP in Flang, the idea is to share common part of the OpenMP declaration between the different Frontend. While doing this it was thought that moving to tablegen instead of Macros will also give a cleaner and more powerful way of generating these declaration. This first part of a future series of patches is setting up the base .td file for DirectiveLanguage as well as the OpenMP version of it. The base file is meant to be used by other directive language such as OpenACC. In this first patch, the Directive and Clause enums are generated with tablegen instead of the macros on OMPConstants.h. The next pacth will extend this to other enum and move the Flang frontend to use it. Reviewers: jdoerfert, DavidTruby, fghanim, ABataev, jdenny, hfinkel, jhuber6, kiranchandramohan, kiranktp Reviewed By: jdoerfert, jdenny Subscribers: arphaman, martong, cfe-commits, mgorny, yaxunl, hiraditya, guansong, jfb, sstefan1, aaron.ballman, llvm-commits Tags: #llvm, #openmp, #clang Differential Revision: https://reviews.llvm.org/D81736 | 5 年前 | |
[clang][modules] NFC: Propagate import SourceLocation into HeaderSearch::lookupModule This patch propagates the import SourceLocation into HeaderSearch::lookupModule. This enables remarks on search path usage (implemented in D102923) to point to the source code that initiated header search. Reviewed By: dexonsmith Differential Revision: https://reviews.llvm.org/D111557 | 4 年前 | |
[Clang] Use std::move in GlobalModuleIndex::readIndex. NFC BitstreamCursors are heavy-weight objects that should not be passed by value. Differential Revision: https://reviews.llvm.org/D123436 | 4 年前 | |
Revert "[modules] Do not cache invalid state for modules that we attempted to load." As per comment on https://reviews.llvm.org/D72860, it is suggested to revert this change in the meantime, since it has introduced regression. This reverts commit 83f4c3af021cd5322ea10fd1c4e839874c1dae49. | 6 年前 | |
clang/Modules: Move Serialization/Module.{h,cpp} to ModuleFile, NFC Remove some cognitive load by renaming clang/Serialization/Module.h to clang/Serialization/ModuleFile.h, since it declares the ModuleFile class. This also makes editing a bit easier, since the basename of the file no long conflicts with clang/Basic/Module.h, which declares the Module class. Also move lib/Serialization/Module.cpp to lib/Serialization/ModuleFile.cpp. | 6 年前 | |
[modules] Use HashBuilder and MD5 for the module hash. Per the comments, hash_code values "are not stable to save or persist", so are unsuitable for the module hash, which must persist across compilations for the implicit module hashes to match. Note that in practice, today, hash_code are stable. But this is an implementation detail, with a clear FIXME indicating we should switch to a per-execution seed. The stability of MD5 also allows modules cross-compilation use-cases. The size_t underlying storage for hash_code varying across platforms could cause mismatching hashes when cross-compiling from a 64bit target to a 32bit target. Note that native endianness is still used for the hash computation. So hashes will differ between platforms of different endianness. Reviewed By: jansvoboda11 Differential Revision: https://reviews.llvm.org/D102943 | 4 年前 | |
unique_ptrify the ModuleManager's VisitState linked list | 4 年前 | |
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 | 7 年前 | |
[Clang] Migrate llvm::make_unique to std::make_unique Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368942 | 6 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 4 年前 | ||
| 7 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 7 年前 | ||
| 6 年前 |