From 12c855180aad702bbcca06e0398d774beeafb155 Mon Sep 17 00:00:00 2001 From: robert Date: Sat, 11 Nov 2023 18:16:10 +0000 Subject: [PATCH] import of clang from LLVM-16.0.6 --- gnu/llvm/clang/CMakeLists.txt | 399 +- gnu/llvm/clang/CodeOwners.rst | 262 + gnu/llvm/clang/README.txt | 4 +- .../clang/bindings/python/clang/cindex.py | 73 +- .../bindings/python/tests/CMakeLists.txt | 5 +- .../python/tests/cindex/test_cursor.py | 58 + .../python/tests/cindex/test_diagnostics.py | 4 +- .../bindings/python/tests/cindex/test_type.py | 8 +- .../clang/cmake/caches/3-stage-base.cmake | 4 +- .../clang/cmake/caches/Apple-stage2.cmake | 15 +- gnu/llvm/clang/cmake/caches/BOLT-PGO.cmake | 11 + gnu/llvm/clang/cmake/caches/BOLT.cmake | 15 + .../clang/cmake/caches/BaremetalARM.cmake | 1 + .../cmake/caches/CrossWinToARMLinux.cmake | 160 +- .../clang/cmake/caches/Fuchsia-stage2.cmake | 72 +- gnu/llvm/clang/cmake/caches/Fuchsia.cmake | 49 +- gnu/llvm/clang/cmake/caches/HLSL.cmake | 13 + .../caches/MultiDistributionExample.cmake | 2 +- gnu/llvm/clang/cmake/caches/PGO-stage2.cmake | 3 +- gnu/llvm/clang/cmake/caches/PGO.cmake | 6 +- gnu/llvm/clang/cmake/modules/AddClang.cmake | 73 +- gnu/llvm/clang/cmake/modules/AddGRPC.cmake | 11 + gnu/llvm/clang/cmake/modules/CMakeLists.txt | 54 +- .../clang/cmake/modules/ClangConfig.cmake.in | 3 +- .../cmake/modules/ClangConfigVersion.cmake.in | 13 + .../clang/cmake/modules/ProtobufMutator.cmake | 6 +- gnu/llvm/clang/docs/APINotes.rst | 6 +- gnu/llvm/clang/docs/AddressSanitizer.rst | 23 +- .../clang/docs/AutomaticReferenceCounting.rst | 28 +- gnu/llvm/clang/docs/Block-ABI-Apple.rst | 128 +- gnu/llvm/clang/docs/CMakeLists.txt | 8 +- gnu/llvm/clang/docs/ClangFormat.rst | 250 +- .../clang/docs/ClangFormatStyleOptions.rst | 2176 ++- gnu/llvm/clang/docs/ClangFormattedStatus.rst | 3966 +++-- gnu/llvm/clang/docs/ClangLinkerWrapper.rst | 74 + gnu/llvm/clang/docs/ClangOffloadBundler.rst | 99 +- gnu/llvm/clang/docs/ClangOffloadPackager.rst | 191 + gnu/llvm/clang/docs/ClangPlugins.rst | 36 + gnu/llvm/clang/docs/ClangRepl.rst | 82 + gnu/llvm/clang/docs/ClangRepl_design.png | Bin 0 -> 72582 bytes .../clang/docs/ClangTransformerTutorial.rst | 400 + gnu/llvm/clang/docs/CodeOwners.rst | 1 + gnu/llvm/clang/docs/ControlFlowIntegrity.rst | 15 +- .../clang/docs/ControlFlowIntegrityDesign.rst | 96 +- gnu/llvm/clang/docs/DataFlowAnalysisIntro.md | 1000 ++ .../CFGExample.svg | 520 + .../CFGJoinRule.svg | 222 + .../DefinitiveInitializationLattice.svg | 114 + .../IntegerSetsFiniteLattice.svg | 403 + .../IntegerSetsInfiniteLattice.svg | 403 + .../OutputParameterIdentificationLattice.svg | 340 + .../UniquePtrLattice.svg | 114 + gnu/llvm/clang/docs/DataFlowSanitizer.rst | 39 +- .../clang/docs/DataFlowSanitizerDesign.rst | 4 +- gnu/llvm/clang/docs/DebuggingCoroutines.rst | 741 + gnu/llvm/clang/docs/ExternalClangExamples.rst | 6 +- gnu/llvm/clang/docs/HLSL/EntryFunctions.rst | 73 + gnu/llvm/clang/docs/HLSL/HLSLDocs.rst | 16 + gnu/llvm/clang/docs/HLSL/HLSLIRReference.rst | 31 + gnu/llvm/clang/docs/HLSL/HLSLSupport.rst | 249 + gnu/llvm/clang/docs/HLSL/ResourceTypes.rst | 34 + .../clang/docs/HowToSetupToolingForLLVM.rst | 56 +- gnu/llvm/clang/docs/InternalsManual.rst | 42 +- .../clang/docs/IntroductionToTheClangAST.rst | 2 +- .../clang/docs/JSONCompilationDatabase.rst | 36 +- gnu/llvm/clang/docs/LTOVisibility.rst | 15 +- gnu/llvm/clang/docs/LanguageExtensions.rst | 1171 +- gnu/llvm/clang/docs/LibASTImporter.rst | 2 +- .../clang/docs/LibASTMatchersReference.html | 744 +- .../clang/docs/LibASTMatchersTutorial.rst | 4 +- gnu/llvm/clang/docs/LibFormat.rst | 2 +- gnu/llvm/clang/docs/MatrixTypes.rst | 2 +- gnu/llvm/clang/docs/MemorySanitizer.rst | 23 +- gnu/llvm/clang/docs/MisExpect.rst | 75 + gnu/llvm/clang/docs/Modules.rst | 39 +- gnu/llvm/clang/docs/OffloadingDesign.rst | 472 + gnu/llvm/clang/docs/OpenCLSupport.rst | 175 +- gnu/llvm/clang/docs/OpenMPSupport.rst | 237 +- gnu/llvm/clang/docs/RAVFrontendAction.rst | 3 +- gnu/llvm/clang/docs/ReleaseNotes.rst | 1337 +- gnu/llvm/clang/docs/SafeStack.rst | 6 +- gnu/llvm/clang/docs/SanitizerCoverage.rst | 86 +- .../clang/docs/SanitizerSpecialCaseList.rst | 18 + .../clang/docs/StandardCPlusPlusModules.rst | 952 ++ gnu/llvm/clang/docs/ThinLTO.rst | 2 +- gnu/llvm/clang/docs/ThreadSafetyAnalysis.rst | 17 +- gnu/llvm/clang/docs/ThreadSanitizer.rst | 10 + gnu/llvm/clang/docs/Toolchain.rst | 4 +- .../clang/docs/UndefinedBehaviorSanitizer.rst | 10 +- gnu/llvm/clang/docs/UsersManual.rst | 990 +- gnu/llvm/clang/docs/analyzer/checkers.rst | 488 +- gnu/llvm/clang/docs/analyzer/conf.py | 7 +- .../clang/docs/analyzer/developer-docs.rst | 3 +- .../analyzer/developer-docs/DebugChecks.rst | 29 +- .../docs/analyzer/developer-docs/IPA.rst | 62 +- .../developer-docs/InitializerLists.rst | 10 +- .../analyzer/developer-docs/nullability.rst | 9 +- gnu/llvm/clang/docs/analyzer/user-docs.rst | 1 + .../user-docs/CrossTranslationUnit.rst | 17 +- .../user-docs/TaintAnalysisConfiguration.rst | 170 + gnu/llvm/clang/docs/conf.py | 34 +- gnu/llvm/clang/docs/doxygen.cfg.in | 2 +- gnu/llvm/clang/docs/index.rst | 12 +- .../docs/tools/clang-formatted-files.txt | 8841 ++++++++++ .../clang/docs/tools/dump_ast_matchers.py | 27 +- gnu/llvm/clang/docs/tools/dump_format_help.py | 64 + .../clang/docs/tools/dump_format_style.py | 381 +- .../docs/tools/generate_formatted_state.py | 29 +- gnu/llvm/clang/docs/tools/plurals.txt | 3 + .../examples/AnnotateFunctions/CMakeLists.txt | 2 +- .../clang/examples/Attribute/CMakeLists.txt | 2 +- gnu/llvm/clang/examples/CMakeLists.txt | 12 +- .../CallSuperAttribute/CMakeLists.txt | 2 +- .../CallSuperAttribute/CallSuperAttrInfo.cpp | 2 + .../examples/PluginsOrder/CMakeLists.txt | 11 + .../examples/PluginsOrder/PluginsOrder.cpp | 117 + .../PrintFunctionNames/CMakeLists.txt | 2 +- gnu/llvm/clang/include/clang-c/CXDiagnostic.h | 379 + gnu/llvm/clang/include/clang-c/CXFile.h | 83 + .../clang/include/clang-c/CXSourceLocation.h | 286 + .../clang/include/clang-c/Documentation.h | 64 + gnu/llvm/clang/include/clang-c/Index.h | 889 +- gnu/llvm/clang/include/clang/APINotes/Types.h | 175 +- .../include/clang/ARCMigrate/ARCMTActions.h | 2 +- gnu/llvm/clang/include/clang/AST/APValue.h | 2 +- gnu/llvm/clang/include/clang/AST/ASTConcept.h | 34 +- .../clang/include/clang/AST/ASTConsumer.h | 2 +- gnu/llvm/clang/include/clang/AST/ASTContext.h | 385 +- .../clang/include/clang/AST/ASTDiagnostic.h | 6 + gnu/llvm/clang/include/clang/AST/ASTDumper.h | 1 + gnu/llvm/clang/include/clang/AST/ASTFwd.h | 4 + .../clang/include/clang/AST/ASTImportError.h | 50 + .../clang/include/clang/AST/ASTImporter.h | 51 +- .../clang/AST/ASTImporterLookupTable.h | 5 +- .../clang/AST/ASTImporterSharedState.h | 26 +- gnu/llvm/clang/include/clang/AST/ASTLambda.h | 5 +- .../include/clang/AST/ASTNodeTraverser.h | 38 +- .../clang/AST/ASTStructuralEquivalence.h | 6 +- .../clang/include/clang/AST/ASTTypeTraits.h | 86 +- .../include/clang/AST/ASTUnresolvedSet.h | 7 +- .../include/clang/AST/AbstractBasicReader.h | 21 +- .../include/clang/AST/AbstractBasicWriter.h | 21 +- .../include/clang/AST/AbstractTypeReader.h | 7 +- .../include/clang/AST/AbstractTypeWriter.h | 4 +- gnu/llvm/clang/include/clang/AST/Attr.h | 45 +- .../clang/include/clang/AST/AttrIterator.h | 1 - .../clang/include/clang/AST/BuiltinTypes.def | 3 + .../clang/AST/CXXRecordDeclDefinitionBits.def | 3 + .../clang/include/clang/AST/CanonicalType.h | 3 +- gnu/llvm/clang/include/clang/AST/CharUnits.h | 13 + gnu/llvm/clang/include/clang/AST/Comment.h | 48 +- .../include/clang/AST/CommentCommands.td | 113 +- .../include/clang/AST/CommentHTMLTags.td | 6 +- .../clang/include/clang/AST/CommentLexer.h | 3 + .../clang/include/clang/AST/CommentParser.h | 5 +- .../clang/include/clang/AST/CommentSema.h | 19 +- .../include/clang/AST/ComparisonCategories.h | 9 +- .../include/clang/AST/ComputeDependence.h | 14 +- .../clang/AST/CurrentSourceLocExprScope.h | 13 +- gnu/llvm/clang/include/clang/AST/Decl.h | 334 +- gnu/llvm/clang/include/clang/AST/DeclBase.h | 119 +- gnu/llvm/clang/include/clang/AST/DeclCXX.h | 240 +- .../include/clang/AST/DeclContextInternals.h | 13 +- gnu/llvm/clang/include/clang/AST/DeclFriend.h | 10 +- gnu/llvm/clang/include/clang/AST/DeclObjC.h | 107 +- .../clang/include/clang/AST/DeclObjCCommon.h | 6 +- gnu/llvm/clang/include/clang/AST/DeclOpenMP.h | 12 +- .../clang/include/clang/AST/DeclTemplate.h | 235 +- .../clang/include/clang/AST/DeclarationName.h | 33 +- .../clang/include/clang/AST/DependenceFlags.h | 24 +- gnu/llvm/clang/include/clang/AST/Expr.h | 98 +- gnu/llvm/clang/include/clang/AST/ExprCXX.h | 434 +- .../clang/include/clang/AST/ExprConcepts.h | 135 +- gnu/llvm/clang/include/clang/AST/ExprObjC.h | 19 +- gnu/llvm/clang/include/clang/AST/ExprOpenMP.h | 4 +- .../include/clang/AST/ExternalASTMerger.h | 2 +- .../include/clang/AST/ExternalASTSource.h | 4 +- gnu/llvm/clang/include/clang/AST/GlobalDecl.h | 9 +- .../clang/include/clang/AST/JSONNodeDumper.h | 16 +- .../clang/include/clang/AST/LambdaCapture.h | 8 +- .../AST/LexicallyOrderedRecursiveASTVisitor.h | 6 +- .../clang/include/clang/AST/LocInfoType.h | 6 +- gnu/llvm/clang/include/clang/AST/Mangle.h | 55 +- .../clang/AST/MangleNumberingContext.h | 2 - gnu/llvm/clang/include/clang/AST/NSAPI.h | 16 +- .../include/clang/AST/NestedNameSpecifier.h | 4 +- .../include/clang/AST/NonTrivialTypeVisitor.h | 4 +- .../clang/include/clang/AST/ODRDiagsEmitter.h | 203 + gnu/llvm/clang/include/clang/AST/ODRHash.h | 14 +- gnu/llvm/clang/include/clang/AST/OSLog.h | 4 +- .../clang/include/clang/AST/OpenMPClause.h | 1579 +- .../include/clang/AST/ParentMapContext.h | 20 +- .../include/clang/AST/PrettyDeclStackTrace.h | 1 - .../clang/include/clang/AST/PrettyPrinter.h | 34 +- .../clang/include/clang/AST/PropertiesBase.td | 82 +- .../clang/include/clang/AST/QualTypeNames.h | 2 +- gnu/llvm/clang/include/clang/AST/Randstruct.h | 35 + .../clang/include/clang/AST/RawCommentList.h | 15 + .../include/clang/AST/RecursiveASTVisitor.h | 396 +- .../clang/include/clang/AST/Redeclarable.h | 3 +- gnu/llvm/clang/include/clang/AST/Stmt.h | 145 +- gnu/llvm/clang/include/clang/AST/StmtCXX.h | 14 +- gnu/llvm/clang/include/clang/AST/StmtObjC.h | 41 +- gnu/llvm/clang/include/clang/AST/StmtOpenMP.h | 1114 +- .../clang/include/clang/AST/TemplateBase.h | 54 +- .../clang/include/clang/AST/TemplateName.h | 163 +- .../clang/include/clang/AST/TextNodeDumper.h | 8 + gnu/llvm/clang/include/clang/AST/Type.h | 667 +- gnu/llvm/clang/include/clang/AST/TypeLoc.h | 208 +- .../clang/include/clang/AST/TypeOrdering.h | 1 - .../clang/include/clang/AST/TypeProperties.td | 104 +- .../clang/include/clang/AST/UnresolvedSet.h | 2 +- .../clang/ASTMatchers/ASTMatchFinder.h | 11 +- .../include/clang/ASTMatchers/ASTMatchers.h | 625 +- .../clang/ASTMatchers/ASTMatchersInternal.h | 206 +- .../clang/ASTMatchers/Dynamic/Diagnostics.h | 4 +- .../clang/ASTMatchers/Dynamic/Parser.h | 18 +- .../clang/ASTMatchers/Dynamic/Registry.h | 8 +- .../clang/ASTMatchers/Dynamic/VariantValue.h | 16 +- .../clang/Analysis/Analyses/CalledOnceCheck.h | 3 +- .../clang/Analysis/Analyses/Consumed.h | 3 +- .../clang/Analysis/Analyses/Dominators.h | 4 +- .../Analysis/Analyses/ExprMutationAnalyzer.h | 2 + .../Analysis/Analyses/PostOrderCFGView.h | 10 +- .../clang/Analysis/Analyses/ThreadSafety.h | 9 +- .../Analysis/Analyses/ThreadSafetyCommon.h | 64 +- .../clang/Analysis/Analyses/ThreadSafetyTIL.h | 28 +- .../Analysis/Analyses/ThreadSafetyTraverse.h | 5 +- .../Analysis/Analyses/ThreadSafetyUtil.h | 6 +- .../Analysis/Analyses/UnsafeBufferUsage.h | 48 + .../Analyses/UnsafeBufferUsageGadgets.def | 35 + .../clang/Analysis/AnalysisDeclContext.h | 6 +- .../clang/include/clang/Analysis/AnyCall.h | 23 +- .../clang/include/clang/Analysis/BodyFarm.h | 9 +- gnu/llvm/clang/include/clang/Analysis/CFG.h | 53 +- .../include/clang/Analysis/CloneDetection.h | 20 +- .../clang/Analysis/ConstructionContext.h | 77 +- .../Analysis/FlowSensitive/CFGMatchSwitch.h | 98 + .../FlowSensitive/ControlFlowContext.h | 67 + .../Analysis/FlowSensitive/DataflowAnalysis.h | 247 + .../FlowSensitive/DataflowAnalysisContext.h | 400 + .../FlowSensitive/DataflowEnvironment.h | 502 + .../Analysis/FlowSensitive/DataflowLattice.h | 31 + .../Analysis/FlowSensitive/DataflowValues.h | 2 +- .../Analysis/FlowSensitive/DataflowWorklist.h | 11 +- .../Analysis/FlowSensitive/DebugSupport.h | 88 + .../clang/Analysis/FlowSensitive/MapLattice.h | 143 + .../Analysis/FlowSensitive/MatchSwitch.h | 181 + .../FlowSensitive/Models/ChromiumCheckModel.h | 39 + .../Models/UncheckedOptionalAccessModel.h | 88 + .../Analysis/FlowSensitive/NoopAnalysis.h | 47 + .../Analysis/FlowSensitive/NoopLattice.h | 41 + .../clang/Analysis/FlowSensitive/Solver.h | 96 + .../Analysis/FlowSensitive/StorageLocation.h | 100 + .../clang/Analysis/FlowSensitive/Transfer.h | 45 + .../TypeErasedDataflowAnalysis.h | 166 + .../clang/Analysis/FlowSensitive/Value.h | 319 + .../FlowSensitive/WatchedLiteralsSolver.h | 37 + .../clang/include/clang/Analysis/IssueHash.h | 4 +- .../clang/Analysis/MacroExpansionContext.h | 12 +- .../include/clang/Analysis/PathDiagnostic.h | 41 +- .../include/clang/Analysis/ProgramPoint.h | 14 +- .../clang/Analysis/RetainSummaryManager.h | 22 +- .../include/clang/Analysis/SelectorExtras.h | 6 +- .../clang/include/clang/Basic/AddressSpaces.h | 3 + .../include/clang/Basic/AlignedAllocation.h | 10 +- gnu/llvm/clang/include/clang/Basic/Attr.td | 534 +- .../clang/include/clang/Basic/AttrDocs.td | 858 +- .../clang/Basic/AttrSubjectMatchRules.h | 7 +- .../include/clang/Basic/AttributeCommonInfo.h | 23 +- .../clang/include/clang/Basic/Attributes.h | 22 +- .../include/clang/Basic/BuiltinHeaders.def | 43 + .../clang/include/clang/Basic/Builtins.def | 1218 +- gnu/llvm/clang/include/clang/Basic/Builtins.h | 107 +- .../include/clang/Basic/BuiltinsAArch64.def | 333 +- .../Basic/BuiltinsAArch64NeonSVEBridge.def | 39 + .../Basic/BuiltinsAArch64NeonSVEBridge_cg.def | 39 + .../include/clang/Basic/BuiltinsAMDGPU.def | 126 +- .../clang/include/clang/Basic/BuiltinsARM.def | 245 +- .../include/clang/Basic/BuiltinsHexagon.def | 22 +- .../clang/Basic/BuiltinsHexagonDep.def | 184 + .../Basic/BuiltinsHexagonMapCustomDep.def | 196 +- .../include/clang/Basic/BuiltinsLoongArch.def | 61 + .../include/clang/Basic/BuiltinsNVPTX.def | 183 +- .../clang/include/clang/Basic/BuiltinsPPC.def | 82 +- .../include/clang/Basic/BuiltinsRISCV.def | 104 +- .../clang/Basic/BuiltinsRISCVVector.def | 21 + .../clang/include/clang/Basic/BuiltinsSVE.def | 2 + .../clang/include/clang/Basic/BuiltinsVE.def | 32 + .../include/clang/Basic/BuiltinsVEVL.gen.def | 1257 ++ .../clang/Basic/BuiltinsWebAssembly.def | 45 +- .../clang/include/clang/Basic/BuiltinsX86.def | 485 +- .../include/clang/Basic/BuiltinsX86_64.def | 43 +- .../clang/include/clang/Basic/CLWarnings.h | 26 + .../clang/include/clang/Basic/CMakeLists.txt | 3 + gnu/llvm/clang/include/clang/Basic/CharInfo.h | 62 +- .../include/clang/Basic/CodeGenOptions.h | 64 +- gnu/llvm/clang/include/clang/Basic/Cuda.h | 29 +- .../clang/Basic/CustomizableOptional.h | 280 + .../clang/include/clang/Basic/DarwinSDKInfo.h | 60 +- .../include/clang/Basic/DebugInfoOptions.h | 6 + .../clang/include/clang/Basic/DeclNodes.td | 5 +- .../clang/include/clang/Basic/Diagnostic.h | 83 +- .../clang/include/clang/Basic/Diagnostic.td | 14 +- .../clang/include/clang/Basic/DiagnosticAST.h | 2 +- .../include/clang/Basic/DiagnosticASTKinds.td | 429 +- .../include/clang/Basic/DiagnosticAnalysis.h | 2 +- .../clang/Basic/DiagnosticCategories.h | 8 + .../include/clang/Basic/DiagnosticComment.h | 2 +- .../clang/Basic/DiagnosticCommentKinds.td | 4 +- .../clang/Basic/DiagnosticCommonKinds.td | 64 +- .../include/clang/Basic/DiagnosticCrossTU.h | 2 +- .../clang/Basic/DiagnosticCrossTUKinds.td | 4 +- .../include/clang/Basic/DiagnosticDriver.h | 2 +- .../clang/Basic/DiagnosticDriverKinds.td | 358 +- .../include/clang/Basic/DiagnosticError.h | 11 +- .../include/clang/Basic/DiagnosticFrontend.h | 2 +- .../clang/include/clang/Basic/DiagnosticIDs.h | 48 +- .../clang/include/clang/Basic/DiagnosticLex.h | 2 +- .../include/clang/Basic/DiagnosticLexKinds.td | 148 +- .../include/clang/Basic/DiagnosticOptions.h | 8 +- .../include/clang/Basic/DiagnosticParse.h | 2 +- .../clang/Basic/DiagnosticParseKinds.td | 182 +- .../clang/Basic/DiagnosticRefactoring.h | 2 +- .../include/clang/Basic/DiagnosticSema.h | 2 +- .../clang/Basic/DiagnosticSerialization.h | 2 +- .../Basic/DiagnosticSerializationKinds.td | 266 +- .../include/clang/Basic/DirectoryEntry.h | 81 +- .../clang/include/clang/Basic/FPOptions.def | 9 +- .../clang/include/clang/Basic/Features.def | 13 +- .../clang/include/clang/Basic/FileEntry.h | 122 +- .../clang/include/clang/Basic/FileManager.h | 30 +- .../include/clang/Basic/FileSystemStatCache.h | 3 +- .../clang/include/clang/Basic/HLSLRuntime.h | 66 + .../clang/include/clang/Basic/HeaderInclude.h | 73 + .../include/clang/Basic/IdentifierTable.h | 80 +- .../clang/include/clang/Basic/JsonSupport.h | 24 +- gnu/llvm/clang/include/clang/Basic/LLVM.h | 6 +- gnu/llvm/clang/include/clang/Basic/Lambda.h | 2 +- .../clang/include/clang/Basic/LangOptions.h | 259 +- .../clang/include/clang/Basic/LangStandard.h | 15 +- .../include/clang/Basic/LangStandards.def | 54 +- .../include/clang/Basic/MSP430Target.def | 3 +- .../clang/include/clang/Basic/MakeSupport.h | 23 + gnu/llvm/clang/include/clang/Basic/Module.h | 127 +- .../include/clang/Basic/NoSanitizeList.h | 2 + .../clang/include/clang/Basic/ObjCRuntime.h | 7 + .../include/clang/Basic/OpenCLExtensions.def | 6 - .../clang/include/clang/Basic/OpenCLOptions.h | 9 +- .../clang/include/clang/Basic/OpenMPKinds.def | 61 + .../clang/include/clang/Basic/OpenMPKinds.h | 77 +- .../include/clang/Basic/OperatorKinds.def | 4 +- .../include/clang/Basic/OperatorPrecedence.h | 2 +- .../include/clang/Basic/PartialDiagnostic.h | 7 +- .../clang/include/clang/Basic/PragmaKinds.h | 4 +- .../clang/include/clang/Basic/ProfileList.h | 33 +- .../clang/include/clang/Basic/RISCVVTypes.def | 4 +- .../clang/include/clang/Basic/Sanitizers.def | 8 +- .../clang/include/clang/Basic/Sanitizers.h | 7 + gnu/llvm/clang/include/clang/Basic/Sarif.h | 513 + .../include/clang/Basic/SourceLocation.h | 31 +- .../clang/include/clang/Basic/SourceManager.h | 195 +- .../clang/include/clang/Basic/Specifiers.h | 69 +- gnu/llvm/clang/include/clang/Basic/Stack.h | 2 +- .../clang/include/clang/Basic/StmtNodes.td | 18 +- .../clang/include/clang/Basic/SyncScope.h | 75 +- .../include/clang/Basic/TargetBuiltins.h | 29 +- gnu/llvm/clang/include/clang/Basic/TargetID.h | 27 +- .../clang/include/clang/Basic/TargetOptions.h | 27 +- .../clang/include/clang/Basic/TokenKinds.def | 127 +- .../clang/include/clang/Basic/TokenKinds.h | 3 + .../clang/Basic/TransformTypeTraits.def | 29 + .../clang/include/clang/Basic/TypeNodes.td | 6 +- .../clang/include/clang/Basic/TypeTraits.h | 4 + .../clang/include/clang/Basic/Version.inc.in | 1 + .../clang/include/clang/Basic/arm_fp16.td | 2 +- .../clang/include/clang/Basic/arm_neon.td | 119 +- .../include/clang/Basic/arm_neon_incl.td | 1 + gnu/llvm/clang/include/clang/Basic/arm_sve.td | 245 +- .../clang/include/clang/Basic/riscv_vector.td | 1542 +- .../clang/include/clang/CodeGen/BackendUtil.h | 3 + .../include/clang/CodeGen/CGFunctionInfo.h | 20 +- .../include/clang/CodeGen/CodeGenABITypes.h | 8 - .../include/clang/CodeGen/ModuleBuilder.h | 12 +- .../ObjectFilePCHContainerOperations.h | 4 +- .../include/clang/CodeGen/SwiftCallingConv.h | 1 - .../clang/include/clang/Config/config.h.cmake | 22 +- .../clang/CrossTU/CrossTranslationUnit.h | 28 +- .../clang/DirectoryWatcher/DirectoryWatcher.h | 2 +- gnu/llvm/clang/include/clang/Driver/Action.h | 63 +- .../clang/include/clang/Driver/Compilation.h | 30 +- gnu/llvm/clang/include/clang/Driver/Distro.h | 9 +- gnu/llvm/clang/include/clang/Driver/Driver.h | 218 +- gnu/llvm/clang/include/clang/Driver/Job.h | 31 +- .../include/clang/Driver/OffloadBundler.h | 89 + gnu/llvm/clang/include/clang/Driver/Options.h | 4 +- gnu/llvm/clang/include/clang/Driver/Phases.h | 3 +- .../include/clang/Driver/SanitizerArgs.h | 24 +- gnu/llvm/clang/include/clang/Driver/Tool.h | 1 + .../clang/include/clang/Driver/ToolChain.h | 130 +- gnu/llvm/clang/include/clang/Driver/Types.def | 17 +- gnu/llvm/clang/include/clang/Driver/Types.h | 17 +- gnu/llvm/clang/include/clang/Driver/Util.h | 1 - gnu/llvm/clang/include/clang/ExtractAPI/API.h | 863 + .../include/clang/ExtractAPI/APIIgnoresList.h | 74 + .../clang/ExtractAPI/AvailabilityInfo.h | 81 + .../clang/ExtractAPI/DeclarationFragments.h | 293 + .../clang/ExtractAPI/ExtractAPIVisitor.h | 88 + .../clang/ExtractAPI/FrontendActions.h | 73 + .../ExtractAPI/Serialization/SerializerBase.h | 64 + .../Serialization/SymbolGraphSerializer.h | 173 + .../clang/include/clang/Format/.clang-format | 4 + gnu/llvm/clang/include/clang/Format/Format.h | 2964 ++-- .../include/clang/Frontend/ASTConsumers.h | 6 - .../clang/include/clang/Frontend/ASTUnit.h | 15 +- .../clang/Frontend/CommandLineSourceLoc.h | 9 +- .../include/clang/Frontend/CompilerInstance.h | 11 +- .../clang/Frontend/CompilerInvocation.h | 39 +- .../clang/Frontend/DependencyOutputOptions.h | 10 +- .../include/clang/Frontend/FrontendAction.h | 17 +- .../include/clang/Frontend/FrontendActions.h | 23 +- .../include/clang/Frontend/FrontendOptions.h | 84 +- .../clang/Frontend/MultiplexConsumer.h | 2 + .../clang/Frontend/PCHContainerOperations.h | 4 +- .../clang/Frontend/PrecompiledPreamble.h | 87 +- .../Frontend/PreprocessorOutputOptions.h | 4 + .../include/clang/Frontend/SARIFDiagnostic.h | 74 + .../clang/Frontend/SARIFDiagnosticPrinter.h | 76 + .../Frontend/SerializedDiagnosticPrinter.h | 1 - .../clang/Frontend/SerializedDiagnostics.h | 4 +- gnu/llvm/clang/include/clang/Frontend/Utils.h | 79 +- .../clang/include/clang/Index/IndexSymbol.h | 2 + .../include/clang/Index/IndexingOptions.h | 4 +- .../SerializablePathCollection.h | 7 +- .../include/clang/Interpreter/Interpreter.h | 24 +- .../clang/Lex/DependencyDirectivesScanner.h | 139 + .../clang/include/clang/Lex/DirectoryLookup.h | 17 +- gnu/llvm/clang/include/clang/Lex/HeaderMap.h | 28 +- .../clang/include/clang/Lex/HeaderSearch.h | 299 +- .../include/clang/Lex/HeaderSearchOptions.h | 27 +- gnu/llvm/clang/include/clang/Lex/Lexer.h | 98 +- .../clang/include/clang/Lex/LiteralSupport.h | 18 +- gnu/llvm/clang/include/clang/Lex/MacroInfo.h | 53 +- .../clang/include/clang/Lex/ModuleLoader.h | 5 + gnu/llvm/clang/include/clang/Lex/ModuleMap.h | 69 +- .../clang/include/clang/Lex/PPCallbacks.h | 106 +- .../include/clang/Lex/PreprocessingRecord.h | 23 +- .../clang/include/clang/Lex/Preprocessor.h | 584 +- .../include/clang/Lex/PreprocessorLexer.h | 21 +- .../include/clang/Lex/PreprocessorOptions.h | 27 +- gnu/llvm/clang/include/clang/Lex/Token.h | 14 +- gnu/llvm/clang/include/clang/Parse/Parser.h | 585 +- .../clang/Parse/RAIIObjectsForParser.h | 32 +- .../clang/Sema/AnalysisBasedWarnings.h | 2 - .../clang/include/clang/Sema/CleanupInfo.h | 4 +- .../include/clang/Sema/CodeCompleteConsumer.h | 136 +- gnu/llvm/clang/include/clang/Sema/DeclSpec.h | 136 +- .../include/clang/Sema/DelayedDiagnostic.h | 4 +- .../include/clang/Sema/ExternalSemaSource.h | 2 - .../clang/Sema/HLSLExternalSemaSource.h | 55 + .../clang/include/clang/Sema/Initialization.h | 44 +- gnu/llvm/clang/include/clang/Sema/Lookup.h | 57 +- .../clang/Sema/MultiplexExternalSemaSource.h | 17 +- gnu/llvm/clang/include/clang/Sema/Overload.h | 107 +- .../clang/include/clang/Sema/ParsedAttr.h | 169 +- .../clang/include/clang/Sema/ParsedTemplate.h | 9 +- .../clang/Sema/RISCVIntrinsicManager.h | 35 + gnu/llvm/clang/include/clang/Sema/Scope.h | 87 +- gnu/llvm/clang/include/clang/Sema/ScopeInfo.h | 61 +- .../clang/include/clang/Sema/SemaConcept.h | 17 +- .../clang/include/clang/Sema/SemaLambda.h | 5 +- gnu/llvm/clang/include/clang/Sema/Template.h | 117 +- .../include/clang/Sema/TemplateDeduction.h | 38 +- .../include/clang/Sema/TemplateInstCallback.h | 4 +- gnu/llvm/clang/include/clang/Sema/Weak.h | 39 +- .../include/clang/Serialization/ASTBitCodes.h | 53 +- .../include/clang/Serialization/ASTReader.h | 167 +- .../clang/Serialization/ASTRecordReader.h | 22 +- .../clang/Serialization/ASTRecordWriter.h | 16 +- .../include/clang/Serialization/ASTWriter.h | 82 +- .../clang/Serialization/GlobalModuleIndex.h | 2 - .../clang/Serialization/InMemoryModuleCache.h | 1 - .../include/clang/Serialization/ModuleFile.h | 24 +- .../clang/Serialization/ModuleFileExtension.h | 28 +- .../clang/Serialization/ModuleManager.h | 18 +- .../Serialization/PCHContainerOperations.h | 2 - .../Serialization/SourceLocationEncoding.h | 163 + .../clang/Serialization/TypeBitCodes.def | 6 +- .../Checkers/BuiltinCheckerRegistration.h | 8 +- .../StaticAnalyzer/Checkers/CheckerBase.td | 9 +- .../clang/StaticAnalyzer/Checkers/Checkers.td | 155 +- .../Checkers/MPIFunctionClassifier.h | 4 +- .../StaticAnalyzer/Checkers/SValExplainer.h | 39 +- .../clang/StaticAnalyzer/Checkers/Taint.h | 106 + .../clang/StaticAnalyzer/Core/Analyses.def | 8 - .../StaticAnalyzer/Core/AnalyzerOptions.def | 83 +- .../StaticAnalyzer/Core/AnalyzerOptions.h | 52 +- .../Core/BugReporter/BugReporter.h | 24 +- .../Core/BugReporter/BugReporterVisitors.h | 126 +- .../StaticAnalyzer/Core/BugReporter/BugType.h | 2 - .../clang/StaticAnalyzer/Core/Checker.h | 12 - .../StaticAnalyzer/Core/CheckerManager.h | 3 +- .../Core/PathDiagnosticConsumers.h | 1 - .../Core/PathSensitive/APSIntType.h | 4 +- .../Core/PathSensitive/BasicValueFactory.h | 27 +- .../Core/PathSensitive/CallDescription.h | 257 + .../Core/PathSensitive/CallEvent.h | 157 +- .../Core/PathSensitive/CheckerContext.h | 22 +- .../Core/PathSensitive/CheckerHelpers.h | 12 +- .../Core/PathSensitive/ConstraintManager.h | 133 +- .../Core/PathSensitive/CoreEngine.h | 16 +- .../Core/PathSensitive/DynamicType.h | 2 +- .../Core/PathSensitive/DynamicTypeInfo.h | 2 +- .../Core/PathSensitive/ExplodedGraph.h | 8 +- .../Core/PathSensitive/ExprEngine.h | 182 +- .../Core/PathSensitive/FunctionSummary.h | 7 +- .../Core/PathSensitive/LoopUnrolling.h | 1 - .../Core/PathSensitive/MemRegion.h | 78 +- .../Core/PathSensitive/ProgramState.h | 128 +- .../Core/PathSensitive/ProgramStateTrait.h | 108 +- .../PathSensitive/RangedConstraintManager.h | 112 +- .../Core/PathSensitive/SMTConstraintManager.h | 17 +- .../Core/PathSensitive/SMTConv.h | 28 +- .../Core/PathSensitive/SValBuilder.h | 117 +- .../StaticAnalyzer/Core/PathSensitive/SVals.h | 267 +- .../PathSensitive/SimpleConstraintManager.h | 21 +- .../StaticAnalyzer/Core/PathSensitive/Store.h | 19 +- .../Core/PathSensitive/SymExpr.h | 1 + .../Core/PathSensitive/SymbolManager.h | 124 +- .../Core/PathSensitive/Symbols.def | 2 + .../Frontend/AnalysisConsumer.h | 4 - .../StaticAnalyzer/Frontend/FrontendActions.h | 3 - .../StaticAnalyzer/Frontend/ModelConsumer.h | 4 +- .../clang/Support/RISCVVIntrinsicUtils.h | 526 + .../include/clang/Testing/CommandLineArgs.h | 2 + .../clang/include/clang/Testing/TestAST.h | 100 + .../include/clang/Testing/TestClangConfig.h | 2 +- .../include/clang/Tooling/ASTDiff/ASTDiff.h | 33 +- .../clang/Tooling/ASTDiff/ASTDiffInternal.h | 4 - .../include/clang/Tooling/AllTUsExecution.h | 3 +- .../clang/Tooling/CommonOptionsParser.h | 2 +- .../clang/Tooling/CompilationDatabase.h | 2 + .../include/clang/Tooling/Core/Replacement.h | 17 +- .../DependencyScanningFilesystem.h | 425 +- .../DependencyScanningService.h | 43 +- .../DependencyScanningTool.h | 152 +- .../DependencyScanningWorker.h | 75 +- .../DependencyScanning/ModuleDepCollector.h | 204 +- .../include/clang/Tooling/DiagnosticsYaml.h | 3 +- gnu/llvm/clang/include/clang/Tooling/FixIt.h | 2 +- .../clang/Tooling/Inclusions/CSymbolMap.inc | 945 ++ .../clang/Tooling/Inclusions/HeaderAnalysis.h | 46 + .../clang/Tooling/Inclusions/HeaderIncludes.h | 44 +- .../clang/Tooling/Inclusions/IncludeStyle.h | 6 +- .../Tooling/Inclusions/StandardLibrary.h | 145 + .../clang/Tooling/Inclusions/StdSymbolMap.inc | 1538 ++ .../clang/Tooling/Refactoring/ASTSelection.h | 17 +- .../clang/Tooling/Refactoring/AtomicChange.h | 8 +- .../Tooling/Refactoring/Extract/Extract.h | 18 +- .../Refactoring/Extract/SourceExtraction.h | 6 +- .../clang/Tooling/Refactoring/Lookup.h | 6 +- .../Refactoring/RecursiveSymbolVisitor.h | 6 +- .../Tooling/Refactoring/RefactoringAction.h | 6 +- .../Refactoring/RefactoringActionRule.h | 7 +- .../RefactoringActionRuleRequirements.h | 8 +- .../Refactoring/RefactoringActionRules.h | 10 +- .../RefactoringActionRulesInternal.h | 18 +- .../Tooling/Refactoring/RefactoringOption.h | 6 +- .../Refactoring/RefactoringOptionVisitor.h | 12 +- .../Tooling/Refactoring/RefactoringOptions.h | 15 +- .../Refactoring/RefactoringResultConsumer.h | 6 +- .../Refactoring/RefactoringRuleContext.h | 6 +- .../Refactoring/Rename/RenamingAction.h | 7 +- .../Tooling/Refactoring/Rename/SymbolName.h | 6 +- .../Refactoring/Rename/SymbolOccurrences.h | 8 +- .../Tooling/Refactoring/Rename/USRFinder.h | 6 +- .../Refactoring/Rename/USRFindingAction.h | 7 +- .../Tooling/Refactoring/Rename/USRLocFinder.h | 6 +- .../include/clang/Tooling/ReplacementsYaml.h | 3 +- .../clang/Tooling/StandaloneExecution.h | 3 +- .../include/clang/Tooling/Syntax/BuildTree.h | 22 +- .../include/clang/Tooling/Syntax/Mutations.h | 6 +- .../include/clang/Tooling/Syntax/Nodes.h | 7 +- .../Tooling/Syntax/TokenBufferTokenManager.h | 70 + .../clang/Tooling/Syntax/TokenManager.h | 47 + .../include/clang/Tooling/Syntax/Tokens.h | 10 +- .../clang/include/clang/Tooling/Syntax/Tree.h | 68 +- .../clang/include/clang/Tooling/Tooling.h | 16 +- .../clang/Tooling/Transformer/MatchConsumer.h | 6 +- .../clang/Tooling/Transformer/Parsing.h | 6 +- .../clang/Tooling/Transformer/RangeSelector.h | 8 +- .../clang/Tooling/Transformer/RewriteRule.h | 159 +- .../clang/Tooling/Transformer/SourceCode.h | 62 +- .../Tooling/Transformer/SourceCodeBuilders.h | 58 +- .../clang/Tooling/Transformer/Stencil.h | 32 + .../clang/Tooling/Transformer/Transformer.h | 180 +- gnu/llvm/clang/include/clang/module.modulemap | 25 +- .../lib/APINotes/APINotesYAMLCompiler.cpp | 76 +- gnu/llvm/clang/lib/ARCMigrate/ARCMT.cpp | 6 +- .../clang/lib/ARCMigrate/ARCMTActions.cpp | 4 +- gnu/llvm/clang/lib/ARCMigrate/CMakeLists.txt | 1 + gnu/llvm/clang/lib/ARCMigrate/Internals.h | 16 +- gnu/llvm/clang/lib/ARCMigrate/ObjCMT.cpp | 51 +- .../lib/ARCMigrate/TransAutoreleasePool.cpp | 5 +- .../clang/lib/ARCMigrate/TransGCAttrs.cpp | 4 +- .../ARCMigrate/TransRetainReleaseDealloc.cpp | 2 +- .../lib/ARCMigrate/TransUnbridgedCasts.cpp | 10 +- .../clang/lib/ARCMigrate/TransformActions.cpp | 2 +- gnu/llvm/clang/lib/ARCMigrate/Transforms.cpp | 10 +- gnu/llvm/clang/lib/AST/APValue.cpp | 95 +- gnu/llvm/clang/lib/AST/ASTConcept.cpp | 79 +- gnu/llvm/clang/lib/AST/ASTContext.cpp | 2985 +++- gnu/llvm/clang/lib/AST/ASTDiagnostic.cpp | 130 +- gnu/llvm/clang/lib/AST/ASTDumper.cpp | 65 +- gnu/llvm/clang/lib/AST/ASTImporter.cpp | 1421 +- .../clang/lib/AST/ASTImporterLookupTable.cpp | 21 +- .../lib/AST/ASTStructuralEquivalence.cpp | 389 +- gnu/llvm/clang/lib/AST/ASTTypeTraits.cpp | 41 +- gnu/llvm/clang/lib/AST/AttrDocTable.cpp | 27 + gnu/llvm/clang/lib/AST/AttrImpl.cpp | 82 +- gnu/llvm/clang/lib/AST/CMakeLists.txt | 10 + gnu/llvm/clang/lib/AST/CXXABI.h | 1 - gnu/llvm/clang/lib/AST/CXXInheritance.cpp | 7 +- gnu/llvm/clang/lib/AST/Comment.cpp | 91 +- gnu/llvm/clang/lib/AST/CommentBriefParser.cpp | 17 +- .../clang/lib/AST/CommentCommandTraits.cpp | 8 +- gnu/llvm/clang/lib/AST/CommentLexer.cpp | 72 +- gnu/llvm/clang/lib/AST/CommentParser.cpp | 76 +- gnu/llvm/clang/lib/AST/CommentSema.cpp | 125 +- .../clang/lib/AST/ComparisonCategories.cpp | 7 +- gnu/llvm/clang/lib/AST/ComputeDependence.cpp | 169 +- gnu/llvm/clang/lib/AST/Decl.cpp | 512 +- gnu/llvm/clang/lib/AST/DeclBase.cpp | 91 +- gnu/llvm/clang/lib/AST/DeclCXX.cpp | 442 +- gnu/llvm/clang/lib/AST/DeclObjC.cpp | 133 +- gnu/llvm/clang/lib/AST/DeclOpenMP.cpp | 2 +- gnu/llvm/clang/lib/AST/DeclPrinter.cpp | 136 +- gnu/llvm/clang/lib/AST/DeclTemplate.cpp | 313 +- gnu/llvm/clang/lib/AST/DeclarationName.cpp | 16 +- gnu/llvm/clang/lib/AST/Expr.cpp | 432 +- gnu/llvm/clang/lib/AST/ExprCXX.cpp | 160 +- gnu/llvm/clang/lib/AST/ExprClassification.cpp | 23 +- gnu/llvm/clang/lib/AST/ExprConcepts.cpp | 86 +- gnu/llvm/clang/lib/AST/ExprConstant.cpp | 1162 +- gnu/llvm/clang/lib/AST/ExprObjC.cpp | 15 +- gnu/llvm/clang/lib/AST/ExternalASTMerger.cpp | 18 +- gnu/llvm/clang/lib/AST/ExternalASTSource.cpp | 6 +- gnu/llvm/clang/lib/AST/Interp/Boolean.h | 27 +- .../clang/lib/AST/Interp/ByteCodeEmitter.cpp | 145 +- .../clang/lib/AST/Interp/ByteCodeEmitter.h | 4 +- .../clang/lib/AST/Interp/ByteCodeExprGen.cpp | 1144 +- .../clang/lib/AST/Interp/ByteCodeExprGen.h | 177 +- .../clang/lib/AST/Interp/ByteCodeGenError.h | 12 +- .../clang/lib/AST/Interp/ByteCodeStmtGen.cpp | 209 +- .../clang/lib/AST/Interp/ByteCodeStmtGen.h | 20 +- gnu/llvm/clang/lib/AST/Interp/Context.cpp | 39 +- gnu/llvm/clang/lib/AST/Interp/Context.h | 9 +- gnu/llvm/clang/lib/AST/Interp/Descriptor.cpp | 93 +- gnu/llvm/clang/lib/AST/Interp/Descriptor.h | 94 +- gnu/llvm/clang/lib/AST/Interp/Disasm.cpp | 19 +- gnu/llvm/clang/lib/AST/Interp/EvalEmitter.cpp | 29 +- gnu/llvm/clang/lib/AST/Interp/EvalEmitter.h | 12 +- gnu/llvm/clang/lib/AST/Interp/Function.cpp | 18 +- gnu/llvm/clang/lib/AST/Interp/Function.h | 76 +- gnu/llvm/clang/lib/AST/Interp/Integral.h | 126 +- gnu/llvm/clang/lib/AST/Interp/Interp.cpp | 93 +- gnu/llvm/clang/lib/AST/Interp/Interp.h | 547 +- gnu/llvm/clang/lib/AST/Interp/InterpBlock.h | 55 +- gnu/llvm/clang/lib/AST/Interp/InterpFrame.cpp | 90 +- gnu/llvm/clang/lib/AST/Interp/InterpFrame.h | 42 +- gnu/llvm/clang/lib/AST/Interp/InterpStack.cpp | 2 +- gnu/llvm/clang/lib/AST/Interp/InterpStack.h | 69 +- gnu/llvm/clang/lib/AST/Interp/InterpState.h | 5 +- gnu/llvm/clang/lib/AST/Interp/Opcodes.td | 120 +- gnu/llvm/clang/lib/AST/Interp/Pointer.cpp | 26 +- gnu/llvm/clang/lib/AST/Interp/Pointer.h | 52 +- gnu/llvm/clang/lib/AST/Interp/PrimType.cpp | 4 +- gnu/llvm/clang/lib/AST/Interp/PrimType.h | 64 +- gnu/llvm/clang/lib/AST/Interp/Program.cpp | 140 +- gnu/llvm/clang/lib/AST/Interp/Program.h | 68 +- gnu/llvm/clang/lib/AST/Interp/Record.h | 22 +- gnu/llvm/clang/lib/AST/Interp/Source.cpp | 4 +- gnu/llvm/clang/lib/AST/Interp/Source.h | 37 +- gnu/llvm/clang/lib/AST/Interp/State.h | 5 + gnu/llvm/clang/lib/AST/ItaniumCXXABI.cpp | 51 +- gnu/llvm/clang/lib/AST/ItaniumMangle.cpp | 764 +- gnu/llvm/clang/lib/AST/JSONNodeDumper.cpp | 74 +- gnu/llvm/clang/lib/AST/Linkage.h | 8 +- gnu/llvm/clang/lib/AST/Mangle.cpp | 22 +- gnu/llvm/clang/lib/AST/MicrosoftCXXABI.cpp | 44 +- gnu/llvm/clang/lib/AST/MicrosoftMangle.cpp | 203 +- gnu/llvm/clang/lib/AST/NSAPI.cpp | 26 +- .../clang/lib/AST/NestedNameSpecifier.cpp | 7 +- gnu/llvm/clang/lib/AST/ODRDiagsEmitter.cpp | 2206 +++ gnu/llvm/clang/lib/AST/ODRHash.cpp | 187 +- gnu/llvm/clang/lib/AST/OSLog.cpp | 17 +- gnu/llvm/clang/lib/AST/OpenMPClause.cpp | 252 +- gnu/llvm/clang/lib/AST/ParentMap.cpp | 7 +- gnu/llvm/clang/lib/AST/ParentMapContext.cpp | 47 +- gnu/llvm/clang/lib/AST/PrintfFormatString.cpp | 56 +- gnu/llvm/clang/lib/AST/QualTypeNames.cpp | 26 +- gnu/llvm/clang/lib/AST/Randstruct.cpp | 231 + gnu/llvm/clang/lib/AST/RawCommentList.cpp | 65 +- .../clang/lib/AST/RecordLayoutBuilder.cpp | 156 +- gnu/llvm/clang/lib/AST/ScanfFormatString.cpp | 8 +- gnu/llvm/clang/lib/AST/Stmt.cpp | 63 +- gnu/llvm/clang/lib/AST/StmtCXX.cpp | 1 - gnu/llvm/clang/lib/AST/StmtObjC.cpp | 8 +- gnu/llvm/clang/lib/AST/StmtOpenMP.cpp | 572 +- gnu/llvm/clang/lib/AST/StmtPrinter.cpp | 268 +- gnu/llvm/clang/lib/AST/StmtProfile.cpp | 140 +- gnu/llvm/clang/lib/AST/TemplateBase.cpp | 78 +- gnu/llvm/clang/lib/AST/TemplateName.cpp | 145 +- gnu/llvm/clang/lib/AST/TextNodeDumper.cpp | 75 +- gnu/llvm/clang/lib/AST/Type.cpp | 435 +- gnu/llvm/clang/lib/AST/TypeLoc.cpp | 57 +- gnu/llvm/clang/lib/AST/TypePrinter.cpp | 433 +- gnu/llvm/clang/lib/AST/VTableBuilder.cpp | 29 +- .../clang/lib/ASTMatchers/ASTMatchFinder.cpp | 264 +- .../lib/ASTMatchers/ASTMatchersInternal.cpp | 46 +- .../lib/ASTMatchers/Dynamic/Diagnostics.cpp | 4 +- .../lib/ASTMatchers/Dynamic/Marshallers.cpp | 63 +- .../lib/ASTMatchers/Dynamic/Marshallers.h | 92 +- .../clang/lib/ASTMatchers/Dynamic/Parser.cpp | 31 +- .../lib/ASTMatchers/Dynamic/Registry.cpp | 44 +- .../lib/ASTMatchers/Dynamic/VariantValue.cpp | 33 +- .../lib/Analysis/AnalysisDeclContext.cpp | 13 +- gnu/llvm/clang/lib/Analysis/BodyFarm.cpp | 84 +- gnu/llvm/clang/lib/Analysis/CFG.cpp | 623 +- gnu/llvm/clang/lib/Analysis/CFGStmtMap.cpp | 3 +- gnu/llvm/clang/lib/Analysis/CMakeLists.txt | 2 + .../clang/lib/Analysis/CalledOnceCheck.cpp | 64 +- .../clang/lib/Analysis/CloneDetection.cpp | 5 +- .../lib/Analysis/ConstructionContext.cpp | 11 + gnu/llvm/clang/lib/Analysis/Consumed.cpp | 6 +- .../lib/Analysis/ExprMutationAnalyzer.cpp | 38 +- .../lib/Analysis/FlowSensitive/CMakeLists.txt | 17 + .../FlowSensitive/ControlFlowContext.cpp | 71 + .../FlowSensitive/DataflowAnalysisContext.cpp | 422 + .../FlowSensitive/DataflowEnvironment.cpp | 818 + .../Analysis/FlowSensitive/DebugSupport.cpp | 259 + .../FlowSensitive/Models/CMakeLists.txt | 11 + .../Models/ChromiumCheckModel.cpp | 71 + .../Models/UncheckedOptionalAccessModel.cpp | 912 ++ .../lib/Analysis/FlowSensitive/Transfer.cpp | 839 + .../TypeErasedDataflowAnalysis.cpp | 500 + .../lib/Analysis/FlowSensitive/Value.cpp | 56 + .../FlowSensitive/WatchedLiteralsSolver.cpp | 721 + gnu/llvm/clang/lib/Analysis/IssueHash.cpp | 5 +- gnu/llvm/clang/lib/Analysis/LiveVariables.cpp | 30 +- .../lib/Analysis/MacroExpansionContext.cpp | 15 +- gnu/llvm/clang/lib/Analysis/ObjCNoReturn.cpp | 9 +- .../clang/lib/Analysis/PathDiagnostic.cpp | 76 +- gnu/llvm/clang/lib/Analysis/ReachableCode.cpp | 44 +- .../lib/Analysis/RetainSummaryManager.cpp | 46 +- gnu/llvm/clang/lib/Analysis/ThreadSafety.cpp | 596 +- .../clang/lib/Analysis/ThreadSafetyCommon.cpp | 85 +- .../lib/Analysis/UninitializedValues.cpp | 49 +- .../clang/lib/Analysis/UnsafeBufferUsage.cpp | 695 + .../clang/lib/Analysis/plugins/CMakeLists.txt | 5 +- .../CheckerDependencyHandling/CMakeLists.txt | 2 +- .../CheckerOptionHandling/CMakeLists.txt | 2 +- .../plugins/SampleAnalyzer/CMakeLists.txt | 2 +- gnu/llvm/clang/lib/Basic/Attributes.cpp | 11 +- .../clang/lib/Basic/BuiltinTargetFeatures.h | 95 + gnu/llvm/clang/lib/Basic/Builtins.cpp | 141 +- gnu/llvm/clang/lib/Basic/CLWarnings.cpp | 29 + gnu/llvm/clang/lib/Basic/CMakeLists.txt | 14 +- gnu/llvm/clang/lib/Basic/Cuda.cpp | 148 +- gnu/llvm/clang/lib/Basic/DarwinSDKInfo.cpp | 59 +- gnu/llvm/clang/lib/Basic/Diagnostic.cpp | 110 +- gnu/llvm/clang/lib/Basic/DiagnosticIDs.cpp | 72 +- .../clang/lib/Basic/DiagnosticOptions.cpp | 2 +- gnu/llvm/clang/lib/Basic/FileManager.cpp | 217 +- gnu/llvm/clang/lib/Basic/IdentifierTable.cpp | 225 +- gnu/llvm/clang/lib/Basic/LangOptions.cpp | 154 +- gnu/llvm/clang/lib/Basic/LangStandards.cpp | 37 +- gnu/llvm/clang/lib/Basic/MakeSupport.cpp | 35 + gnu/llvm/clang/lib/Basic/Module.cpp | 39 +- gnu/llvm/clang/lib/Basic/NoSanitizeList.cpp | 5 + gnu/llvm/clang/lib/Basic/OpenCLOptions.cpp | 43 +- gnu/llvm/clang/lib/Basic/OpenMPKinds.cpp | 213 +- gnu/llvm/clang/lib/Basic/ProfileList.cpp | 60 +- .../lib/Basic/SanitizerSpecialCaseList.cpp | 2 +- gnu/llvm/clang/lib/Basic/Sanitizers.cpp | 2 +- gnu/llvm/clang/lib/Basic/Sarif.cpp | 422 + gnu/llvm/clang/lib/Basic/SourceLocation.cpp | 12 +- gnu/llvm/clang/lib/Basic/SourceManager.cpp | 440 +- gnu/llvm/clang/lib/Basic/Stack.cpp | 1 - gnu/llvm/clang/lib/Basic/TargetID.cpp | 52 +- gnu/llvm/clang/lib/Basic/Targets.cpp | 54 +- gnu/llvm/clang/lib/Basic/Targets/AArch64.cpp | 742 +- gnu/llvm/clang/lib/Basic/Targets/AArch64.h | 125 +- gnu/llvm/clang/lib/Basic/Targets/AMDGPU.cpp | 134 +- gnu/llvm/clang/lib/Basic/Targets/AMDGPU.h | 63 +- gnu/llvm/clang/lib/Basic/Targets/ARC.h | 12 +- gnu/llvm/clang/lib/Basic/Targets/ARM.cpp | 146 +- gnu/llvm/clang/lib/Basic/Targets/ARM.h | 17 +- gnu/llvm/clang/lib/Basic/Targets/AVR.cpp | 696 +- gnu/llvm/clang/lib/Basic/Targets/AVR.h | 25 +- gnu/llvm/clang/lib/Basic/Targets/BPF.cpp | 10 +- gnu/llvm/clang/lib/Basic/Targets/BPF.h | 7 +- gnu/llvm/clang/lib/Basic/Targets/CSKY.cpp | 314 + gnu/llvm/clang/lib/Basic/Targets/CSKY.h | 107 + gnu/llvm/clang/lib/Basic/Targets/DirectX.cpp | 22 + gnu/llvm/clang/lib/Basic/Targets/DirectX.h | 100 + gnu/llvm/clang/lib/Basic/Targets/Hexagon.cpp | 41 +- gnu/llvm/clang/lib/Basic/Targets/Hexagon.h | 3 +- gnu/llvm/clang/lib/Basic/Targets/Lanai.cpp | 4 +- gnu/llvm/clang/lib/Basic/Targets/Lanai.h | 6 +- gnu/llvm/clang/lib/Basic/Targets/Le64.h | 6 +- .../clang/lib/Basic/Targets/LoongArch.cpp | 217 + gnu/llvm/clang/lib/Basic/Targets/LoongArch.h | 136 + gnu/llvm/clang/lib/Basic/Targets/M68k.cpp | 19 +- gnu/llvm/clang/lib/Basic/Targets/M68k.h | 3 +- gnu/llvm/clang/lib/Basic/Targets/MSP430.cpp | 2 +- gnu/llvm/clang/lib/Basic/Targets/MSP430.h | 4 +- gnu/llvm/clang/lib/Basic/Targets/Mips.cpp | 26 +- gnu/llvm/clang/lib/Basic/Targets/NVPTX.cpp | 61 +- gnu/llvm/clang/lib/Basic/Targets/NVPTX.h | 27 +- .../clang/lib/Basic/Targets/OSTargets.cpp | 169 +- gnu/llvm/clang/lib/Basic/Targets/PNaCl.cpp | 6 +- gnu/llvm/clang/lib/Basic/Targets/PNaCl.h | 6 +- gnu/llvm/clang/lib/Basic/Targets/PPC.cpp | 174 +- gnu/llvm/clang/lib/Basic/Targets/PPC.h | 33 +- gnu/llvm/clang/lib/Basic/Targets/RISCV.h | 61 +- gnu/llvm/clang/lib/Basic/Targets/SPIR.cpp | 21 +- gnu/llvm/clang/lib/Basic/Targets/SPIR.h | 153 +- gnu/llvm/clang/lib/Basic/Targets/Sparc.cpp | 6 +- gnu/llvm/clang/lib/Basic/Targets/Sparc.h | 13 +- gnu/llvm/clang/lib/Basic/Targets/SystemZ.cpp | 27 +- gnu/llvm/clang/lib/Basic/Targets/TCE.h | 11 +- gnu/llvm/clang/lib/Basic/Targets/VE.cpp | 14 +- gnu/llvm/clang/lib/Basic/Targets/VE.h | 5 +- .../clang/lib/Basic/Targets/WebAssembly.cpp | 63 +- .../clang/lib/Basic/Targets/WebAssembly.h | 21 +- gnu/llvm/clang/lib/Basic/Targets/XCore.cpp | 10 +- gnu/llvm/clang/lib/Basic/Targets/XCore.h | 7 +- gnu/llvm/clang/lib/Basic/TokenKinds.cpp | 9 + gnu/llvm/clang/lib/Basic/TypeTraits.cpp | 14 + gnu/llvm/clang/lib/Basic/Version.cpp | 6 +- gnu/llvm/clang/lib/CMakeLists.txt | 6 +- gnu/llvm/clang/lib/CodeGen/ABIInfo.h | 53 +- gnu/llvm/clang/lib/CodeGen/Address.h | 118 +- gnu/llvm/clang/lib/CodeGen/BackendUtil.cpp | 1112 +- gnu/llvm/clang/lib/CodeGen/CGAtomic.cpp | 146 +- gnu/llvm/clang/lib/CodeGen/CGBlocks.cpp | 450 +- gnu/llvm/clang/lib/CodeGen/CGBlocks.h | 69 +- gnu/llvm/clang/lib/CodeGen/CGBuilder.h | 107 +- gnu/llvm/clang/lib/CodeGen/CGBuiltin.cpp | 4593 ++++-- gnu/llvm/clang/lib/CodeGen/CGCUDANV.cpp | 185 +- gnu/llvm/clang/lib/CodeGen/CGCUDARuntime.h | 13 + gnu/llvm/clang/lib/CodeGen/CGCXXABI.cpp | 48 +- gnu/llvm/clang/lib/CodeGen/CGCXXABI.h | 37 +- gnu/llvm/clang/lib/CodeGen/CGCall.h | 15 +- gnu/llvm/clang/lib/CodeGen/CGClass.cpp | 390 +- gnu/llvm/clang/lib/CodeGen/CGCleanup.cpp | 40 +- gnu/llvm/clang/lib/CodeGen/CGCleanup.h | 12 +- gnu/llvm/clang/lib/CodeGen/CGCoroutine.cpp | 121 +- gnu/llvm/clang/lib/CodeGen/CGDebugInfo.cpp | 1156 +- gnu/llvm/clang/lib/CodeGen/CGDebugInfo.h | 74 +- gnu/llvm/clang/lib/CodeGen/CGDecl.cpp | 127 +- gnu/llvm/clang/lib/CodeGen/CGDeclCXX.cpp | 263 +- gnu/llvm/clang/lib/CodeGen/CGException.cpp | 54 +- gnu/llvm/clang/lib/CodeGen/CGExpr.cpp | 760 +- gnu/llvm/clang/lib/CodeGen/CGExprAgg.cpp | 134 +- gnu/llvm/clang/lib/CodeGen/CGExprCXX.cpp | 66 +- gnu/llvm/clang/lib/CodeGen/CGExprComplex.cpp | 257 +- gnu/llvm/clang/lib/CodeGen/CGExprConstant.cpp | 117 +- gnu/llvm/clang/lib/CodeGen/CGExprScalar.cpp | 563 +- gnu/llvm/clang/lib/CodeGen/CGGPUBuiltin.cpp | 135 +- gnu/llvm/clang/lib/CodeGen/CGHLSLRuntime.cpp | 459 + gnu/llvm/clang/lib/CodeGen/CGHLSLRuntime.h | 105 + gnu/llvm/clang/lib/CodeGen/CGLoopInfo.cpp | 17 +- .../clang/lib/CodeGen/CGNonTrivialStruct.cpp | 47 +- gnu/llvm/clang/lib/CodeGen/CGObjC.cpp | 338 +- gnu/llvm/clang/lib/CodeGen/CGObjCGNU.cpp | 275 +- gnu/llvm/clang/lib/CodeGen/CGObjCMac.cpp | 304 +- gnu/llvm/clang/lib/CodeGen/CGObjCRuntime.cpp | 110 +- gnu/llvm/clang/lib/CodeGen/CGObjCRuntime.h | 20 +- .../clang/lib/CodeGen/CGOpenCLRuntime.cpp | 51 +- gnu/llvm/clang/lib/CodeGen/CGOpenCLRuntime.h | 6 +- .../clang/lib/CodeGen/CGOpenMPRuntime.cpp | 3172 ++-- gnu/llvm/clang/lib/CodeGen/CGOpenMPRuntime.h | 392 +- .../clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp | 716 +- .../clang/lib/CodeGen/CGOpenMPRuntimeGPU.h | 66 +- gnu/llvm/clang/lib/CodeGen/CGRecordLayout.h | 10 +- .../lib/CodeGen/CGRecordLayoutBuilder.cpp | 4 +- gnu/llvm/clang/lib/CodeGen/CGStmt.cpp | 327 +- gnu/llvm/clang/lib/CodeGen/CGStmtOpenMP.cpp | 1728 +- gnu/llvm/clang/lib/CodeGen/CGVTT.cpp | 6 +- gnu/llvm/clang/lib/CodeGen/CGVTables.cpp | 88 +- gnu/llvm/clang/lib/CodeGen/CGVTables.h | 7 + gnu/llvm/clang/lib/CodeGen/CGValue.h | 76 +- gnu/llvm/clang/lib/CodeGen/CMakeLists.txt | 7 +- gnu/llvm/clang/lib/CodeGen/CodeGenAction.cpp | 203 +- .../clang/lib/CodeGen/CodeGenFunction.cpp | 561 +- gnu/llvm/clang/lib/CodeGen/CodeGenFunction.h | 405 +- gnu/llvm/clang/lib/CodeGen/CodeGenModule.h | 217 +- gnu/llvm/clang/lib/CodeGen/CodeGenPGO.cpp | 25 +- gnu/llvm/clang/lib/CodeGen/CodeGenPGO.h | 7 +- gnu/llvm/clang/lib/CodeGen/CodeGenTBAA.cpp | 41 +- gnu/llvm/clang/lib/CodeGen/CodeGenTBAA.h | 1 - gnu/llvm/clang/lib/CodeGen/CodeGenTypeCache.h | 9 + gnu/llvm/clang/lib/CodeGen/CodeGenTypes.cpp | 104 +- gnu/llvm/clang/lib/CodeGen/CodeGenTypes.h | 13 +- gnu/llvm/clang/lib/CodeGen/ConstantEmitter.h | 3 + .../clang/lib/CodeGen/ConstantInitBuilder.cpp | 13 +- .../clang/lib/CodeGen/CoverageMappingGen.cpp | 176 +- .../clang/lib/CodeGen/CoverageMappingGen.h | 20 +- gnu/llvm/clang/lib/CodeGen/ItaniumCXXABI.cpp | 307 +- .../clang/lib/CodeGen/MacroPPCallbacks.cpp | 4 +- gnu/llvm/clang/lib/CodeGen/MacroPPCallbacks.h | 7 +- .../clang/lib/CodeGen/MicrosoftCXXABI.cpp | 244 +- gnu/llvm/clang/lib/CodeGen/ModuleBuilder.cpp | 45 +- .../ObjectFilePCHContainerOperations.cpp | 72 +- gnu/llvm/clang/lib/CodeGen/PatternInit.cpp | 4 +- .../clang/lib/CodeGen/SanitizerMetadata.cpp | 127 +- .../clang/lib/CodeGen/SanitizerMetadata.h | 22 +- .../clang/lib/CodeGen/SwiftCallingConv.cpp | 39 +- gnu/llvm/clang/lib/CodeGen/TargetInfo.h | 20 +- .../clang/lib/CodeGen/VarBypassDetector.cpp | 2 +- .../clang/lib/CodeGen/VarBypassDetector.h | 2 +- gnu/llvm/clang/lib/CrossTU/CMakeLists.txt | 1 + .../lib/CrossTU/CrossTranslationUnit.cpp | 128 +- .../lib/DirectoryWatcher/DirectoryScanner.cpp | 7 +- .../lib/DirectoryWatcher/DirectoryScanner.h | 5 +- .../linux/DirectoryWatcher-linux.cpp | 5 +- .../mac/DirectoryWatcher-mac.cpp | 2 +- .../windows/DirectoryWatcher-windows.cpp | 9 +- gnu/llvm/clang/lib/Driver/Action.cpp | 67 +- gnu/llvm/clang/lib/Driver/CMakeLists.txt | 16 +- gnu/llvm/clang/lib/Driver/Compilation.cpp | 26 +- gnu/llvm/clang/lib/Driver/Distro.cpp | 14 +- gnu/llvm/clang/lib/Driver/DriverOptions.cpp | 39 +- gnu/llvm/clang/lib/Driver/Job.cpp | 33 +- gnu/llvm/clang/lib/Driver/Multilib.cpp | 9 +- gnu/llvm/clang/lib/Driver/OffloadBundler.cpp | 1283 ++ gnu/llvm/clang/lib/Driver/SanitizerArgs.cpp | 479 +- gnu/llvm/clang/lib/Driver/ToolChain.cpp | 266 +- gnu/llvm/clang/lib/Driver/ToolChains/AIX.cpp | 164 +- gnu/llvm/clang/lib/Driver/ToolChains/AIX.h | 12 +- .../clang/lib/Driver/ToolChains/AMDGPU.cpp | 305 +- gnu/llvm/clang/lib/Driver/ToolChains/AMDGPU.h | 29 +- .../lib/Driver/ToolChains/AMDGPUOpenMP.cpp | 265 +- .../lib/Driver/ToolChains/AMDGPUOpenMP.h | 49 +- gnu/llvm/clang/lib/Driver/ToolChains/AVR.cpp | 275 +- gnu/llvm/clang/lib/Driver/ToolChains/AVR.h | 26 +- .../clang/lib/Driver/ToolChains/Ananas.cpp | 16 +- .../lib/Driver/ToolChains/Arch/AArch64.cpp | 259 +- .../clang/lib/Driver/ToolChains/Arch/ARM.cpp | 111 +- .../clang/lib/Driver/ToolChains/Arch/ARM.h | 8 +- .../clang/lib/Driver/ToolChains/Arch/CSKY.cpp | 169 + .../clang/lib/Driver/ToolChains/Arch/CSKY.h | 47 + .../lib/Driver/ToolChains/Arch/LoongArch.cpp | 115 + .../lib/Driver/ToolChains/Arch/LoongArch.h | 31 + .../clang/lib/Driver/ToolChains/Arch/Mips.cpp | 9 +- .../clang/lib/Driver/ToolChains/Arch/Mips.h | 3 +- .../clang/lib/Driver/ToolChains/Arch/PPC.cpp | 131 +- .../clang/lib/Driver/ToolChains/Arch/PPC.h | 5 +- .../clang/lib/Driver/ToolChains/Arch/RISCV.h | 2 + .../lib/Driver/ToolChains/Arch/Sparc.cpp | 78 +- .../clang/lib/Driver/ToolChains/Arch/Sparc.h | 3 + .../clang/lib/Driver/ToolChains/Arch/VE.cpp | 1 - .../clang/lib/Driver/ToolChains/Arch/VE.h | 2 +- .../clang/lib/Driver/ToolChains/Arch/X86.h | 2 +- .../clang/lib/Driver/ToolChains/BareMetal.cpp | 83 +- .../clang/lib/Driver/ToolChains/BareMetal.h | 27 +- .../lib/Driver/ToolChains/CSKYToolChain.cpp | 204 + .../lib/Driver/ToolChains/CSKYToolChain.h | 63 + gnu/llvm/clang/lib/Driver/ToolChains/Clang.h | 42 +- .../clang/lib/Driver/ToolChains/CloudABI.cpp | 6 +- .../clang/lib/Driver/ToolChains/CloudABI.h | 2 +- .../lib/Driver/ToolChains/CommonArgs.cpp | 1024 +- .../clang/lib/Driver/ToolChains/CommonArgs.h | 86 +- .../lib/Driver/ToolChains/CrossWindows.cpp | 14 +- .../lib/Driver/ToolChains/CrossWindows.h | 5 +- gnu/llvm/clang/lib/Driver/ToolChains/Cuda.cpp | 526 +- gnu/llvm/clang/lib/Driver/ToolChains/Cuda.h | 144 +- .../clang/lib/Driver/ToolChains/Darwin.cpp | 912 +- gnu/llvm/clang/lib/Driver/ToolChains/Darwin.h | 56 +- .../clang/lib/Driver/ToolChains/DragonFly.cpp | 11 +- .../clang/lib/Driver/ToolChains/Flang.cpp | 265 +- gnu/llvm/clang/lib/Driver/ToolChains/Flang.h | 23 +- .../clang/lib/Driver/ToolChains/FreeBSD.cpp | 151 +- .../clang/lib/Driver/ToolChains/FreeBSD.h | 22 +- .../clang/lib/Driver/ToolChains/Fuchsia.cpp | 75 +- .../clang/lib/Driver/ToolChains/Fuchsia.h | 37 +- gnu/llvm/clang/lib/Driver/ToolChains/Gnu.h | 11 +- .../clang/lib/Driver/ToolChains/HIPAMD.cpp | 421 + gnu/llvm/clang/lib/Driver/ToolChains/HIPAMD.h | 100 + .../clang/lib/Driver/ToolChains/HIPSPV.cpp | 292 + gnu/llvm/clang/lib/Driver/ToolChains/HIPSPV.h | 103 + .../lib/Driver/ToolChains/HIPUtility.cpp | 171 + .../clang/lib/Driver/ToolChains/HIPUtility.h | 35 + gnu/llvm/clang/lib/Driver/ToolChains/HLSL.cpp | 214 + gnu/llvm/clang/lib/Driver/ToolChains/HLSL.h | 39 + gnu/llvm/clang/lib/Driver/ToolChains/Haiku.h | 2 +- .../clang/lib/Driver/ToolChains/Hexagon.cpp | 181 +- .../clang/lib/Driver/ToolChains/Hexagon.h | 13 +- gnu/llvm/clang/lib/Driver/ToolChains/Lanai.h | 2 - .../clang/lib/Driver/ToolChains/Linux.cpp | 190 +- gnu/llvm/clang/lib/Driver/ToolChains/Linux.h | 8 +- .../clang/lib/Driver/ToolChains/MSP430.cpp | 2 +- gnu/llvm/clang/lib/Driver/ToolChains/MSP430.h | 4 +- gnu/llvm/clang/lib/Driver/ToolChains/MSVC.cpp | 882 +- gnu/llvm/clang/lib/Driver/ToolChains/MSVC.h | 40 +- .../clang/lib/Driver/ToolChains/MinGW.cpp | 314 +- gnu/llvm/clang/lib/Driver/ToolChains/MinGW.h | 22 +- .../clang/lib/Driver/ToolChains/Minix.cpp | 9 +- .../clang/lib/Driver/ToolChains/MipsLinux.cpp | 2 + .../clang/lib/Driver/ToolChains/Myriad.cpp | 2 +- gnu/llvm/clang/lib/Driver/ToolChains/NaCl.cpp | 2 + .../clang/lib/Driver/ToolChains/NetBSD.cpp | 120 +- gnu/llvm/clang/lib/Driver/ToolChains/NetBSD.h | 8 +- .../lib/Driver/ToolChains/PPCFreeBSD.cpp | 28 + .../clang/lib/Driver/ToolChains/PPCFreeBSD.h | 33 + .../clang/lib/Driver/ToolChains/PPCLinux.cpp | 75 + .../clang/lib/Driver/ToolChains/PPCLinux.h | 9 +- .../clang/lib/Driver/ToolChains/PS4CPU.cpp | 230 +- gnu/llvm/clang/lib/Driver/ToolChains/PS4CPU.h | 117 +- .../lib/Driver/ToolChains/RISCVToolchain.cpp | 14 +- .../lib/Driver/ToolChains/RISCVToolchain.h | 1 - gnu/llvm/clang/lib/Driver/ToolChains/ROCm.h | 50 +- .../clang/lib/Driver/ToolChains/SPIRV.cpp | 93 + gnu/llvm/clang/lib/Driver/ToolChains/SPIRV.h | 92 + .../clang/lib/Driver/ToolChains/Solaris.cpp | 35 +- gnu/llvm/clang/lib/Driver/ToolChains/TCE.cpp | 4 +- gnu/llvm/clang/lib/Driver/ToolChains/TCE.h | 2 +- .../lib/Driver/ToolChains/VEToolchain.cpp | 44 +- .../clang/lib/Driver/ToolChains/VEToolchain.h | 3 +- .../lib/Driver/ToolChains/WebAssembly.cpp | 163 +- .../clang/lib/Driver/ToolChains/WebAssembly.h | 12 +- .../clang/lib/Driver/ToolChains/XCore.cpp | 8 +- gnu/llvm/clang/lib/Driver/ToolChains/XCore.h | 2 +- gnu/llvm/clang/lib/Driver/ToolChains/ZOS.h | 6 +- gnu/llvm/clang/lib/Driver/Types.cpp | 245 +- gnu/llvm/clang/lib/Driver/XRayArgs.cpp | 4 +- gnu/llvm/clang/lib/Edit/EditedSource.cpp | 10 +- .../lib/Edit/RewriteObjCFoundationAPI.cpp | 27 +- gnu/llvm/clang/lib/ExtractAPI/API.cpp | 304 + .../clang/lib/ExtractAPI/APIIgnoresList.cpp | 53 + .../clang/lib/ExtractAPI/AvailabilityInfo.cpp | 50 + gnu/llvm/clang/lib/ExtractAPI/CMakeLists.txt | 23 + .../lib/ExtractAPI/DeclarationFragments.cpp | 805 + .../lib/ExtractAPI/ExtractAPIConsumer.cpp | 435 + .../lib/ExtractAPI/ExtractAPIVisitor.cpp | 560 + .../Serialization/SerializerBase.cpp | 19 + .../Serialization/SymbolGraphSerializer.cpp | 909 ++ .../TypedefUnderlyingTypeResolver.cpp | 76 + .../TypedefUnderlyingTypeResolver.h | 48 + gnu/llvm/clang/lib/Format/.clang-format | 4 + .../clang/lib/Format/AffectedRangeManager.cpp | 11 +- gnu/llvm/clang/lib/Format/BreakableToken.cpp | 172 +- gnu/llvm/clang/lib/Format/CMakeLists.txt | 4 + .../clang/lib/Format/ContinuationIndenter.cpp | 1069 +- .../clang/lib/Format/ContinuationIndenter.h | 44 +- .../lib/Format/DefinitionBlockSeparator.cpp | 259 + .../lib/Format/DefinitionBlockSeparator.h | 41 + gnu/llvm/clang/lib/Format/Format.cpp | 1886 ++- gnu/llvm/clang/lib/Format/FormatToken.cpp | 54 +- gnu/llvm/clang/lib/Format/FormatToken.h | 699 +- .../clang/lib/Format/FormatTokenLexer.cpp | 702 +- gnu/llvm/clang/lib/Format/FormatTokenLexer.h | 14 + .../Format/IntegerLiteralSeparatorFixer.cpp | 221 + .../lib/Format/IntegerLiteralSeparatorFixer.h | 39 + .../lib/Format/MacroCallReconstructor.cpp | 568 + gnu/llvm/clang/lib/Format/MacroExpander.cpp | 12 +- gnu/llvm/clang/lib/Format/Macros.h | 286 +- .../lib/Format/NamespaceEndCommentsFixer.cpp | 138 +- .../lib/Format/QualifierAlignmentFixer.cpp | 525 + .../lib/Format/QualifierAlignmentFixer.h | 100 + .../lib/Format/SortJavaScriptImports.cpp | 81 +- gnu/llvm/clang/lib/Format/TokenAnalyzer.cpp | 79 +- gnu/llvm/clang/lib/Format/TokenAnalyzer.h | 15 +- gnu/llvm/clang/lib/Format/TokenAnnotator.cpp | 2429 ++- gnu/llvm/clang/lib/Format/TokenAnnotator.h | 68 +- .../lib/Format/UnwrappedLineFormatter.cpp | 554 +- .../clang/lib/Format/UnwrappedLineFormatter.h | 2 +- .../clang/lib/Format/UnwrappedLineParser.cpp | 2470 ++- .../clang/lib/Format/UnwrappedLineParser.h | 90 +- .../lib/Format/UsingDeclarationsSorter.cpp | 67 +- .../clang/lib/Format/WhitespaceManager.cpp | 407 +- gnu/llvm/clang/lib/Format/WhitespaceManager.h | 27 +- gnu/llvm/clang/lib/Frontend/ASTConsumers.cpp | 7 +- gnu/llvm/clang/lib/Frontend/ASTUnit.cpp | 73 +- gnu/llvm/clang/lib/Frontend/CMakeLists.txt | 4 +- .../lib/Frontend/ChainedIncludesSource.cpp | 39 +- .../CreateInvocationFromCommandLine.cpp | 42 +- .../clang/lib/Frontend/DependencyFile.cpp | 61 +- .../clang/lib/Frontend/DependencyGraph.cpp | 36 +- .../clang/lib/Frontend/DiagnosticRenderer.cpp | 5 +- .../clang/lib/Frontend/FrontendAction.cpp | 232 +- .../clang/lib/Frontend/FrontendActions.cpp | 334 +- .../clang/lib/Frontend/FrontendOptions.cpp | 3 +- .../clang/lib/Frontend/HeaderIncludeGen.cpp | 137 +- .../clang/lib/Frontend/InitPreprocessor.cpp | 259 +- .../lib/Frontend/LayoutOverrideSource.cpp | 6 +- .../lib/Frontend/LogDiagnosticPrinter.cpp | 6 +- .../Frontend/ModuleDependencyCollector.cpp | 19 +- .../clang/lib/Frontend/MultiplexConsumer.cpp | 10 +- .../lib/Frontend/PrecompiledPreamble.cpp | 358 +- .../lib/Frontend/PrintPreprocessedOutput.cpp | 430 +- .../lib/Frontend/Rewrite/FrontendActions.cpp | 2 +- .../Frontend/Rewrite/InclusionRewriter.cpp | 94 +- .../Frontend/Rewrite/RewriteModernObjC.cpp | 38 +- .../lib/Frontend/Rewrite/RewriteObjC.cpp | 4 +- .../clang/lib/Frontend/SARIFDiagnostic.cpp | 225 + .../lib/Frontend/SARIFDiagnosticPrinter.cpp | 83 + .../Frontend/SerializedDiagnosticPrinter.cpp | 3 +- .../Frontend/SerializedDiagnosticReader.cpp | 8 +- .../lib/Frontend/TestModuleFileExtension.cpp | 16 +- .../lib/Frontend/TestModuleFileExtension.h | 2 +- .../clang/lib/Frontend/TextDiagnostic.cpp | 18 +- .../lib/Frontend/VerifyDiagnosticConsumer.cpp | 9 +- .../clang/lib/FrontendTool/CMakeLists.txt | 1 + .../ExecuteCompilerInvocation.cpp | 28 +- gnu/llvm/clang/lib/Headers/CMakeLists.txt | 598 +- .../Headers/__clang_cuda_complex_builtins.h | 6 +- .../lib/Headers/__clang_cuda_intrinsics.h | 44 +- .../Headers/__clang_cuda_libdevice_declares.h | 6 + .../clang/lib/Headers/__clang_cuda_math.h | 2 +- .../Headers/__clang_cuda_runtime_wrapper.h | 69 +- .../Headers/__clang_cuda_texture_intrinsics.h | 742 + .../Headers/__clang_hip_libdevice_declares.h | 5 + gnu/llvm/clang/lib/Headers/__clang_hip_math.h | 23 +- .../lib/Headers/__clang_hip_runtime_wrapper.h | 22 +- .../clang/lib/Headers/__clang_hip_stdlib.h | 43 + gnu/llvm/clang/lib/Headers/__wmmintrin_aes.h | 2 +- .../clang/lib/Headers/__wmmintrin_pclmul.h | 20 +- gnu/llvm/clang/lib/Headers/altivec.h | 1033 +- gnu/llvm/clang/lib/Headers/ammintrin.h | 4 + gnu/llvm/clang/lib/Headers/amxfp16intrin.h | 58 + gnu/llvm/clang/lib/Headers/amxintrin.h | 67 +- gnu/llvm/clang/lib/Headers/arm_acle.h | 153 +- .../clang/lib/Headers/arm_neon_sve_bridge.h | 182 + gnu/llvm/clang/lib/Headers/avx2intrin.h | 378 +- gnu/llvm/clang/lib/Headers/avx512bf16intrin.h | 39 +- gnu/llvm/clang/lib/Headers/avx512bwintrin.h | 166 +- gnu/llvm/clang/lib/Headers/avx512dqintrin.h | 730 +- gnu/llvm/clang/lib/Headers/avx512erintrin.h | 204 +- gnu/llvm/clang/lib/Headers/avx512fintrin.h | 3247 ++-- gnu/llvm/clang/lib/Headers/avx512fp16intrin.h | 3346 ++++ .../clang/lib/Headers/avx512ifmavlintrin.h | 40 +- .../clang/lib/Headers/avx512vbmi2intrin.h | 96 +- .../clang/lib/Headers/avx512vlbf16intrin.h | 123 +- gnu/llvm/clang/lib/Headers/avx512vlbwintrin.h | 556 +- gnu/llvm/clang/lib/Headers/avx512vldqintrin.h | 268 +- .../clang/lib/Headers/avx512vlfp16intrin.h | 2071 +++ gnu/llvm/clang/lib/Headers/avx512vlintrin.h | 1206 +- .../clang/lib/Headers/avx512vlvbmi2intrin.h | 192 +- .../clang/lib/Headers/avx512vlvnniintrin.h | 48 +- gnu/llvm/clang/lib/Headers/avxifmaintrin.h | 177 + gnu/llvm/clang/lib/Headers/avxintrin.h | 490 +- .../clang/lib/Headers/avxneconvertintrin.h | 484 + .../clang/lib/Headers/avxvnniint8intrin.h | 471 + gnu/llvm/clang/lib/Headers/avxvnniintrin.h | 32 +- gnu/llvm/clang/lib/Headers/bmiintrin.h | 8 +- gnu/llvm/clang/lib/Headers/cetintrin.h | 24 +- gnu/llvm/clang/lib/Headers/cmpccxaddintrin.h | 70 + gnu/llvm/clang/lib/Headers/cpuid.h | 16 +- gnu/llvm/clang/lib/Headers/crc32intrin.h | 100 + .../clang/lib/Headers/cuda_wrappers/cmath | 90 + gnu/llvm/clang/lib/Headers/emmintrin.h | 1352 +- gnu/llvm/clang/lib/Headers/f16cintrin.h | 8 +- gnu/llvm/clang/lib/Headers/float.h | 28 +- gnu/llvm/clang/lib/Headers/gfniintrin.h | 107 +- gnu/llvm/clang/lib/Headers/hexagon_protos.h | 11 - gnu/llvm/clang/lib/Headers/hexagon_types.h | 32 - gnu/llvm/clang/lib/Headers/hlsl.h | 15 + .../clang/lib/Headers/hlsl/hlsl_basic_types.h | 67 + .../clang/lib/Headers/hlsl/hlsl_intrinsics.h | 223 + gnu/llvm/clang/lib/Headers/hresetintrin.h | 4 +- .../clang/lib/Headers/hvx_hexagon_protos.h | 1609 +- gnu/llvm/clang/lib/Headers/ia32intrin.h | 34 +- gnu/llvm/clang/lib/Headers/immintrin.h | 98 +- gnu/llvm/clang/lib/Headers/intrin.h | 69 +- gnu/llvm/clang/lib/Headers/keylockerintrin.h | 54 +- gnu/llvm/clang/lib/Headers/larchintrin.h | 234 + gnu/llvm/clang/lib/Headers/limits.h | 23 +- gnu/llvm/clang/lib/Headers/mm_malloc.h | 6 +- gnu/llvm/clang/lib/Headers/mmintrin.h | 4 + gnu/llvm/clang/lib/Headers/nmmintrin.h | 4 + gnu/llvm/clang/lib/Headers/opencl-c-base.h | 109 +- gnu/llvm/clang/lib/Headers/opencl-c.h | 13460 +++++++++------- .../clang/lib/Headers/openmp_wrappers/complex | 11 +- .../lib/Headers/openmp_wrappers/complex.h | 9 + .../lib/Headers/openmp_wrappers/stdlib.h | 29 + gnu/llvm/clang/lib/Headers/pmmintrin.h | 6 +- .../lib/Headers/ppc_wrappers/bmi2intrin.h | 134 + .../lib/Headers/ppc_wrappers/bmiintrin.h | 165 + .../lib/Headers/ppc_wrappers/emmintrin.h | 2924 ++-- .../lib/Headers/ppc_wrappers/immintrin.h | 27 + .../lib/Headers/ppc_wrappers/mm_malloc.h | 29 +- .../clang/lib/Headers/ppc_wrappers/mmintrin.h | 775 +- .../lib/Headers/ppc_wrappers/nmmintrin.h | 26 + .../lib/Headers/ppc_wrappers/pmmintrin.h | 153 +- .../lib/Headers/ppc_wrappers/smmintrin.h | 588 +- .../lib/Headers/ppc_wrappers/tmmintrin.h | 648 +- .../lib/Headers/ppc_wrappers/x86gprintrin.h | 17 + .../lib/Headers/ppc_wrappers/x86intrin.h | 28 + .../lib/Headers/ppc_wrappers/xmmintrin.h | 2070 ++- gnu/llvm/clang/lib/Headers/prfchiintrin.h | 61 + gnu/llvm/clang/lib/Headers/prfchwintrin.h | 7 +- gnu/llvm/clang/lib/Headers/raointintrin.h | 203 + gnu/llvm/clang/lib/Headers/rdpruintrin.h | 57 + gnu/llvm/clang/lib/Headers/rdseedintrin.h | 6 +- gnu/llvm/clang/lib/Headers/rtmintrin.h | 2 +- gnu/llvm/clang/lib/Headers/smmintrin.h | 622 +- gnu/llvm/clang/lib/Headers/stdarg.h | 30 +- gnu/llvm/clang/lib/Headers/stdatomic.h | 15 +- gnu/llvm/clang/lib/Headers/stdbool.h | 17 +- gnu/llvm/clang/lib/Headers/stddef.h | 11 +- gnu/llvm/clang/lib/Headers/stdint.h | 336 +- gnu/llvm/clang/lib/Headers/stdnoreturn.h | 13 + gnu/llvm/clang/lib/Headers/tmmintrin.h | 16 +- gnu/llvm/clang/lib/Headers/uintrintrin.h | 16 +- gnu/llvm/clang/lib/Headers/unwind.h | 19 +- gnu/llvm/clang/lib/Headers/vaesintrin.h | 2 +- gnu/llvm/clang/lib/Headers/velintrin.h | 71 + gnu/llvm/clang/lib/Headers/velintrin_approx.h | 120 + gnu/llvm/clang/lib/Headers/velintrin_gen.h | 1257 ++ gnu/llvm/clang/lib/Headers/vpclmulqdqintrin.h | 12 +- gnu/llvm/clang/lib/Headers/wasm_simd128.h | 195 +- gnu/llvm/clang/lib/Headers/wmmintrin.h | 4 + gnu/llvm/clang/lib/Headers/x86gprintrin.h | 42 + gnu/llvm/clang/lib/Headers/x86intrin.h | 4 + gnu/llvm/clang/lib/Headers/xmmintrin.h | 29 +- gnu/llvm/clang/lib/Headers/xopintrin.h | 62 +- gnu/llvm/clang/lib/Index/FileIndexRecord.cpp | 19 +- gnu/llvm/clang/lib/Index/IndexBody.cpp | 24 +- gnu/llvm/clang/lib/Index/IndexDecl.cpp | 78 +- gnu/llvm/clang/lib/Index/IndexSymbol.cpp | 5 + .../clang/lib/Index/IndexTypeSourceInfo.cpp | 10 + gnu/llvm/clang/lib/Index/IndexingContext.cpp | 10 +- gnu/llvm/clang/lib/Index/IndexingContext.h | 14 +- gnu/llvm/clang/lib/Index/USRGeneration.cpp | 176 +- gnu/llvm/clang/lib/Interpreter/CMakeLists.txt | 2 + .../lib/Interpreter/IncrementalExecutor.cpp | 45 +- .../lib/Interpreter/IncrementalExecutor.h | 21 +- .../lib/Interpreter/IncrementalParser.cpp | 83 +- .../clang/lib/Interpreter/IncrementalParser.h | 13 +- .../clang/lib/Interpreter/Interpreter.cpp | 120 +- gnu/llvm/clang/lib/Lex/CMakeLists.txt | 8 +- .../lib/Lex/DependencyDirectivesScanner.cpp | 886 + gnu/llvm/clang/lib/Lex/HeaderMap.cpp | 34 +- gnu/llvm/clang/lib/Lex/HeaderSearch.cpp | 636 +- gnu/llvm/clang/lib/Lex/InitHeaderSearch.cpp | 685 + gnu/llvm/clang/lib/Lex/Lexer.cpp | 1089 +- gnu/llvm/clang/lib/Lex/LiteralSupport.cpp | 479 +- gnu/llvm/clang/lib/Lex/MacroArgs.cpp | 6 +- gnu/llvm/clang/lib/Lex/MacroInfo.cpp | 40 +- gnu/llvm/clang/lib/Lex/ModuleMap.cpp | 271 +- gnu/llvm/clang/lib/Lex/PPCallbacks.cpp | 5 +- gnu/llvm/clang/lib/Lex/PPDirectives.cpp | 709 +- gnu/llvm/clang/lib/Lex/PPExpressions.cpp | 27 +- gnu/llvm/clang/lib/Lex/PPLexerChange.cpp | 120 +- gnu/llvm/clang/lib/Lex/PPMacroExpansion.cpp | 312 +- gnu/llvm/clang/lib/Lex/Pragma.cpp | 301 +- .../clang/lib/Lex/PreprocessingRecord.cpp | 24 +- gnu/llvm/clang/lib/Lex/Preprocessor.cpp | 237 +- gnu/llvm/clang/lib/Lex/PreprocessorLexer.cpp | 5 +- gnu/llvm/clang/lib/Lex/TokenConcatenation.cpp | 2 +- gnu/llvm/clang/lib/Lex/TokenLexer.cpp | 128 +- gnu/llvm/clang/lib/Lex/UnicodeCharSets.h | 507 +- gnu/llvm/clang/lib/Parse/CMakeLists.txt | 2 + gnu/llvm/clang/lib/Parse/ParseAST.cpp | 29 +- .../clang/lib/Parse/ParseCXXInlineMethods.cpp | 59 +- gnu/llvm/clang/lib/Parse/ParseDecl.cpp | 1089 +- gnu/llvm/clang/lib/Parse/ParseDeclCXX.cpp | 1143 +- gnu/llvm/clang/lib/Parse/ParseExpr.cpp | 278 +- gnu/llvm/clang/lib/Parse/ParseExprCXX.cpp | 324 +- gnu/llvm/clang/lib/Parse/ParseHLSL.cpp | 200 + gnu/llvm/clang/lib/Parse/ParseInit.cpp | 22 +- gnu/llvm/clang/lib/Parse/ParseObjc.cpp | 156 +- gnu/llvm/clang/lib/Parse/ParseOpenMP.cpp | 1093 +- gnu/llvm/clang/lib/Parse/ParsePragma.cpp | 565 +- gnu/llvm/clang/lib/Parse/ParseStmt.cpp | 511 +- gnu/llvm/clang/lib/Parse/ParseStmtAsm.cpp | 14 +- gnu/llvm/clang/lib/Parse/ParseTemplate.cpp | 184 +- gnu/llvm/clang/lib/Parse/ParseTentative.cpp | 199 +- gnu/llvm/clang/lib/Parse/Parser.cpp | 468 +- gnu/llvm/clang/lib/Rewrite/HTMLRewrite.cpp | 11 +- gnu/llvm/clang/lib/Rewrite/Rewriter.cpp | 3 +- .../clang/lib/Sema/AnalysisBasedWarnings.cpp | 149 +- gnu/llvm/clang/lib/Sema/CMakeLists.txt | 6 + .../clang/lib/Sema/CodeCompleteConsumer.cpp | 122 +- gnu/llvm/clang/lib/Sema/DeclSpec.cpp | 69 +- .../clang/lib/Sema/HLSLExternalSemaSource.cpp | 513 + .../clang/lib/Sema/IdentifierResolver.cpp | 14 +- gnu/llvm/clang/lib/Sema/JumpDiagnostics.cpp | 19 +- .../lib/Sema/MultiplexExternalSemaSource.cpp | 24 +- gnu/llvm/clang/lib/Sema/OpenCLBuiltins.td | 650 +- gnu/llvm/clang/lib/Sema/ParsedAttr.cpp | 75 +- gnu/llvm/clang/lib/Sema/Scope.cpp | 85 +- gnu/llvm/clang/lib/Sema/ScopeInfo.cpp | 11 +- gnu/llvm/clang/lib/Sema/Sema.cpp | 420 +- gnu/llvm/clang/lib/Sema/SemaAccess.cpp | 42 +- gnu/llvm/clang/lib/Sema/SemaAttr.cpp | 281 +- gnu/llvm/clang/lib/Sema/SemaAvailability.cpp | 40 +- gnu/llvm/clang/lib/Sema/SemaCUDA.cpp | 82 +- gnu/llvm/clang/lib/Sema/SemaCXXScopeSpec.cpp | 41 +- gnu/llvm/clang/lib/Sema/SemaCast.cpp | 136 +- gnu/llvm/clang/lib/Sema/SemaCodeComplete.cpp | 893 +- gnu/llvm/clang/lib/Sema/SemaConcept.cpp | 763 +- gnu/llvm/clang/lib/Sema/SemaCoroutine.cpp | 809 +- gnu/llvm/clang/lib/Sema/SemaDecl.cpp | 3248 ++-- gnu/llvm/clang/lib/Sema/SemaDeclObjC.cpp | 232 +- gnu/llvm/clang/lib/Sema/SemaExceptionSpec.cpp | 53 +- gnu/llvm/clang/lib/Sema/SemaExpr.cpp | 2987 +++- gnu/llvm/clang/lib/Sema/SemaExprCXX.cpp | 912 +- gnu/llvm/clang/lib/Sema/SemaExprMember.cpp | 85 +- gnu/llvm/clang/lib/Sema/SemaExprObjC.cpp | 144 +- gnu/llvm/clang/lib/Sema/SemaFixItUtils.cpp | 6 +- gnu/llvm/clang/lib/Sema/SemaHLSL.cpp | 34 + gnu/llvm/clang/lib/Sema/SemaInit.cpp | 610 +- gnu/llvm/clang/lib/Sema/SemaLambda.cpp | 263 +- gnu/llvm/clang/lib/Sema/SemaLookup.cpp | 635 +- gnu/llvm/clang/lib/Sema/SemaModule.cpp | 488 +- gnu/llvm/clang/lib/Sema/SemaObjCProperty.cpp | 27 +- gnu/llvm/clang/lib/Sema/SemaOpenMP.cpp | 4114 ++++- gnu/llvm/clang/lib/Sema/SemaOverload.cpp | 1468 +- gnu/llvm/clang/lib/Sema/SemaPseudoObject.cpp | 10 +- .../clang/lib/Sema/SemaRISCVVectorLookup.cpp | 440 + gnu/llvm/clang/lib/Sema/SemaSYCL.cpp | 118 +- gnu/llvm/clang/lib/Sema/SemaStmt.cpp | 363 +- gnu/llvm/clang/lib/Sema/SemaStmtAsm.cpp | 105 +- gnu/llvm/clang/lib/Sema/SemaStmtAttr.cpp | 129 +- gnu/llvm/clang/lib/Sema/SemaTemplate.cpp | 1578 +- .../clang/lib/Sema/SemaTemplateDeduction.cpp | 2315 +-- .../lib/Sema/SemaTemplateInstantiate.cpp | 1098 +- .../lib/Sema/SemaTemplateInstantiateDecl.cpp | 769 +- .../clang/lib/Sema/SemaTemplateVariadic.cpp | 116 +- gnu/llvm/clang/lib/Sema/SemaType.cpp | 1304 +- gnu/llvm/clang/lib/Sema/TreeTransform.h | 1262 +- gnu/llvm/clang/lib/Sema/TypeLocBuilder.cpp | 29 +- gnu/llvm/clang/lib/Sema/TypeLocBuilder.h | 12 +- gnu/llvm/clang/lib/Sema/UsedDeclVisitor.h | 20 +- .../clang/lib/Serialization/ASTCommon.cpp | 15 +- .../clang/lib/Serialization/ASTReader.cpp | 3597 ++--- .../clang/lib/Serialization/ASTReaderDecl.cpp | 941 +- .../lib/Serialization/ASTReaderInternals.h | 1 - .../clang/lib/Serialization/ASTReaderStmt.cpp | 291 +- .../clang/lib/Serialization/ASTWriter.cpp | 1091 +- .../clang/lib/Serialization/ASTWriterDecl.cpp | 260 +- .../clang/lib/Serialization/ASTWriterStmt.cpp | 160 +- .../clang/lib/Serialization/CMakeLists.txt | 1 + .../clang/lib/Serialization/GeneratePCH.cpp | 3 +- .../lib/Serialization/GlobalModuleIndex.cpp | 2 +- .../lib/Serialization/ModuleFileExtension.cpp | 10 +- .../clang/lib/Serialization/ModuleManager.cpp | 54 +- .../Checkers/AnalyzerStatsChecker.cpp | 10 +- .../Checkers/ArrayBoundChecker.cpp | 4 +- .../Checkers/ArrayBoundCheckerV2.cpp | 28 +- .../Checkers/BasicObjCFoundationChecks.cpp | 64 +- .../BlockInCriticalSectionChecker.cpp | 50 +- .../Checkers/BoolAssignmentChecker.cpp | 19 +- .../Checkers/BuiltinFunctionChecker.cpp | 3 +- .../StaticAnalyzer/Checkers/CMakeLists.txt | 8 + .../Checkers/CStringChecker.cpp | 349 +- .../Checkers/CallAndMessageChecker.cpp | 2 +- .../Checkers/CastValueChecker.cpp | 19 +- .../Checkers/CheckObjCDealloc.cpp | 11 +- .../Checkers/CheckObjCInstMethSignature.cpp | 10 +- .../Checkers/CheckSecuritySyntaxOnly.cpp | 35 +- .../StaticAnalyzer/Checkers/ChrootChecker.cpp | 9 +- .../StaticAnalyzer/Checkers/CloneChecker.cpp | 2 +- .../Checkers/ContainerModeling.cpp | 50 +- .../Checkers/ConversionChecker.cpp | 33 +- .../Checkers/DeadStoresChecker.cpp | 42 +- .../StaticAnalyzer/Checkers/DebugCheckers.cpp | 2 +- .../Checkers/DebugContainerModeling.cpp | 9 +- .../Checkers/DebugIteratorModeling.cpp | 13 +- .../Checkers/DereferenceChecker.cpp | 51 +- .../Checkers/DirectIvarAssignment.cpp | 4 +- .../Checkers/DivZeroChecker.cpp | 5 +- .../Checkers/DynamicTypePropagation.cpp | 12 +- .../Checkers/EnumCastOutOfRangeChecker.cpp | 11 +- .../StaticAnalyzer/Checkers/ErrnoChecker.cpp | 250 + .../StaticAnalyzer/Checkers/ErrnoModeling.cpp | 346 + .../StaticAnalyzer/Checkers/ErrnoModeling.h | 132 + .../Checkers/ErrnoTesterChecker.cpp | 185 + .../Checkers/ExprInspectionChecker.cpp | 147 +- .../Checkers/FuchsiaHandleChecker.cpp | 19 +- .../StaticAnalyzer/Checkers/GTestChecker.cpp | 22 +- .../Checkers/GenericTaintChecker.cpp | 1533 +- .../Checkers/InnerPointerChecker.cpp | 38 +- .../lib/StaticAnalyzer/Checkers/Iterator.cpp | 4 +- .../lib/StaticAnalyzer/Checkers/Iterator.h | 8 +- .../Checkers/IteratorModeling.cpp | 11 +- .../Checkers/IteratorRangeChecker.cpp | 2 +- .../Checkers/IvarInvalidationChecker.cpp | 7 +- .../Checkers/LLVMConventionsChecker.cpp | 2 +- .../Checkers/LocalizationChecker.cpp | 20 +- .../StaticAnalyzer/Checkers/MIGChecker.cpp | 12 +- .../Checkers/MPI-Checker/MPIChecker.cpp | 2 +- .../Checkers/MacOSKeychainAPIChecker.cpp | 8 +- .../StaticAnalyzer/Checkers/MallocChecker.cpp | 583 +- .../MallocOverflowSecurityChecker.cpp | 75 +- .../Checkers/MallocSizeofChecker.cpp | 6 +- .../Checkers/MismatchedIteratorChecker.cpp | 6 +- .../Checkers/MmapWriteExecChecker.cpp | 10 +- .../StaticAnalyzer/Checkers/MoveChecker.cpp | 26 +- .../Checkers/NSErrorChecker.cpp | 13 +- .../Checkers/NoReturnFunctionChecker.cpp | 8 +- .../Checkers/NonNullParamChecker.cpp | 6 +- .../NonnullGlobalConstantsChecker.cpp | 21 +- .../Checkers/NullabilityChecker.cpp | 142 +- .../NumberObjectConversionChecker.cpp | 23 +- .../Checkers/ObjCAtSyncChecker.cpp | 2 +- .../Checkers/ObjCAutoreleaseWriteChecker.cpp | 6 +- .../Checkers/ObjCContainersASTChecker.cpp | 8 +- .../Checkers/ObjCContainersChecker.cpp | 7 +- .../Checkers/ObjCSelfInitChecker.cpp | 22 +- .../Checkers/PaddingChecker.cpp | 8 +- .../Checkers/PthreadLockChecker.cpp | 83 +- .../RetainCountChecker/RetainCountChecker.cpp | 30 +- .../RetainCountDiagnostics.cpp | 54 +- .../Checkers/ReturnPointerRangeChecker.cpp | 53 +- .../Checkers/ReturnValueChecker.cpp | 17 +- .../Checkers/STLAlgorithmModeling.cpp | 5 +- .../Checkers/SimpleStreamChecker.cpp | 21 +- .../lib/StaticAnalyzer/Checkers/SmartPtr.h | 2 - .../Checkers/SmartPtrModeling.cpp | 62 +- .../Checkers/StackAddrEscapeChecker.cpp | 100 +- .../Checkers/StdLibraryFunctionsChecker.cpp | 1148 +- .../StaticAnalyzer/Checkers/StreamChecker.cpp | 274 +- .../StaticAnalyzer/Checkers/StringChecker.cpp | 105 + .../lib/StaticAnalyzer/Checkers/Taint.cpp | 9 +- .../Checkers/TaintTesterChecker.cpp | 21 +- .../Checkers/TestAfterDivZeroChecker.cpp | 5 +- .../Checkers/TrustReturnsNonnullChecker.cpp | 60 + .../Checkers/UndefBranchChecker.cpp | 3 +- .../Checkers/UndefCapturedBlockVarChecker.cpp | 5 +- .../Checkers/UndefResultChecker.cpp | 9 +- .../Checkers/UndefinedAssignmentChecker.cpp | 2 +- .../Checkers/UndefinedNewArraySizeChecker.cpp | 80 + .../UninitializedObjectChecker.cpp | 22 +- .../UninitializedPointee.cpp | 51 +- .../Checkers/UnixAPIChecker.cpp | 24 +- .../Checkers/UnreachableCodeChecker.cpp | 7 +- .../Checkers/VLASizeChecker.cpp | 10 +- .../StaticAnalyzer/Checkers/ValistChecker.cpp | 54 +- .../StaticAnalyzer/Checkers/VforkChecker.cpp | 29 +- .../Checkers/WebKit/ASTUtils.cpp | 5 +- .../StaticAnalyzer/Checkers/WebKit/ASTUtils.h | 6 +- .../WebKit/NoUncountedMembersChecker.cpp | 9 +- .../Checkers/WebKit/PtrTypesSemantics.cpp | 49 +- .../Checkers/WebKit/PtrTypesSemantics.h | 22 +- .../WebKit/RefCntblBaseVirtualDtorChecker.cpp | 4 +- .../WebKit/UncountedCallArgsChecker.cpp | 6 +- .../WebKit/UncountedLambdaCapturesChecker.cpp | 13 +- .../WebKit/UncountedLocalVarsChecker.cpp | 3 +- .../clang/lib/StaticAnalyzer/Checkers/Yaml.h | 13 +- .../Checkers/cert/InvalidPtrChecker.cpp | 276 + .../Checkers/cert/PutenvWithAutoChecker.cpp | 5 +- .../StaticAnalyzer/Core/AnalyzerOptions.cpp | 74 +- .../lib/StaticAnalyzer/Core/BugReporter.cpp | 124 +- .../Core/BugReporterVisitors.cpp | 825 +- .../lib/StaticAnalyzer/Core/CMakeLists.txt | 1 + .../StaticAnalyzer/Core/CallDescription.cpp | 169 + .../lib/StaticAnalyzer/Core/CallEvent.cpp | 213 +- .../StaticAnalyzer/Core/CheckerContext.cpp | 36 +- .../StaticAnalyzer/Core/CheckerHelpers.cpp | 12 +- .../StaticAnalyzer/Core/CheckerManager.cpp | 33 +- .../StaticAnalyzer/Core/ConstraintManager.cpp | 80 + .../lib/StaticAnalyzer/Core/CoreEngine.cpp | 90 +- .../lib/StaticAnalyzer/Core/DynamicExtent.cpp | 1 + .../lib/StaticAnalyzer/Core/DynamicType.cpp | 8 +- .../lib/StaticAnalyzer/Core/Environment.cpp | 7 +- .../lib/StaticAnalyzer/Core/ExplodedGraph.cpp | 7 +- .../lib/StaticAnalyzer/Core/ExprEngine.cpp | 942 +- .../lib/StaticAnalyzer/Core/ExprEngineC.cpp | 80 +- .../lib/StaticAnalyzer/Core/ExprEngineCXX.cpp | 354 +- .../Core/ExprEngineCallAndReturn.cpp | 271 +- .../StaticAnalyzer/Core/ExprEngineObjC.cpp | 4 +- .../StaticAnalyzer/Core/HTMLDiagnostics.cpp | 643 +- .../lib/StaticAnalyzer/Core/LoopUnrolling.cpp | 13 +- .../lib/StaticAnalyzer/Core/LoopWidening.cpp | 3 +- .../lib/StaticAnalyzer/Core/MemRegion.cpp | 145 +- .../StaticAnalyzer/Core/PlistDiagnostics.cpp | 15 +- .../lib/StaticAnalyzer/Core/ProgramState.cpp | 52 +- .../Core/RangeConstraintManager.cpp | 1200 +- .../Core/RangedConstraintManager.cpp | 86 +- .../lib/StaticAnalyzer/Core/RegionStore.cpp | 819 +- .../Core/SMTConstraintManager.cpp | 7 +- .../lib/StaticAnalyzer/Core/SValBuilder.cpp | 958 +- .../clang/lib/StaticAnalyzer/Core/SVals.cpp | 93 +- .../StaticAnalyzer/Core/SarifDiagnostics.cpp | 394 +- .../Core/SimpleConstraintManager.cpp | 17 +- .../StaticAnalyzer/Core/SimpleSValBuilder.cpp | 342 +- .../clang/lib/StaticAnalyzer/Core/Store.cpp | 76 +- .../lib/StaticAnalyzer/Core/SymbolManager.cpp | 73 +- .../StaticAnalyzer/Core/TextDiagnostics.cpp | 6 +- .../lib/StaticAnalyzer/Core/WorkList.cpp | 16 +- .../Frontend/AnalysisConsumer.cpp | 139 +- .../Frontend/AnalyzerHelpFlags.cpp | 5 +- .../Frontend/CheckerRegistry.cpp | 5 +- .../StaticAnalyzer/Frontend/ModelInjector.h | 3 - gnu/llvm/clang/lib/StaticAnalyzer/README.txt | 6 +- gnu/llvm/clang/lib/Support/CMakeLists.txt | 32 + .../lib/Support/RISCVVIntrinsicUtils.cpp | 1087 ++ gnu/llvm/clang/lib/Testing/CMakeLists.txt | 28 +- .../clang/lib/Testing/CommandLineArgs.cpp | 42 + gnu/llvm/clang/lib/Testing/TestAST.cpp | 163 + .../clang/lib/Tooling/ASTDiff/ASTDiff.cpp | 15 +- .../clang/lib/Tooling/AllTUsExecution.cpp | 2 +- .../clang/lib/Tooling/ArgumentsAdjusters.cpp | 2 +- gnu/llvm/clang/lib/Tooling/CMakeLists.txt | 11 +- .../clang/lib/Tooling/CommonOptionsParser.cpp | 10 +- .../clang/lib/Tooling/Core/Replacement.cpp | 8 +- .../Tooling/DependencyScanning/CMakeLists.txt | 2 + .../DependencyScanningFilesystem.cpp | 374 +- .../DependencyScanningService.cpp | 8 +- .../DependencyScanningTool.cpp | 358 +- .../DependencyScanningWorker.cpp | 416 +- .../DependencyScanning/ModuleDepCollector.cpp | 572 +- .../Tooling/DumpTool/ASTSrcLocProcessor.cpp | 2 +- .../lib/Tooling/DumpTool/ASTSrcLocProcessor.h | 2 +- .../lib/Tooling/DumpTool/ClangSrcLocDump.cpp | 10 +- ...ExpandResponseFilesCompilationDatabase.cpp | 9 +- .../lib/Tooling/Inclusions/CMakeLists.txt | 3 + .../lib/Tooling/Inclusions/HeaderAnalysis.cpp | 119 + .../lib/Tooling/Inclusions/HeaderIncludes.cpp | 37 +- .../Tooling/Inclusions/Stdlib/CMakeLists.txt | 6 + .../Inclusions/Stdlib/StandardLibrary.cpp | 165 + .../InterpolatingCompilationDatabase.cpp | 26 +- .../lib/Tooling/JSONCompilationDatabase.cpp | 22 +- .../lib/Tooling/Refactoring/ASTSelection.cpp | 19 +- .../Refactoring/ASTSelectionRequirements.cpp | 8 +- .../Tooling/Refactoring/Extract/Extract.cpp | 3 +- .../Refactoring/Extract/SourceExtraction.cpp | 3 +- .../Refactoring/Rename/USRFindingAction.cpp | 6 +- .../clang/lib/Tooling/Syntax/BuildTree.cpp | 70 +- .../clang/lib/Tooling/Syntax/CMakeLists.txt | 1 + .../Tooling/Syntax/ComputeReplacements.cpp | 49 +- .../clang/lib/Tooling/Syntax/Mutations.cpp | 6 +- gnu/llvm/clang/lib/Tooling/Syntax/Nodes.cpp | 2 +- .../clang/lib/Tooling/Syntax/Synthesis.cpp | 34 +- .../Syntax/TokenBufferTokenManager.cpp | 25 + gnu/llvm/clang/lib/Tooling/Syntax/Tokens.cpp | 261 +- gnu/llvm/clang/lib/Tooling/Syntax/Tree.cpp | 61 +- gnu/llvm/clang/lib/Tooling/Tooling.cpp | 53 +- .../clang/lib/Tooling/Transformer/Parsing.cpp | 17 +- .../lib/Tooling/Transformer/RewriteRule.cpp | 93 +- .../lib/Tooling/Transformer/SourceCode.cpp | 92 +- .../Transformer/SourceCodeBuilders.cpp | 113 +- .../clang/lib/Tooling/Transformer/Stencil.cpp | 153 +- .../lib/Tooling/Transformer/Transformer.cpp | 58 +- gnu/llvm/clang/runtime/CMakeLists.txt | 12 +- gnu/llvm/clang/tools/CMakeLists.txt | 8 +- .../clang/tools/amdgpu-arch/AMDGPUArch.cpp | 89 +- .../clang/tools/amdgpu-arch/CMakeLists.txt | 17 +- .../clang/tools/c-index-test/CMakeLists.txt | 9 +- .../clang/tools/c-index-test/c-index-test.c | 109 +- .../clang/tools/c-index-test/core_main.cpp | 6 +- .../clang/tools/clang-check/ClangCheck.cpp | 51 +- .../ClangExtDefMapGen.cpp | 106 +- .../clang/tools/clang-format/.clang-format | 4 + .../clang/tools/clang-format/CMakeLists.txt | 20 +- .../clang/tools/clang-format/ClangFormat.cpp | 128 +- .../tools/clang-format/clang-format-diff.py | 19 +- .../clang/tools/clang-format/clang-format.el | 2 +- .../clang/tools/clang-format/clang-format.py | 10 +- .../clang/tools/clang-format/git-clang-format | 161 +- .../clang/tools/clang-fuzzer/CMakeLists.txt | 3 +- .../clang-fuzzer/dictionary/CMakeLists.txt | 4 + .../clang-fuzzer/dictionary/dictionary.c | 57 + .../fuzzer-initialize/fuzzer_initialize.cpp | 2 - .../clang-fuzzer/handle-cxx/CMakeLists.txt | 2 + .../clang-fuzzer/handle-llvm/CMakeLists.txt | 3 + .../clang-fuzzer/handle-llvm/handle_llvm.cpp | 106 +- .../clang-fuzzer/proto-to-cxx/CMakeLists.txt | 2 + .../tools/clang-import-test/CMakeLists.txt | 1 + .../clang-import-test/clang-import-test.cpp | 21 +- .../tools/clang-linker-wrapper/CMakeLists.txt | 45 + .../ClangLinkerWrapper.cpp | 1442 ++ .../clang-linker-wrapper/LinkerWrapperOpts.td | 124 + .../clang-linker-wrapper/OffloadWrapper.cpp | 622 + .../clang-linker-wrapper/OffloadWrapper.h | 28 + .../clang-offload-bundler/CMakeLists.txt | 11 +- .../ClangOffloadBundler.cpp | 1412 +- .../clang-offload-packager/CMakeLists.txt | 19 + .../ClangOffloadPackager.cpp | 221 + .../tools/clang-refactor/ClangRefactor.cpp | 18 +- .../tools/clang-refactor/TestSupport.cpp | 15 +- .../clang/tools/clang-refactor/TestSupport.h | 7 +- .../clang/tools/clang-rename/CMakeLists.txt | 8 +- .../clang/tools/clang-rename/ClangRename.cpp | 6 +- .../clang/tools/clang-repl/CMakeLists.txt | 8 +- gnu/llvm/clang/tools/clang-repl/ClangRepl.cpp | 50 +- .../tools/clang-scan-deps/CMakeLists.txt | 2 + .../tools/clang-scan-deps/ClangScanDeps.cpp | 550 +- .../clang/tools/clang-shlib/CMakeLists.txt | 2 +- gnu/llvm/clang/tools/diag-build/diag-build.sh | 2 +- gnu/llvm/clang/tools/diagtool/DiagTool.cpp | 1 + .../clang/tools/diagtool/DiagnosticNames.cpp | 15 +- .../clang/tools/diagtool/FindDiagnosticID.cpp | 9 +- .../tools/diagtool/ShowEnabledWarnings.cpp | 7 +- gnu/llvm/clang/tools/diagtool/TreeView.cpp | 6 +- gnu/llvm/clang/tools/driver/CMakeLists.txt | 14 +- gnu/llvm/clang/tools/driver/cc1_main.cpp | 25 +- gnu/llvm/clang/tools/driver/cc1as_main.cpp | 65 +- .../tools/driver/cc1gen_reproducer_main.cpp | 7 +- gnu/llvm/clang/tools/driver/driver.cpp | 221 +- .../include-mapping/cppreference_parser.py | 188 + .../clang/tools/include-mapping/gen_std.py | 126 + gnu/llvm/clang/tools/include-mapping/test.py | 155 + gnu/llvm/clang/tools/libclang/BuildSystem.cpp | 1 + gnu/llvm/clang/tools/libclang/CIndex.cpp | 446 +- .../tools/libclang/CIndexCodeCompletion.cpp | 14 +- gnu/llvm/clang/tools/libclang/CIndexHigh.cpp | 4 +- .../tools/libclang/CIndexInclusionStack.cpp | 4 +- gnu/llvm/clang/tools/libclang/CIndexer.cpp | 22 +- gnu/llvm/clang/tools/libclang/CMakeLists.txt | 24 +- gnu/llvm/clang/tools/libclang/CXCursor.cpp | 133 +- .../clang/tools/libclang/CXExtractAPI.cpp | 151 + .../tools/libclang/CXIndexDataConsumer.cpp | 27 +- .../tools/libclang/CXIndexDataConsumer.h | 15 +- .../tools/libclang/CXLoadedDiagnostic.cpp | 2 +- gnu/llvm/clang/tools/libclang/CXString.cpp | 11 +- gnu/llvm/clang/tools/libclang/CXType.cpp | 44 +- gnu/llvm/clang/tools/libclang/CXType.h | 3 - gnu/llvm/clang/tools/libclang/CursorVisitor.h | 14 +- .../tools/libclang/FatalErrorHandler.cpp | 5 +- gnu/llvm/clang/tools/libclang/Indexing.cpp | 16 +- gnu/llvm/clang/tools/libclang/libclang.map | 13 + .../clang/tools/nvptx-arch/CMakeLists.txt | 26 + gnu/llvm/clang/tools/nvptx-arch/NVPTXArch.cpp | 116 + .../clang/tools/scan-build-py/CMakeLists.txt | 18 +- .../tools/scan-build-py/bin/analyze-build | 2 +- .../tools/scan-build-py/bin/intercept-build | 2 +- .../clang/tools/scan-build-py/bin/scan-build | 2 +- .../tools/scan-build-py/lib/libear/ear.c | 8 +- .../scan-build-py/lib/libscanbuild/analyze.py | 12 +- .../scan-build-py/lib/libscanbuild/report.py | 2 +- .../tools/scan-build-py/libexec/analyze-c++ | 2 +- .../tools/scan-build-py/libexec/analyze-cc | 2 +- .../tools/scan-build-py/libexec/intercept-c++ | 2 +- .../tools/scan-build-py/libexec/intercept-cc | 2 +- .../clang/tools/scan-build/CMakeLists.txt | 20 +- .../clang/tools/scan-build/bin/scan-build | 48 +- .../tools/scan-build/libexec/ccc-analyzer | 11 +- .../clang/tools/scan-build/man/scan-build.1 | 6 +- gnu/llvm/clang/tools/scan-view/CMakeLists.txt | 4 +- gnu/llvm/clang/utils/ClangDataFormat.py | 21 - .../clang/utils/ClangVisualizers/clang.natvis | 20 +- gnu/llvm/clang/utils/TableGen/ASTTableGen.cpp | 5 +- gnu/llvm/clang/utils/TableGen/ASTTableGen.h | 1 + gnu/llvm/clang/utils/TableGen/CMakeLists.txt | 5 + .../TableGen/ClangASTPropertiesEmitter.cpp | 31 +- .../clang/utils/TableGen/ClangAttrEmitter.cpp | 594 +- .../ClangCommentCommandInfoEmitter.cpp | 6 + .../TableGen/ClangDiagnosticsEmitter.cpp | 69 +- .../utils/TableGen/ClangOpcodesEmitter.cpp | 14 +- .../TableGen/ClangOpenCLBuiltinEmitter.cpp | 268 +- .../utils/TableGen/ClangOptionDocEmitter.cpp | 56 +- .../utils/TableGen/ClangSACheckersEmitter.cpp | 45 +- gnu/llvm/clang/utils/TableGen/MveEmitter.cpp | 39 +- gnu/llvm/clang/utils/TableGen/NeonEmitter.cpp | 146 +- .../clang/utils/TableGen/RISCVVEmitter.cpp | 1489 +- gnu/llvm/clang/utils/TableGen/SveEmitter.cpp | 66 +- gnu/llvm/clang/utils/TableGen/TableGen.cpp | 13 + .../clang/utils/TableGen/TableGenBackends.h | 2 + gnu/llvm/clang/utils/analyzer/CmpRuns.py | 13 +- gnu/llvm/clang/utils/analyzer/Dockerfile | 8 +- gnu/llvm/clang/utils/analyzer/SATest.py | 7 +- gnu/llvm/clang/utils/analyzer/SATestBuild.py | 15 +- gnu/llvm/clang/utils/analyzer/entrypoint.py | 13 +- .../utils/analyzer/exploded-graph-rewriter.py | 97 +- gnu/llvm/clang/utils/check_cfc/check_cfc.py | 2 +- gnu/llvm/clang/utils/convert_arm_neon.py | 2 +- gnu/llvm/clang/utils/creduce-clang-crash.py | 6 +- gnu/llvm/clang/utils/hmaptool/CMakeLists.txt | 18 +- gnu/llvm/clang/utils/hmaptool/hmaptool | 19 +- gnu/llvm/clang/utils/make-ast-dump-check.sh | 2 +- gnu/llvm/clang/utils/module-deps-to-rsp.py | 11 +- .../clang/utils/perf-training/CMakeLists.txt | 10 +- gnu/llvm/clang/utils/perf-training/lit.cfg | 2 +- .../clang/utils/perf-training/lit.site.cfg.in | 13 +- .../utils/perf-training/order-files.lit.cfg | 2 +- .../perf-training/order-files.lit.site.cfg.in | 13 +- .../clang/utils/perf-training/perf-helper.py | 20 +- .../www/analyzer/checker_dev_manual.html | 45 +- gnu/llvm/clang/www/analyzer/installation.html | 2 +- gnu/llvm/clang/www/analyzer/menu.html.incl | 4 +- gnu/llvm/clang/www/c_dr_status.html | 2686 +++ gnu/llvm/clang/www/c_status.html | 917 +- gnu/llvm/clang/www/cxx_dr_status.html | 2696 +++- gnu/llvm/clang/www/cxx_status.html | 283 +- gnu/llvm/clang/www/demo/index.cgi | 2 +- gnu/llvm/clang/www/get_involved.html | 29 +- gnu/llvm/clang/www/get_started.html | 12 +- gnu/llvm/clang/www/hacking.html | 36 + gnu/llvm/clang/www/make_cxx_dr_status | 184 +- gnu/llvm/clang/www/menu.html.incl | 5 +- gnu/llvm/clang/www/related.html | 4 +- 1697 files changed, 216987 insertions(+), 80443 deletions(-) create mode 100644 gnu/llvm/clang/CodeOwners.rst create mode 100644 gnu/llvm/clang/cmake/caches/BOLT-PGO.cmake create mode 100644 gnu/llvm/clang/cmake/caches/BOLT.cmake create mode 100644 gnu/llvm/clang/cmake/caches/HLSL.cmake create mode 100644 gnu/llvm/clang/cmake/modules/AddGRPC.cmake create mode 100644 gnu/llvm/clang/cmake/modules/ClangConfigVersion.cmake.in create mode 100644 gnu/llvm/clang/docs/ClangLinkerWrapper.rst create mode 100644 gnu/llvm/clang/docs/ClangOffloadPackager.rst create mode 100644 gnu/llvm/clang/docs/ClangRepl.rst create mode 100644 gnu/llvm/clang/docs/ClangRepl_design.png create mode 100644 gnu/llvm/clang/docs/ClangTransformerTutorial.rst create mode 100644 gnu/llvm/clang/docs/CodeOwners.rst create mode 100644 gnu/llvm/clang/docs/DataFlowAnalysisIntro.md create mode 100644 gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/CFGExample.svg create mode 100644 gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/CFGJoinRule.svg create mode 100644 gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/DefinitiveInitializationLattice.svg create mode 100644 gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/IntegerSetsFiniteLattice.svg create mode 100644 gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/IntegerSetsInfiniteLattice.svg create mode 100644 gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/OutputParameterIdentificationLattice.svg create mode 100644 gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/UniquePtrLattice.svg create mode 100644 gnu/llvm/clang/docs/DebuggingCoroutines.rst create mode 100644 gnu/llvm/clang/docs/HLSL/EntryFunctions.rst create mode 100644 gnu/llvm/clang/docs/HLSL/HLSLDocs.rst create mode 100644 gnu/llvm/clang/docs/HLSL/HLSLIRReference.rst create mode 100644 gnu/llvm/clang/docs/HLSL/HLSLSupport.rst create mode 100644 gnu/llvm/clang/docs/HLSL/ResourceTypes.rst create mode 100644 gnu/llvm/clang/docs/MisExpect.rst create mode 100644 gnu/llvm/clang/docs/OffloadingDesign.rst create mode 100644 gnu/llvm/clang/docs/StandardCPlusPlusModules.rst create mode 100644 gnu/llvm/clang/docs/analyzer/user-docs/TaintAnalysisConfiguration.rst create mode 100644 gnu/llvm/clang/docs/tools/clang-formatted-files.txt create mode 100755 gnu/llvm/clang/docs/tools/dump_format_help.py create mode 100644 gnu/llvm/clang/docs/tools/plurals.txt create mode 100644 gnu/llvm/clang/examples/PluginsOrder/CMakeLists.txt create mode 100644 gnu/llvm/clang/examples/PluginsOrder/PluginsOrder.cpp create mode 100644 gnu/llvm/clang/include/clang-c/CXDiagnostic.h create mode 100644 gnu/llvm/clang/include/clang-c/CXFile.h create mode 100644 gnu/llvm/clang/include/clang-c/CXSourceLocation.h create mode 100644 gnu/llvm/clang/include/clang/AST/ASTImportError.h create mode 100644 gnu/llvm/clang/include/clang/AST/ODRDiagsEmitter.h create mode 100644 gnu/llvm/clang/include/clang/AST/Randstruct.h create mode 100644 gnu/llvm/clang/include/clang/Analysis/Analyses/UnsafeBufferUsage.h create mode 100644 gnu/llvm/clang/include/clang/Analysis/Analyses/UnsafeBufferUsageGadgets.def create mode 100644 gnu/llvm/clang/include/clang/Analysis/FlowSensitive/CFGMatchSwitch.h create mode 100644 gnu/llvm/clang/include/clang/Analysis/FlowSensitive/ControlFlowContext.h create mode 100644 gnu/llvm/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h create mode 100644 gnu/llvm/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysisContext.h create mode 100644 gnu/llvm/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h create mode 100644 gnu/llvm/clang/include/clang/Analysis/FlowSensitive/DataflowLattice.h create mode 100644 gnu/llvm/clang/include/clang/Analysis/FlowSensitive/DebugSupport.h create mode 100644 gnu/llvm/clang/include/clang/Analysis/FlowSensitive/MapLattice.h create mode 100644 gnu/llvm/clang/include/clang/Analysis/FlowSensitive/MatchSwitch.h create mode 100644 gnu/llvm/clang/include/clang/Analysis/FlowSensitive/Models/ChromiumCheckModel.h create mode 100644 gnu/llvm/clang/include/clang/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.h create mode 100644 gnu/llvm/clang/include/clang/Analysis/FlowSensitive/NoopAnalysis.h create mode 100644 gnu/llvm/clang/include/clang/Analysis/FlowSensitive/NoopLattice.h create mode 100644 gnu/llvm/clang/include/clang/Analysis/FlowSensitive/Solver.h create mode 100644 gnu/llvm/clang/include/clang/Analysis/FlowSensitive/StorageLocation.h create mode 100644 gnu/llvm/clang/include/clang/Analysis/FlowSensitive/Transfer.h create mode 100644 gnu/llvm/clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h create mode 100644 gnu/llvm/clang/include/clang/Analysis/FlowSensitive/Value.h create mode 100644 gnu/llvm/clang/include/clang/Analysis/FlowSensitive/WatchedLiteralsSolver.h create mode 100644 gnu/llvm/clang/include/clang/Basic/BuiltinHeaders.def create mode 100644 gnu/llvm/clang/include/clang/Basic/BuiltinsAArch64NeonSVEBridge.def create mode 100644 gnu/llvm/clang/include/clang/Basic/BuiltinsAArch64NeonSVEBridge_cg.def create mode 100644 gnu/llvm/clang/include/clang/Basic/BuiltinsLoongArch.def create mode 100644 gnu/llvm/clang/include/clang/Basic/BuiltinsRISCVVector.def create mode 100644 gnu/llvm/clang/include/clang/Basic/BuiltinsVE.def create mode 100644 gnu/llvm/clang/include/clang/Basic/BuiltinsVEVL.gen.def create mode 100644 gnu/llvm/clang/include/clang/Basic/CLWarnings.h create mode 100644 gnu/llvm/clang/include/clang/Basic/CustomizableOptional.h create mode 100644 gnu/llvm/clang/include/clang/Basic/HLSLRuntime.h create mode 100644 gnu/llvm/clang/include/clang/Basic/HeaderInclude.h create mode 100644 gnu/llvm/clang/include/clang/Basic/MakeSupport.h create mode 100644 gnu/llvm/clang/include/clang/Basic/Sarif.h create mode 100644 gnu/llvm/clang/include/clang/Basic/TransformTypeTraits.def create mode 100644 gnu/llvm/clang/include/clang/Driver/OffloadBundler.h create mode 100644 gnu/llvm/clang/include/clang/ExtractAPI/API.h create mode 100644 gnu/llvm/clang/include/clang/ExtractAPI/APIIgnoresList.h create mode 100644 gnu/llvm/clang/include/clang/ExtractAPI/AvailabilityInfo.h create mode 100644 gnu/llvm/clang/include/clang/ExtractAPI/DeclarationFragments.h create mode 100644 gnu/llvm/clang/include/clang/ExtractAPI/ExtractAPIVisitor.h create mode 100644 gnu/llvm/clang/include/clang/ExtractAPI/FrontendActions.h create mode 100644 gnu/llvm/clang/include/clang/ExtractAPI/Serialization/SerializerBase.h create mode 100644 gnu/llvm/clang/include/clang/ExtractAPI/Serialization/SymbolGraphSerializer.h create mode 100644 gnu/llvm/clang/include/clang/Format/.clang-format create mode 100644 gnu/llvm/clang/include/clang/Frontend/SARIFDiagnostic.h create mode 100644 gnu/llvm/clang/include/clang/Frontend/SARIFDiagnosticPrinter.h create mode 100644 gnu/llvm/clang/include/clang/Lex/DependencyDirectivesScanner.h create mode 100644 gnu/llvm/clang/include/clang/Sema/HLSLExternalSemaSource.h create mode 100644 gnu/llvm/clang/include/clang/Sema/RISCVIntrinsicManager.h create mode 100644 gnu/llvm/clang/include/clang/Serialization/SourceLocationEncoding.h create mode 100644 gnu/llvm/clang/include/clang/StaticAnalyzer/Checkers/Taint.h create mode 100644 gnu/llvm/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallDescription.h create mode 100644 gnu/llvm/clang/include/clang/Support/RISCVVIntrinsicUtils.h create mode 100644 gnu/llvm/clang/include/clang/Testing/TestAST.h create mode 100644 gnu/llvm/clang/include/clang/Tooling/Inclusions/CSymbolMap.inc create mode 100644 gnu/llvm/clang/include/clang/Tooling/Inclusions/HeaderAnalysis.h create mode 100644 gnu/llvm/clang/include/clang/Tooling/Inclusions/StandardLibrary.h create mode 100644 gnu/llvm/clang/include/clang/Tooling/Inclusions/StdSymbolMap.inc create mode 100644 gnu/llvm/clang/include/clang/Tooling/Syntax/TokenBufferTokenManager.h create mode 100644 gnu/llvm/clang/include/clang/Tooling/Syntax/TokenManager.h create mode 100644 gnu/llvm/clang/lib/AST/AttrDocTable.cpp create mode 100644 gnu/llvm/clang/lib/AST/ODRDiagsEmitter.cpp create mode 100644 gnu/llvm/clang/lib/AST/Randstruct.cpp create mode 100644 gnu/llvm/clang/lib/Analysis/FlowSensitive/CMakeLists.txt create mode 100644 gnu/llvm/clang/lib/Analysis/FlowSensitive/ControlFlowContext.cpp create mode 100644 gnu/llvm/clang/lib/Analysis/FlowSensitive/DataflowAnalysisContext.cpp create mode 100644 gnu/llvm/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp create mode 100644 gnu/llvm/clang/lib/Analysis/FlowSensitive/DebugSupport.cpp create mode 100644 gnu/llvm/clang/lib/Analysis/FlowSensitive/Models/CMakeLists.txt create mode 100644 gnu/llvm/clang/lib/Analysis/FlowSensitive/Models/ChromiumCheckModel.cpp create mode 100644 gnu/llvm/clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp create mode 100644 gnu/llvm/clang/lib/Analysis/FlowSensitive/Transfer.cpp create mode 100644 gnu/llvm/clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp create mode 100644 gnu/llvm/clang/lib/Analysis/FlowSensitive/Value.cpp create mode 100644 gnu/llvm/clang/lib/Analysis/FlowSensitive/WatchedLiteralsSolver.cpp create mode 100644 gnu/llvm/clang/lib/Analysis/UnsafeBufferUsage.cpp create mode 100644 gnu/llvm/clang/lib/Basic/BuiltinTargetFeatures.h create mode 100644 gnu/llvm/clang/lib/Basic/CLWarnings.cpp create mode 100644 gnu/llvm/clang/lib/Basic/MakeSupport.cpp create mode 100644 gnu/llvm/clang/lib/Basic/Sarif.cpp create mode 100644 gnu/llvm/clang/lib/Basic/Targets/CSKY.cpp create mode 100644 gnu/llvm/clang/lib/Basic/Targets/CSKY.h create mode 100644 gnu/llvm/clang/lib/Basic/Targets/DirectX.cpp create mode 100644 gnu/llvm/clang/lib/Basic/Targets/DirectX.h create mode 100644 gnu/llvm/clang/lib/Basic/Targets/LoongArch.cpp create mode 100644 gnu/llvm/clang/lib/Basic/Targets/LoongArch.h create mode 100644 gnu/llvm/clang/lib/CodeGen/CGHLSLRuntime.cpp create mode 100644 gnu/llvm/clang/lib/CodeGen/CGHLSLRuntime.h create mode 100644 gnu/llvm/clang/lib/Driver/OffloadBundler.cpp create mode 100644 gnu/llvm/clang/lib/Driver/ToolChains/Arch/CSKY.cpp create mode 100644 gnu/llvm/clang/lib/Driver/ToolChains/Arch/CSKY.h create mode 100644 gnu/llvm/clang/lib/Driver/ToolChains/Arch/LoongArch.cpp create mode 100644 gnu/llvm/clang/lib/Driver/ToolChains/Arch/LoongArch.h create mode 100644 gnu/llvm/clang/lib/Driver/ToolChains/CSKYToolChain.cpp create mode 100644 gnu/llvm/clang/lib/Driver/ToolChains/CSKYToolChain.h create mode 100644 gnu/llvm/clang/lib/Driver/ToolChains/HIPAMD.cpp create mode 100644 gnu/llvm/clang/lib/Driver/ToolChains/HIPAMD.h create mode 100644 gnu/llvm/clang/lib/Driver/ToolChains/HIPSPV.cpp create mode 100644 gnu/llvm/clang/lib/Driver/ToolChains/HIPSPV.h create mode 100644 gnu/llvm/clang/lib/Driver/ToolChains/HIPUtility.cpp create mode 100644 gnu/llvm/clang/lib/Driver/ToolChains/HIPUtility.h create mode 100644 gnu/llvm/clang/lib/Driver/ToolChains/HLSL.cpp create mode 100644 gnu/llvm/clang/lib/Driver/ToolChains/HLSL.h create mode 100644 gnu/llvm/clang/lib/Driver/ToolChains/PPCFreeBSD.cpp create mode 100644 gnu/llvm/clang/lib/Driver/ToolChains/PPCFreeBSD.h create mode 100644 gnu/llvm/clang/lib/Driver/ToolChains/SPIRV.cpp create mode 100644 gnu/llvm/clang/lib/Driver/ToolChains/SPIRV.h create mode 100644 gnu/llvm/clang/lib/ExtractAPI/API.cpp create mode 100644 gnu/llvm/clang/lib/ExtractAPI/APIIgnoresList.cpp create mode 100644 gnu/llvm/clang/lib/ExtractAPI/AvailabilityInfo.cpp create mode 100644 gnu/llvm/clang/lib/ExtractAPI/CMakeLists.txt create mode 100644 gnu/llvm/clang/lib/ExtractAPI/DeclarationFragments.cpp create mode 100644 gnu/llvm/clang/lib/ExtractAPI/ExtractAPIConsumer.cpp create mode 100644 gnu/llvm/clang/lib/ExtractAPI/ExtractAPIVisitor.cpp create mode 100644 gnu/llvm/clang/lib/ExtractAPI/Serialization/SerializerBase.cpp create mode 100644 gnu/llvm/clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp create mode 100644 gnu/llvm/clang/lib/ExtractAPI/TypedefUnderlyingTypeResolver.cpp create mode 100644 gnu/llvm/clang/lib/ExtractAPI/TypedefUnderlyingTypeResolver.h create mode 100644 gnu/llvm/clang/lib/Format/.clang-format create mode 100644 gnu/llvm/clang/lib/Format/DefinitionBlockSeparator.cpp create mode 100644 gnu/llvm/clang/lib/Format/DefinitionBlockSeparator.h create mode 100644 gnu/llvm/clang/lib/Format/IntegerLiteralSeparatorFixer.cpp create mode 100644 gnu/llvm/clang/lib/Format/IntegerLiteralSeparatorFixer.h create mode 100644 gnu/llvm/clang/lib/Format/MacroCallReconstructor.cpp create mode 100644 gnu/llvm/clang/lib/Format/QualifierAlignmentFixer.cpp create mode 100644 gnu/llvm/clang/lib/Format/QualifierAlignmentFixer.h create mode 100644 gnu/llvm/clang/lib/Frontend/SARIFDiagnostic.cpp create mode 100644 gnu/llvm/clang/lib/Frontend/SARIFDiagnosticPrinter.cpp create mode 100644 gnu/llvm/clang/lib/Headers/__clang_cuda_texture_intrinsics.h create mode 100644 gnu/llvm/clang/lib/Headers/__clang_hip_stdlib.h create mode 100644 gnu/llvm/clang/lib/Headers/amxfp16intrin.h create mode 100644 gnu/llvm/clang/lib/Headers/arm_neon_sve_bridge.h create mode 100644 gnu/llvm/clang/lib/Headers/avx512fp16intrin.h create mode 100644 gnu/llvm/clang/lib/Headers/avx512vlfp16intrin.h create mode 100644 gnu/llvm/clang/lib/Headers/avxifmaintrin.h create mode 100644 gnu/llvm/clang/lib/Headers/avxneconvertintrin.h create mode 100644 gnu/llvm/clang/lib/Headers/avxvnniint8intrin.h create mode 100644 gnu/llvm/clang/lib/Headers/cmpccxaddintrin.h create mode 100644 gnu/llvm/clang/lib/Headers/crc32intrin.h create mode 100644 gnu/llvm/clang/lib/Headers/cuda_wrappers/cmath create mode 100644 gnu/llvm/clang/lib/Headers/hlsl.h create mode 100644 gnu/llvm/clang/lib/Headers/hlsl/hlsl_basic_types.h create mode 100644 gnu/llvm/clang/lib/Headers/hlsl/hlsl_intrinsics.h create mode 100644 gnu/llvm/clang/lib/Headers/larchintrin.h create mode 100644 gnu/llvm/clang/lib/Headers/openmp_wrappers/stdlib.h create mode 100644 gnu/llvm/clang/lib/Headers/ppc_wrappers/bmi2intrin.h create mode 100644 gnu/llvm/clang/lib/Headers/ppc_wrappers/bmiintrin.h create mode 100644 gnu/llvm/clang/lib/Headers/ppc_wrappers/immintrin.h create mode 100644 gnu/llvm/clang/lib/Headers/ppc_wrappers/nmmintrin.h create mode 100644 gnu/llvm/clang/lib/Headers/ppc_wrappers/x86gprintrin.h create mode 100644 gnu/llvm/clang/lib/Headers/ppc_wrappers/x86intrin.h create mode 100644 gnu/llvm/clang/lib/Headers/prfchiintrin.h create mode 100644 gnu/llvm/clang/lib/Headers/raointintrin.h create mode 100644 gnu/llvm/clang/lib/Headers/rdpruintrin.h create mode 100644 gnu/llvm/clang/lib/Headers/velintrin.h create mode 100644 gnu/llvm/clang/lib/Headers/velintrin_approx.h create mode 100644 gnu/llvm/clang/lib/Headers/velintrin_gen.h create mode 100644 gnu/llvm/clang/lib/Lex/DependencyDirectivesScanner.cpp create mode 100644 gnu/llvm/clang/lib/Lex/InitHeaderSearch.cpp create mode 100644 gnu/llvm/clang/lib/Parse/ParseHLSL.cpp create mode 100644 gnu/llvm/clang/lib/Sema/HLSLExternalSemaSource.cpp create mode 100644 gnu/llvm/clang/lib/Sema/SemaHLSL.cpp create mode 100644 gnu/llvm/clang/lib/Sema/SemaRISCVVectorLookup.cpp create mode 100644 gnu/llvm/clang/lib/StaticAnalyzer/Checkers/ErrnoChecker.cpp create mode 100644 gnu/llvm/clang/lib/StaticAnalyzer/Checkers/ErrnoModeling.cpp create mode 100644 gnu/llvm/clang/lib/StaticAnalyzer/Checkers/ErrnoModeling.h create mode 100644 gnu/llvm/clang/lib/StaticAnalyzer/Checkers/ErrnoTesterChecker.cpp create mode 100644 gnu/llvm/clang/lib/StaticAnalyzer/Checkers/StringChecker.cpp create mode 100644 gnu/llvm/clang/lib/StaticAnalyzer/Checkers/TrustReturnsNonnullChecker.cpp create mode 100644 gnu/llvm/clang/lib/StaticAnalyzer/Checkers/UndefinedNewArraySizeChecker.cpp create mode 100644 gnu/llvm/clang/lib/StaticAnalyzer/Checkers/cert/InvalidPtrChecker.cpp create mode 100644 gnu/llvm/clang/lib/StaticAnalyzer/Core/CallDescription.cpp create mode 100644 gnu/llvm/clang/lib/Support/CMakeLists.txt create mode 100644 gnu/llvm/clang/lib/Support/RISCVVIntrinsicUtils.cpp create mode 100644 gnu/llvm/clang/lib/Testing/TestAST.cpp create mode 100644 gnu/llvm/clang/lib/Tooling/Inclusions/HeaderAnalysis.cpp create mode 100644 gnu/llvm/clang/lib/Tooling/Inclusions/Stdlib/CMakeLists.txt create mode 100644 gnu/llvm/clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp create mode 100644 gnu/llvm/clang/lib/Tooling/Syntax/TokenBufferTokenManager.cpp create mode 100644 gnu/llvm/clang/tools/clang-format/.clang-format create mode 100644 gnu/llvm/clang/tools/clang-fuzzer/dictionary/CMakeLists.txt create mode 100644 gnu/llvm/clang/tools/clang-fuzzer/dictionary/dictionary.c create mode 100644 gnu/llvm/clang/tools/clang-linker-wrapper/CMakeLists.txt create mode 100644 gnu/llvm/clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp create mode 100644 gnu/llvm/clang/tools/clang-linker-wrapper/LinkerWrapperOpts.td create mode 100644 gnu/llvm/clang/tools/clang-linker-wrapper/OffloadWrapper.cpp create mode 100644 gnu/llvm/clang/tools/clang-linker-wrapper/OffloadWrapper.h create mode 100644 gnu/llvm/clang/tools/clang-offload-packager/CMakeLists.txt create mode 100644 gnu/llvm/clang/tools/clang-offload-packager/ClangOffloadPackager.cpp create mode 100644 gnu/llvm/clang/tools/include-mapping/cppreference_parser.py create mode 100755 gnu/llvm/clang/tools/include-mapping/gen_std.py create mode 100755 gnu/llvm/clang/tools/include-mapping/test.py create mode 100644 gnu/llvm/clang/tools/libclang/CXExtractAPI.cpp create mode 100644 gnu/llvm/clang/tools/nvptx-arch/CMakeLists.txt create mode 100644 gnu/llvm/clang/tools/nvptx-arch/NVPTXArch.cpp create mode 100644 gnu/llvm/clang/www/c_dr_status.html diff --git a/gnu/llvm/clang/CMakeLists.txt b/gnu/llvm/clang/CMakeLists.txt index 95cdbd8f666..090cfa35207 100644 --- a/gnu/llvm/clang/CMakeLists.txt +++ b/gnu/llvm/clang/CMakeLists.txt @@ -1,61 +1,33 @@ cmake_minimum_required(VERSION 3.13.4) +if(NOT DEFINED LLVM_COMMON_CMAKE_UTILS) + set(LLVM_COMMON_CMAKE_UTILS ${CMAKE_CURRENT_SOURCE_DIR}/../cmake) +endif() +include(${LLVM_COMMON_CMAKE_UTILS}/Modules/CMakePolicy.cmake + NO_POLICY_SCOPE) + # If we are not building as a part of LLVM, build Clang as an # standalone project, using LLVM as an external library: -if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR ) +if(CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR) project(Clang) + set(CLANG_BUILT_STANDALONE TRUE) + if ("${CMAKE_VERSION}" VERSION_LESS "3.20.0") + message(WARNING + "Your CMake version is ${CMAKE_VERSION}. Starting with LLVM 17.0.0, the " + "minimum version of CMake required to build LLVM will become 3.20.0, and " + "using an older CMake will become an error. Please upgrade your CMake to " + "at least 3.20.0 now to avoid issues in the future!") + endif() +endif() - set(CMAKE_CXX_STANDARD 14 CACHE STRING "C++ standard to conform to") +# Must go below project(..) +include(GNUInstallDirs) + +if(CLANG_BUILT_STANDALONE) + set(CMAKE_CXX_STANDARD 17 CACHE STRING "C++ standard to conform to") set(CMAKE_CXX_STANDARD_REQUIRED YES) set(CMAKE_CXX_EXTENSIONS NO) - # Rely on llvm-config. - set(CONFIG_OUTPUT) - if(LLVM_CONFIG) - set (LLVM_CONFIG_FOUND 1) - message(STATUS "Found LLVM_CONFIG as ${LLVM_CONFIG}") - message(DEPRECATION "Using llvm-config to detect the LLVM installation is \ - deprecated. The installed cmake files should be used \ - instead. CMake should be able to detect your LLVM install \ - automatically, but you can also use LLVM_DIR to specify \ - the path containing LLVMConfig.cmake.") - set(CONFIG_COMMAND ${LLVM_CONFIG} - "--assertion-mode" - "--bindir" - "--libdir" - "--includedir" - "--prefix" - "--src-root" - "--cmakedir") - execute_process( - COMMAND ${CONFIG_COMMAND} - RESULT_VARIABLE HAD_ERROR - OUTPUT_VARIABLE CONFIG_OUTPUT - ) - if(NOT HAD_ERROR) - string(REGEX REPLACE - "[ \t]*[\r\n]+[ \t]*" ";" - CONFIG_OUTPUT ${CONFIG_OUTPUT}) - else() - string(REPLACE ";" " " CONFIG_COMMAND_STR "${CONFIG_COMMAND}") - message(STATUS "${CONFIG_COMMAND_STR}") - message(FATAL_ERROR "llvm-config failed with status ${HAD_ERROR}") - endif() - - list(GET CONFIG_OUTPUT 0 ENABLE_ASSERTIONS) - list(GET CONFIG_OUTPUT 1 TOOLS_BINARY_DIR) - list(GET CONFIG_OUTPUT 2 LIBRARY_DIR) - list(GET CONFIG_OUTPUT 3 INCLUDE_DIR) - list(GET CONFIG_OUTPUT 4 LLVM_OBJ_ROOT) - list(GET CONFIG_OUTPUT 5 MAIN_SRC_DIR) - list(GET CONFIG_OUTPUT 6 LLVM_CONFIG_CMAKE_PATH) - - # Normalize LLVM_CMAKE_PATH. --cmakedir might contain backslashes. - # CMake assumes slashes as PATH. - file(TO_CMAKE_PATH ${LLVM_CONFIG_CMAKE_PATH} LLVM_CMAKE_PATH) - endif() - - if(NOT MSVC_IDE) set(LLVM_ENABLE_ASSERTIONS ${ENABLE_ASSERTIONS} CACHE BOOL "Enable assertions") @@ -63,30 +35,15 @@ if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR ) mark_as_advanced(LLVM_ENABLE_ASSERTIONS) endif() - find_package(LLVM REQUIRED HINTS "${LLVM_CMAKE_PATH}") - list(APPEND CMAKE_MODULE_PATH ${LLVM_DIR}) - - # We can't check LLVM_CONFIG here, because find_package(LLVM ...) also sets - # LLVM_CONFIG. - if (NOT LLVM_CONFIG_FOUND) - # Pull values from LLVMConfig.cmake. We can drop this once the llvm-config - # path is removed. - set(TOOLS_BINARY_DIR ${LLVM_TOOLS_BINARY_DIR}) - set(LIBRARY_DIR ${LLVM_LIBRARY_DIR}) - set(INCLUDE_DIR ${LLVM_INCLUDE_DIR}) - set(LLVM_OBJ_DIR ${LLVM_BINARY_DIR}) - # The LLVM_CMAKE_PATH variable is set when doing non-standalone builds and - # used in this project, so we need to make sure we set this value. - # FIXME: LLVM_CMAKE_DIR comes from LLVMConfig.cmake. We should rename - # LLVM_CMAKE_PATH to LLVM_CMAKE_DIR throughout the project. - set(LLVM_CMAKE_PATH ${LLVM_CMAKE_DIR}) - endif() + find_package(LLVM REQUIRED HINTS "${LLVM_CMAKE_DIR}") + list(APPEND CMAKE_MODULE_PATH "${LLVM_DIR}") - set(LLVM_TOOLS_BINARY_DIR ${TOOLS_BINARY_DIR} CACHE PATH "Path to llvm/bin") - set(LLVM_LIBRARY_DIR ${LIBRARY_DIR} CACHE PATH "Path to llvm/lib") - set(LLVM_MAIN_INCLUDE_DIR ${INCLUDE_DIR} CACHE PATH "Path to llvm/include") - set(LLVM_BINARY_DIR ${LLVM_OBJ_ROOT} CACHE PATH "Path to LLVM build tree") - set(LLVM_MAIN_SRC_DIR ${MAIN_SRC_DIR} CACHE PATH "Path to LLVM source tree") + # Turn into CACHE PATHs for overwritting + set(LLVM_INCLUDE_DIRS ${LLVM_INCLUDE_DIRS} CACHE PATH "Path to llvm/include and any other header dirs needed") + set(LLVM_BINARY_DIR "${LLVM_BINARY_DIR}" CACHE PATH "Path to LLVM build tree") + set(LLVM_MAIN_SRC_DIR "${CMAKE_CURRENT_SOURCE_DIR}/../llvm" CACHE PATH "Path to LLVM source tree") + set(LLVM_TOOLS_BINARY_DIR "${LLVM_TOOLS_BINARY_DIR}" CACHE PATH "Path to llvm/bin") + set(LLVM_LIBRARY_DIR "${LLVM_LIBRARY_DIR}" CACHE PATH "Path to llvm/lib") find_program(LLVM_TABLEGEN_EXE "llvm-tblgen" ${LLVM_TOOLS_BINARY_DIR} NO_DEFAULT_PATH) @@ -113,6 +70,7 @@ if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR ) include(TableGen) include(HandleLLVMOptions) include(VersionFromVCS) + include(CheckAtomic) include(GetErrcMessages) include(LLVMDistributionSupport) @@ -124,7 +82,7 @@ if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR ) set(LLVM_INCLUDE_TESTS ON) endif() - include_directories("${LLVM_BINARY_DIR}/include" "${LLVM_MAIN_INCLUDE_DIR}") + include_directories(${LLVM_INCLUDE_DIRS}) link_directories("${LLVM_LIBRARY_DIR}") set( CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin ) @@ -142,9 +100,14 @@ if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR ) set(LLVM_UTILS_PROVIDED ON) endif() + # Seek installed Lit. + find_program(LLVM_LIT + NAMES llvm-lit lit.py lit + PATHS "${LLVM_MAIN_SRC_DIR}/utils/lit" + DOC "Path to lit.py") + if(EXISTS ${LLVM_MAIN_SRC_DIR}/utils/lit/lit.py) # Note: path not really used, except for checking if lit was found - set(LLVM_LIT ${LLVM_MAIN_SRC_DIR}/utils/lit/lit.py) if(EXISTS ${LLVM_MAIN_SRC_DIR}/utils/llvm-lit) add_subdirectory(${LLVM_MAIN_SRC_DIR}/utils/llvm-lit utils/llvm-lit) endif() @@ -155,18 +118,12 @@ if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR ) set(LLVM_UTILS_PROVIDED ON) set(CLANG_TEST_DEPS FileCheck count not) endif() - set(UNITTEST_DIR ${LLVM_MAIN_SRC_DIR}/utils/unittest) + set(UNITTEST_DIR ${LLVM_THIRD_PARTY_DIR}/unittest) if(EXISTS ${UNITTEST_DIR}/googletest/include/gtest/gtest.h AND NOT EXISTS ${LLVM_LIBRARY_DIR}/${CMAKE_STATIC_LIBRARY_PREFIX}gtest${CMAKE_STATIC_LIBRARY_SUFFIX} AND EXISTS ${UNITTEST_DIR}/CMakeLists.txt) - add_subdirectory(${UNITTEST_DIR} utils/unittest) + add_subdirectory(${UNITTEST_DIR} third-party/unittest) endif() - else() - # Seek installed Lit. - find_program(LLVM_LIT - NAMES llvm-lit lit.py lit - PATHS "${LLVM_MAIN_SRC_DIR}/utils/lit" - DOC "Path to lit.py") endif() if(LLVM_LIT) @@ -187,19 +144,24 @@ if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR ) else() set(LLVM_INCLUDE_TESTS OFF) endif() - endif() - set( CLANG_BUILT_STANDALONE 1 ) - set(BACKEND_PACKAGE_STRING "LLVM ${LLVM_PACKAGE_VERSION}") -else() - set(BACKEND_PACKAGE_STRING "${PACKAGE_STRING}") -endif() + umbrella_lit_testsuite_begin(check-all) + endif() # LLVM_INCLUDE_TESTS +endif() # standalone # Make sure that our source directory is on the current cmake module path so that # we can include cmake files from this directory. -list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules") +list(INSERT CMAKE_MODULE_PATH 0 + "${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules" + "${LLVM_COMMON_CMAKE_UTILS}/Modules" + ) + +# This allows disabling clang's XML dependency even if LLVM finds libxml2. +# By default, clang depends on libxml2 if LLVM does. +option(CLANG_ENABLE_LIBXML2 "Whether libclang may depend on libxml2" + ${LLVM_ENABLE_LIBXML2}) -if(LLVM_ENABLE_LIBXML2) +if(CLANG_ENABLE_LIBXML2) # Don't look for libxml if we're using MSan, since uninstrumented third party # code may call MSan interceptors like strlen, leading to false positives. if(NOT LLVM_USE_SANITIZER MATCHES "Memory.*") @@ -229,14 +191,13 @@ set(ENABLE_LINKER_BUILD_ID OFF CACHE BOOL "pass --build-id to ld") set(ENABLE_X86_RELAX_RELOCATIONS ON CACHE BOOL "enable x86 relax relocations by default") +set(PPC_LINUX_DEFAULT_IEEELONGDOUBLE OFF CACHE BOOL + "Enable IEEE binary128 as default long double format on PowerPC Linux.") + set(CLANG_SPAWN_CC1 OFF CACHE BOOL "Whether clang should use a new process for the CC1 invocation") -# TODO: verify the values against LangStandards.def? -set(CLANG_DEFAULT_STD_C "" CACHE STRING - "Default standard to use for C/ObjC code (IDENT from LangStandards.def, empty for platform default)") -set(CLANG_DEFAULT_STD_CXX "" CACHE STRING - "Default standard to use for C++/ObjC++ code (IDENT from LangStandards.def, empty for platform default)") +option(CLANG_DEFAULT_PIE_ON_LINUX "Default to -fPIE and -pie on linux-gnu" ON) set(CLANG_DEFAULT_LINKER "" CACHE STRING "Default linker to use (linker name or absolute path, empty for platform default)") @@ -284,31 +245,6 @@ set(CLANG_DEFAULT_OBJCOPY "objcopy" CACHE STRING set(CLANG_DEFAULT_OPENMP_RUNTIME "libomp" CACHE STRING "Default OpenMP runtime used by -fopenmp.") -# OpenMP offloading requires at least sm_35 because we use shuffle instructions -# to generate efficient code for reductions and the atomicMax instruction on -# 64-bit integers in the implementation of conditional lastprivate. -set(CUDA_ARCH_FLAGS "sm_35") - -# Try to find the highest Nvidia GPU architecture the system supports -if (NOT DEFINED CLANG_OPENMP_NVPTX_DEFAULT_ARCH) - find_package(CUDA QUIET) - if (CUDA_FOUND) - cuda_select_nvcc_arch_flags(CUDA_ARCH_FLAGS) - endif() -else() - set(CUDA_ARCH_FLAGS ${CLANG_OPENMP_NVPTX_DEFAULT_ARCH}) -endif() - -string(REGEX MATCH "sm_([0-9]+)" CUDA_ARCH_MATCH ${CUDA_ARCH_FLAGS}) -if (NOT DEFINED CUDA_ARCH_MATCH OR "${CMAKE_MATCH_1}" LESS 35) - set(CLANG_OPENMP_NVPTX_DEFAULT_ARCH "sm_35" CACHE STRING - "Default architecture for OpenMP offloading to Nvidia GPUs." FORCE) - message(WARNING "Resetting default architecture for OpenMP offloading to Nvidia GPUs to sm_35") -else() - set(CLANG_OPENMP_NVPTX_DEFAULT_ARCH ${CUDA_ARCH_MATCH} CACHE STRING - "Default architecture for OpenMP offloading to Nvidia GPUs.") -endif() - set(CLANG_SYSTEMZ_DEFAULT_ARCH "z10" CACHE STRING "SystemZ Default Arch") set(CLANG_VENDOR ${PACKAGE_VENDOR} CACHE STRING @@ -338,6 +274,10 @@ endif() # The libdir suffix must exactly match whatever LLVM's configuration used. set(CLANG_LIBDIR_SUFFIX "${LLVM_LIBDIR_SUFFIX}") +set(CLANG_TOOLS_INSTALL_DIR "${CMAKE_INSTALL_BINDIR}" CACHE PATH + "Path for binary subdirectory (defaults to '${CMAKE_INSTALL_BINDIR}')") +mark_as_advanced(CLANG_TOOLS_INSTALL_DIR) + set(CLANG_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}) set(CLANG_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR}) @@ -388,7 +328,7 @@ endif () # Determine HOST_LINK_VERSION on Darwin. set(HOST_LINK_VERSION) -if (APPLE) +if (APPLE AND NOT CMAKE_LINKER MATCHES ".*lld.*") set(LD_V_OUTPUT) execute_process( COMMAND sh -c "${CMAKE_LINKER} -v 2>&1 | head -1" @@ -418,7 +358,7 @@ include_directories(BEFORE if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY) install(DIRECTORY include/clang include/clang-c - DESTINATION include + DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}" COMPONENT clang-headers FILES_MATCHING PATTERN "*.def" @@ -427,7 +367,7 @@ if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY) ) install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/include/clang - DESTINATION include + DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}" COMPONENT clang-headers FILES_MATCHING PATTERN "CMakeFiles" EXCLUDE @@ -446,8 +386,8 @@ if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY) endif() add_custom_target(bash-autocomplete DEPENDS utils/bash-autocomplete.sh) - install(PROGRAMS utils/bash-autocomplete.sh - DESTINATION share/clang + install(FILES utils/bash-autocomplete.sh + DESTINATION "${CMAKE_INSTALL_DATADIR}/clang" COMPONENT bash-autocomplete) if(NOT LLVM_ENABLE_IDE) add_llvm_install_targets(install-bash-autocomplete @@ -456,20 +396,31 @@ if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY) endif() endif() -add_definitions( -D_GNU_SOURCE ) - option(CLANG_BUILD_TOOLS "Build the Clang tools. If OFF, just generate build targets." ON) +if(LLVM_ENABLE_PLUGINS OR LLVM_EXPORT_SYMBOLS_FOR_PLUGINS) + set(HAVE_CLANG_PLUGIN_SUPPORT ON) +else() + set(HAVE_CLANG_PLUGIN_SUPPORT OFF) +endif() +CMAKE_DEPENDENT_OPTION(CLANG_PLUGIN_SUPPORT + "Build clang with plugin support" ON + "HAVE_CLANG_PLUGIN_SUPPORT" OFF) + +# If libstdc++ is statically linked, clang-repl needs to statically link libstdc++ +# itself, which is not possible in many platforms because of current limitations in +# JIT stack. (more platforms need to be supported by JITLink) +if(NOT LLVM_STATIC_LINK_CXX_STDLIB) + set(HAVE_CLANG_REPL_SUPPORT ON) +endif() + option(CLANG_ENABLE_ARCMT "Build ARCMT." ON) option(CLANG_ENABLE_STATIC_ANALYZER "Include static analyzer in clang binary." ON) option(CLANG_ENABLE_PROTO_FUZZER "Build Clang protobuf fuzzer." OFF) -option(CLANG_ROUND_TRIP_CC1_ARGS - "Round-trip command line arguments in -cc1." ${LLVM_ENABLE_ASSERTIONS}) - if(NOT CLANG_ENABLE_STATIC_ANALYZER AND CLANG_ENABLE_ARCMT) message(FATAL_ERROR "Cannot disable static analyzer while enabling ARCMT or Z3") endif() @@ -478,9 +429,11 @@ if(CLANG_ENABLE_ARCMT) set(CLANG_ENABLE_OBJC_REWRITER ON) endif() -if (CLANG_ROUND_TRIP_CC1_ARGS) - add_definitions(-DCLANG_ROUND_TRIP_CC1_ARGS=ON) -endif() +# This option is a stop-gap, we should commit to removing this as +# soon as possible. See discussion: +# https://discourse.llvm.org/t/rationale-for-removing-versioned-libclang-middle-ground-to-keep-it-behind-option/ +option(CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION + "Force the SOVERSION of libclang to be equal to CLANG_MAJOR" ON) # Clang version information set(CLANG_EXECUTABLE_VERSION @@ -495,8 +448,15 @@ option(CLANG_INCLUDE_TESTS "Generate build targets for the Clang unit tests." ${LLVM_INCLUDE_TESTS}) +option(CLANG_ENABLE_HLSL "Include HLSL build products" Off) +# While HLSL support is experimental this should stay hidden. +mark_as_advanced(CLANG_ENABLE_HLSL) + add_subdirectory(utils/TableGen) +# Export CLANG_TABLEGEN_EXE for use by flang docs. +set(CLANG_TABLEGEN_EXE "${CLANG_TABLEGEN_EXE}" CACHE INTERNAL "") + add_subdirectory(include) # All targets below may depend on all tablegen'd files. @@ -546,7 +506,7 @@ endif() if( CLANG_INCLUDE_TESTS ) - if(EXISTS ${LLVM_MAIN_SRC_DIR}/utils/unittest/googletest/include/gtest/gtest.h) + if(EXISTS ${LLVM_THIRD_PARTY_DIR}/unittest/googletest/include/gtest/gtest.h) add_subdirectory(unittests) list(APPEND CLANG_TEST_DEPS ClangUnitTests) list(APPEND CLANG_TEST_PARAMS @@ -557,21 +517,7 @@ if( CLANG_INCLUDE_TESTS ) add_subdirectory(bindings/python/tests) if(CLANG_BUILT_STANDALONE) - # Add a global check rule now that all subdirectories have been traversed - # and we know the total set of lit testsuites. - get_property(LLVM_LIT_TESTSUITES GLOBAL PROPERTY LLVM_LIT_TESTSUITES) - get_property(LLVM_LIT_PARAMS GLOBAL PROPERTY LLVM_LIT_PARAMS) - get_property(LLVM_LIT_DEPENDS GLOBAL PROPERTY LLVM_LIT_DEPENDS) - get_property(LLVM_LIT_EXTRA_ARGS GLOBAL PROPERTY LLVM_LIT_EXTRA_ARGS) - get_property(LLVM_ADDITIONAL_TEST_TARGETS - GLOBAL PROPERTY LLVM_ADDITIONAL_TEST_TARGETS) - add_lit_target(check-all - "Running all regression tests" - ${LLVM_LIT_TESTSUITES} - PARAMS ${LLVM_LIT_PARAMS} - DEPENDS ${LLVM_LIT_DEPENDS} ${LLVM_ADDITIONAL_TEST_TARGETS} - ARGS ${LLVM_LIT_EXTRA_ARGS} - ) + umbrella_lit_testsuite_end(check-all) endif() add_subdirectory(utils/perf-training) endif() @@ -644,7 +590,7 @@ if (CLANG_ENABLE_BOOTSTRAP) # adding lld to clang-bootstrap-deps without having it enabled in # LLVM_ENABLE_PROJECTS just generates a cryptic error message. if (NOT "lld" IN_LIST LLVM_ENABLE_PROJECTS) - message(FATAL_ERROR "LLD is enabled in the boostrap build, but lld is not in LLVM_ENABLE_PROJECTS") + message(FATAL_ERROR "LLD is enabled in the bootstrap build, but lld is not in LLVM_ENABLE_PROJECTS") endif() add_dependencies(clang-bootstrap-deps lld) endif() @@ -711,6 +657,7 @@ if (CLANG_ENABLE_BOOTSTRAP) CMAKE_CXX_COMPILER_LAUNCHER CMAKE_MAKE_PROGRAM CMAKE_OSX_ARCHITECTURES + CMAKE_BUILD_TYPE LLVM_ENABLE_PROJECTS LLVM_ENABLE_RUNTIMES) @@ -747,7 +694,6 @@ if (CLANG_ENABLE_BOOTSTRAP) endif() if(BOOTSTRAP_CMAKE_SYSTEM_NAME) - set(${CLANG_STAGE}_CONFIG -DLLVM_CONFIG_PATH=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-config) set(${CLANG_STAGE}_TABLEGEN -DLLVM_TABLEGEN=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-tblgen -DCLANG_TABLEGEN=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang-tblgen) @@ -763,6 +709,7 @@ if (CLANG_ENABLE_BOOTSTRAP) add_dependencies(clang-bootstrap-deps llvm-objcopy llvm-strip) set(${CLANG_STAGE}_OBJCOPY -DCMAKE_OBJCOPY=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-objcopy) set(${CLANG_STAGE}_STRIP -DCMAKE_STRIP=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-strip) + set(${CLANG_STAGE}_READELF -DCMAKE_READELF=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-readelf) endif() endif() @@ -790,6 +737,19 @@ if (CLANG_ENABLE_BOOTSTRAP) set(LTO_RANLIB) endif() + # Populate the passthrough variables + foreach(variableName ${CLANG_BOOTSTRAP_PASSTHROUGH} ${_BOOTSTRAP_DEFAULT_PASSTHROUGH}) + if(DEFINED ${variableName}) + if("${${variableName}}" STREQUAL "") + set(value "") + else() + string(REPLACE ";" "|" value "${${variableName}}") + endif() + list(APPEND PASSTHROUGH_VARIABLES + -D${variableName}=${value}) + endif() + endforeach() + # Find all variables that start with BOOTSTRAP_ and populate a variable with # them. get_cmake_property(variableNames VARIABLES) @@ -806,18 +766,13 @@ if (CLANG_ENABLE_BOOTSTRAP) endif() endforeach() - # Populate the passthrough variables - foreach(variableName ${CLANG_BOOTSTRAP_PASSTHROUGH} ${_BOOTSTRAP_DEFAULT_PASSTHROUGH}) - if(DEFINED ${variableName}) - if("${${variableName}}" STREQUAL "") - set(value "") - else() - string(REPLACE ";" "|" value "${${variableName}}") - endif() - list(APPEND PASSTHROUGH_VARIABLES - -D${variableName}=${value}) - endif() - endforeach() + # Build arguments for native tool used in CMake. + set(build_configuration "$") + set(build_tool_args "${LLVM_EXTERNAL_PROJECT_BUILD_TOOL_ARGS}") + if(NOT build_tool_args STREQUAL "") + string(PREPEND build_tool_args "-- ") + separate_arguments(build_tool_args UNIX_COMMAND "${build_tool_args}") + endif() ExternalProject_Add(${NEXT_CLANG_STAGE} DEPENDS clang-bootstrap-deps @@ -834,7 +789,6 @@ if (CLANG_ENABLE_BOOTSTRAP) ${CLANG_BOOTSTRAP_CMAKE_ARGS} -DCLANG_STAGE=${NEXT_CLANG_STAGE} ${COMPILER_OPTIONS} - ${${CLANG_STAGE}_CONFIG} ${${CLANG_STAGE}_TABLEGEN} ${LTO_LIBRARY} ${verbose} ${PGO_OPT} ${${CLANG_STAGE}_LINKER} @@ -842,6 +796,9 @@ if (CLANG_ENABLE_BOOTSTRAP) ${${CLANG_STAGE}_RANLIB} ${${CLANG_STAGE}_OBJCOPY} ${${CLANG_STAGE}_STRIP} + BUILD_COMMAND ${CMAKE_COMMAND} --build ${BINARY_DIR} + --config ${build_configuration} + ${build_tool_args} INSTALL_COMMAND "" STEP_TARGETS configure build USES_TERMINAL_CONFIGURE 1 @@ -894,6 +851,118 @@ if (CLANG_ENABLE_BOOTSTRAP) endforeach() endif() +if (CLANG_BOLT_INSTRUMENT AND NOT LLVM_BUILD_INSTRUMENTED) + set(CLANG_PATH ${LLVM_RUNTIME_OUTPUT_INTDIR}/clang) + set(CLANGXX_PATH ${CLANG_PATH}++) + set(CLANG_INSTRUMENTED ${CLANG_PATH}-bolt.inst) + set(CLANGXX_INSTRUMENTED ${CLANGXX_PATH}-bolt.inst) + set(CLANG_OPTIMIZED ${CLANG_PATH}-bolt) + set(CLANGXX_OPTIMIZED ${CLANGXX_PATH}-bolt) + + # Instrument clang with BOLT + add_custom_target(clang-instrumented + DEPENDS ${CLANG_INSTRUMENTED} + ) + add_custom_command(OUTPUT ${CLANG_INSTRUMENTED} + DEPENDS clang llvm-bolt + COMMAND llvm-bolt ${CLANG_PATH} -o ${CLANG_INSTRUMENTED} + -instrument --instrumentation-file-append-pid + --instrumentation-file=${CMAKE_CURRENT_BINARY_DIR}/prof.fdata + COMMENT "Instrumenting clang binary with BOLT" + VERBATIM + ) + + # Make a symlink from clang-bolt.inst to clang++-bolt.inst + add_custom_target(clang++-instrumented + DEPENDS ${CLANGXX_INSTRUMENTED} + ) + add_custom_command(OUTPUT ${CLANGXX_INSTRUMENTED} + DEPENDS clang-instrumented + COMMAND ${CMAKE_COMMAND} -E create_symlink + ${CLANG_INSTRUMENTED} + ${CLANGXX_INSTRUMENTED} + COMMENT "Creating symlink from BOLT instrumented clang to clang++" + VERBATIM + ) + + # Build specified targets with instrumented Clang to collect the profile + set(STAMP_DIR ${CMAKE_CURRENT_BINARY_DIR}/bolt-instrumented-clang-stamps/) + set(BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR}/bolt-instrumented-clang-bins/) + set(build_configuration "$") + include(ExternalProject) + ExternalProject_Add(bolt-instrumentation-profile + DEPENDS clang++-instrumented + PREFIX bolt-instrumentation-profile + SOURCE_DIR ${CMAKE_SOURCE_DIR} + STAMP_DIR ${STAMP_DIR} + BINARY_DIR ${BINARY_DIR} + EXCLUDE_FROM_ALL 1 + CMAKE_ARGS + ${CLANG_BOLT_INSTRUMENT_EXTRA_CMAKE_FLAGS} + # We shouldn't need to set this here, but INSTALL_DIR doesn't + # seem to work, so instead I'm passing this through + -DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX} + -DCMAKE_C_COMPILER=${CLANG_INSTRUMENTED} + -DCMAKE_CXX_COMPILER=${CLANGXX_INSTRUMENTED} + -DCMAKE_ASM_COMPILER=${CLANG_INSTRUMENTED} + -DCMAKE_ASM_COMPILER_ID=Clang + -DCMAKE_BUILD_TYPE=Release + -DLLVM_ENABLE_PROJECTS=${CLANG_BOLT_INSTRUMENT_PROJECTS} + -DLLVM_TARGETS_TO_BUILD=${LLVM_TARGETS_TO_BUILD} + BUILD_COMMAND ${CMAKE_COMMAND} --build ${BINARY_DIR} + --config ${build_configuration} + --target ${CLANG_BOLT_INSTRUMENT_TARGETS} + INSTALL_COMMAND "" + STEP_TARGETS configure build + USES_TERMINAL_CONFIGURE 1 + USES_TERMINAL_BUILD 1 + USES_TERMINAL_INSTALL 1 + ) + + # Merge profiles into one using merge-fdata + add_custom_target(clang-bolt-profile + DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/prof.fdata + ) + add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/prof.fdata + DEPENDS merge-fdata bolt-instrumentation-profile-build + WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} + COMMAND ${Python3_EXECUTABLE} + ${CMAKE_CURRENT_SOURCE_DIR}/utils/perf-training/perf-helper.py merge-fdata + $ ${CMAKE_CURRENT_BINARY_DIR}/prof.fdata + ${CMAKE_CURRENT_BINARY_DIR} + COMMENT "Preparing BOLT profile" + VERBATIM + ) + + # Optimize original (pre-bolt) Clang using the collected profile + add_custom_target(clang-bolt + DEPENDS ${CLANG_OPTIMIZED} + ) + add_custom_command(OUTPUT ${CLANG_OPTIMIZED} + DEPENDS clang-bolt-profile + COMMAND llvm-bolt ${CLANG_PATH} + -o ${CLANG_OPTIMIZED} + -data ${CMAKE_CURRENT_BINARY_DIR}/prof.fdata + -reorder-blocks=ext-tsp -reorder-functions=hfsort+ -split-functions + -split-all-cold -split-eh -dyno-stats -icf=1 -use-gnu-stack + COMMENT "Optimizing Clang with BOLT" + VERBATIM + ) + + # Make a symlink from clang-bolt to clang++-bolt + add_custom_target(clang++-bolt + DEPENDS ${CLANGXX_OPTIMIZED} + ) + add_custom_command(OUTPUT ${CLANGXX_OPTIMIZED} + DEPENDS clang-bolt + COMMAND ${CMAKE_COMMAND} -E create_symlink + ${CLANG_OPTIMIZED} + ${CLANGXX_OPTIMIZED} + COMMENT "Creating symlink from BOLT optimized clang to clang++" + VERBATIM + ) +endif() + if (LLVM_ADD_NATIVE_VISUALIZERS_TO_SOLUTION) add_subdirectory(utils/ClangVisualizers) endif() @@ -904,6 +973,8 @@ if(CLANG_BUILT_STANDALONE) process_llvm_pass_plugins() endif() +set(CLANG_INSTALL_LIBDIR_BASENAME "lib${CLANG_LIBDIR_SUFFIX}") + configure_file( ${CLANG_SOURCE_DIR}/include/clang/Config/config.h.cmake ${CLANG_BINARY_DIR}/include/clang/Config/config.h) diff --git a/gnu/llvm/clang/CodeOwners.rst b/gnu/llvm/clang/CodeOwners.rst new file mode 100644 index 00000000000..b2183a72b0a --- /dev/null +++ b/gnu/llvm/clang/CodeOwners.rst @@ -0,0 +1,262 @@ +================= +Clang Code Owners +================= + +This file is a list of the people responsible for ensuring that patches for a +particular part of Clang are reviewed, either by themself or by someone else. +They are also the gatekeepers for their part of Clang, with the final word on +what goes in or not. + +.. contents:: + :depth: 2 + :local: + +Current Code Owners +=================== +The following people are the active code owners for the project. Please reach +out to them for code reviews, questions about their area of expertise, or other +assistance. + +All parts of Clang not covered by someone else +---------------------------------------------- +| Aaron Ballman +| aaron\@aaronballman.com (email), aaron.ballman (Phabricator), AaronBallman (GitHub) + + +Contained Components +-------------------- +These code owners are responsible for particular high-level components within +Clang that are typically contained to one area of the compiler. + +AST matchers +~~~~~~~~~~~~ +| Manuel Klimek +| klimek\@google.com (email), klimek (Phabricator), r4nt (GitHub) + + +Clang LLVM IR generation +~~~~~~~~~~~~~~~~~~~~~~~~ +| John McCall +| rjmccall\@apple.com (email), rjmccall (Phabricator), rjmccall (GitHub) + +| Eli Friedman +| efriedma\@quicinc.com (email), efriedma (Phabricator), efriedma-quic (GitHub) + +| Anton Korobeynikov +| anton\@korobeynikov.info (email), asl (Phabricator), asl (GitHub) + + +Analysis & CFG +~~~~~~~~~~~~~~ +| Dmitri Gribenko +| gribozavr\@gmail.com (email), gribozavr (Phabricator), gribozavr (GitHub) + +| Yitzhak Mandelbaum +| yitzhakm\@google.com (email), ymandel (Phabricator), ymand (GitHub) + +| Stanislav Gatev +| sgatev\@google.com (email), sgatev (Phabricator), sgatev (GitHub) + + +Modules & serialization +~~~~~~~~~~~~~~~~~~~~~~~ +| Chuanqi Xu +| yedeng.yd\@linux.alibaba.com (email), ChuanqiXu (Phabricator), ChuanqiXu9 (GitHub) + +| Michael Spencer +| bigcheesegs\@gmail.com (email), Bigcheese (Phabricator), Bigcheese (GitHub) + + +Templates +~~~~~~~~~ +| Erich Keane +| erich.keane\@intel.com (email), ErichKeane (Phabricator), erichkeane (GitHub) + + +Debug information +~~~~~~~~~~~~~~~~~ +| Eric Christopher +| echristo\@gmail.com (email), echristo (Phabricator), echristo (GitHub) + + +Exception handling +~~~~~~~~~~~~~~~~~~ +| Anton Korobeynikov +| anton\@korobeynikov.info (email), asl (Phabricator), asl (GitHub) + + +Clang static analyzer +~~~~~~~~~~~~~~~~~~~~~ +| Artem Dergachev +| adergachev\@apple.com (email), NoQ (Phabricator), haoNoQ (GitHub) + +| Gábor Horváth +| xazax.hun\@gmail.com (email), xazax.hun (Phabricator), Xazax-hun (GitHub) + + +Compiler options +~~~~~~~~~~~~~~~~ +| Jan Svoboda +| jan_svoboda\@apple.com (email), jansvoboda11 (Phabricator), jansvoboda11 (GitHub) + + +OpenBSD driver +~~~~~~~~~~~~~~ +| Brad Smith +| brad\@comstyle.com (email), brad (Phabricator), brad0 (GitHub) + + +Driver parts not covered by someone else +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +| Fangrui Song +| maskray\@google.com (email), MaskRay (Phabricator), MaskRay (GitHub) + + +Tools +----- +These code owners are responsible for user-facing tools under the Clang +umbrella or components used to support such tools. + +Tooling library +~~~~~~~~~~~~~~~ +| Manuel Klimek +| klimek\@google.com (email), klimek (Phabricator), r4nt (GitHub) + + +clang-format +~~~~~~~~~~~~ +| MyDeveloperDay +| mydeveloperday\@gmail.com (email), MyDeveloperDay (Phabricator), MyDeveloperDay (GitHub) + +| Owen Pan +| owenpiano\@gmail.com (email), owenpan (Phabricator), owenca (GitHub) + + +ABIs +---- +The following people are responsible for decisions involving ABI. + +Itanium ABI +~~~~~~~~~~~ +| John McCall +| rjmccall\@apple.com (email), rjmccall (Phabricator), rjmccall (GitHub) + + +Microsoft ABI +~~~~~~~~~~~~~ +| Reid Kleckner +| rnk\@google.com (email), rnk (Phabricator), rnk (GitHub) + + +ARM EABI +~~~~~~~~ +| Anton Korobeynikov +| anton\@korobeynikov.info (email), asl (Phabricator), asl (GitHub) + + +Compiler-Wide Topics +-------------------- +The following people are responsible for functionality that does not fit into +a single part of the compiler, but instead span multiple components within the +compiler. + +Attributes +~~~~~~~~~~ +| Erich Keane +| erich.keane\@intel.com (email), ErichKeane (Phabricator), erichkeane (GitHub) + + +Inline assembly +~~~~~~~~~~~~~~~ +| Eric Christopher +| echristo\@gmail.com (email), echristo (Phabricator), echristo (GitHub) + + +Text encodings +~~~~~~~~~~~~~~ +| Tom Honermann +| tom\@honermann.net (email), tahonermann (Phabricator), tahonermann (GitHub) + +| Corentin Jabot +| corentin.jabot\@gmail.com (email), cor3ntin (Phabricator), cor3ntin (GitHub) + + +CMake integration +~~~~~~~~~~~~~~~~~ +| Petr Hosek +| phosek\@google.com (email), phosek (Phabricator), petrhosek (GitHub) + +| John Ericson +| git\@johnericson.me (email), Ericson2314 (Phabricator), Ericson2314 (GitHub) + + +General Windows support +~~~~~~~~~~~~~~~~~~~~~~~ +| Reid Kleckner +| rnk\@google.com (email), rnk (Phabricator), rnk (GitHub) + + +Incremental compilation, REPLs, clang-repl +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +| Vassil Vassilev +| Vassil.Vassilev\@cern.ch (email), v.g.vassilev (Phabricator), vgvassilev (GitHub) + + +Standards Conformance +--------------------- +The following people are responsible for validating that changes are conforming +to a relevant standard. Contact them for questions about how to interpret a +standard, when fixing standards bugs, or when implementing a new standard feature. + +C conformance +~~~~~~~~~~~~~ +| Aaron Ballman +| aaron\@aaronballman.com (email), aaron.ballman (Phabricator), AaronBallman (GitHub) + + +C++ conformance +~~~~~~~~~~~~~~~ +| Hubert Tong +| hubert.reinterpretcast\@gmail.com (email), hubert.reinterpretcast (Phabricator), hubert-reinterpretcast (GitHub) + + +Objective-C/C++ conformance +~~~~~~~~~~~~~~~~~~~~~~~~~~~ +| John McCall +| rjmccall\@apple.com (email), rjmccall (Phabricator), rjmccall (GitHub) + + +OpenMP conformance +~~~~~~~~~~~~~~~~~~ +| Alexey Bataev +| a.bataev\@hotmail.com (email), ABataev (Phabricator), alexey-bataev (GitHub) + + +OpenCL conformance +~~~~~~~~~~~~~~~~~~ +| Anastasia Stulova +| anastasia\@compiler-experts.com (email), Anastasia (Phabricator), AnastasiaStulova (GitHub) + + +SYCL conformance +~~~~~~~~~~~~~~~~ +| Alexey Bader +| alexey.bader\@intel.com (email), bader (Phabricator), bader (GitHub) + + +Former Code Owners +================== +The following people have graciously spent time performing code ownership +responsibilities but are no longer active in that role. Thank you for all your +help with the success of the project! + +Emeritus owners +--------------- +| Doug Gregor (dgregor\@apple.com) +| Richard Smith (richard\@metafoo.co.uk) + + +Former component owners +----------------------- +| Chandler Carruth (chandlerc\@gmail.com, chandlerc\@google.com) -- CMake, library layering +| Devin Coughlin (dcoughlin\@apple.com) -- Clang static analyzer diff --git a/gnu/llvm/clang/README.txt b/gnu/llvm/clang/README.txt index 91527b09485..63842d42bc2 100644 --- a/gnu/llvm/clang/README.txt +++ b/gnu/llvm/clang/README.txt @@ -19,8 +19,8 @@ Clang Static Analyzer: http://clang-analyzer.llvm.org/ Information on the LLVM project: http://llvm.org/ If you have questions or comments about Clang, a great place to discuss them is -on the Clang development mailing list: - http://lists.llvm.org/mailman/listinfo/cfe-dev +on the Clang forums: + https://discourse.llvm.org/c/clang/ If you find a bug in Clang, please file it in the LLVM bug tracker: http://llvm.org/bugs/ diff --git a/gnu/llvm/clang/bindings/python/clang/cindex.py b/gnu/llvm/clang/bindings/python/clang/cindex.py index aceaa131f15..2e32ce2ba6d 100644 --- a/gnu/llvm/clang/bindings/python/clang/cindex.py +++ b/gnu/llvm/clang/bindings/python/clang/cindex.py @@ -1152,7 +1152,7 @@ CursorKind.OBJC_AT_THROW_STMT = CursorKind(219) # Objective-C's @synchronized statement. CursorKind.OBJC_AT_SYNCHRONIZED_STMT = CursorKind(220) -# Objective-C's autorealease pool statement. +# Objective-C's autorelease pool statement. CursorKind.OBJC_AUTORELEASE_POOL_STMT = CursorKind(221) # Objective-C's for collection statement. @@ -1312,7 +1312,7 @@ CursorKind.OMP_TEAMS_DISTRIBUTE_DIRECTIVE = CursorKind(271) # # The translation unit cursor exists primarily to act as the root cursor for # traversing the contents of a translation unit. -CursorKind.TRANSLATION_UNIT = CursorKind(300) +CursorKind.TRANSLATION_UNIT = CursorKind(350) ### # Attributes @@ -1473,6 +1473,62 @@ class Cursor(Structure): """ return conf.lib.clang_CXXMethod_isDefaulted(self) + def is_deleted_method(self): + """Returns True if the cursor refers to a C++ member function or member + function template that is declared '= delete'. + """ + return conf.lib.clang_CXXMethod_isDeleted(self) + + def is_copy_assignment_operator_method(self): + """Returnrs True if the cursor refers to a copy-assignment operator. + + A copy-assignment operator `X::operator=` is a non-static, + non-template member function of _class_ `X` with exactly one + parameter of type `X`, `X&`, `const X&`, `volatile X&` or `const + volatile X&`. + + + That is, for example, the `operator=` in: + + class Foo { + bool operator=(const volatile Foo&); + }; + + Is a copy-assignment operator, while the `operator=` in: + + class Bar { + bool operator=(const int&); + }; + + Is not. + """ + return conf.lib.clang_CXXMethod_isCopyAssignmentOperator(self) + + def is_move_assignment_operator_method(self): + """Returnrs True if the cursor refers to a move-assignment operator. + + A move-assignment operator `X::operator=` is a non-static, + non-template member function of _class_ `X` with exactly one + parameter of type `X&&`, `const X&&`, `volatile X&&` or `const + volatile X&&`. + + + That is, for example, the `operator=` in: + + class Foo { + bool operator=(const volatile Foo&&); + }; + + Is a move-assignment operator, while the `operator=` in: + + class Bar { + bool operator=(const int&&); + }; + + Is not. + """ + return conf.lib.clang_CXXMethod_isMoveAssignmentOperator(self) + def is_mutable_field(self): """Returns True if the cursor refers to a C++ field that is declared 'mutable'. @@ -2059,6 +2115,7 @@ TypeKind.OBJCCLASS = TypeKind(28) TypeKind.OBJCSEL = TypeKind(29) TypeKind.FLOAT128 = TypeKind(30) TypeKind.HALF = TypeKind(31) +TypeKind.IBM128 = TypeKind(40) TypeKind.COMPLEX = TypeKind(100) TypeKind.POINTER = TypeKind(101) TypeKind.BLOCKPOINTER = TypeKind(102) @@ -3425,6 +3482,18 @@ functionList = [ [Cursor], bool), + ("clang_CXXMethod_isDeleted", + [Cursor], + bool), + + ("clang_CXXMethod_isCopyAssignmentOperator", + [Cursor], + bool), + + ("clang_CXXMethod_isMoveAssignmentOperator", + [Cursor], + bool), + ("clang_CXXMethod_isPureVirtual", [Cursor], bool), diff --git a/gnu/llvm/clang/bindings/python/tests/CMakeLists.txt b/gnu/llvm/clang/bindings/python/tests/CMakeLists.txt index 280da9d0068..c4cd2539e9d 100644 --- a/gnu/llvm/clang/bindings/python/tests/CMakeLists.txt +++ b/gnu/llvm/clang/bindings/python/tests/CMakeLists.txt @@ -1,7 +1,10 @@ # Test target to run Python test suite from main build. +# Avoid configurations including '-include' from interfering with +# our tests by setting CLANG_NO_DEFAULT_CONFIG. add_custom_target(check-clang-python COMMAND ${CMAKE_COMMAND} -E env + CLANG_NO_DEFAULT_CONFIG=1 CLANG_LIBRARY_PATH=$ "${Python3_EXECUTABLE}" -m unittest discover DEPENDS libclang @@ -46,5 +49,5 @@ endif() if(RUN_PYTHON_TESTS) set_property(GLOBAL APPEND PROPERTY - LLVM_ADDITIONAL_TEST_TARGETS check-clang-python) + LLVM_ALL_ADDITIONAL_TEST_TARGETS check-clang-python) endif() diff --git a/gnu/llvm/clang/bindings/python/tests/cindex/test_cursor.py b/gnu/llvm/clang/bindings/python/tests/cindex/test_cursor.py index ef875e97247..198352080c6 100644 --- a/gnu/llvm/clang/bindings/python/tests/cindex/test_cursor.py +++ b/gnu/llvm/clang/bindings/python/tests/cindex/test_cursor.py @@ -219,6 +219,64 @@ class TestCursor(unittest.TestCase): self.assertTrue(xc.is_default_method()) self.assertFalse(yc.is_default_method()) + def test_is_move_assignment_operator_method(self): + """Ensure Cursor.is_move_assignment_operator_method works.""" + source_with_move_assignment_operators = """ + struct Foo { + // Those are move-assignment operators + bool operator=(const Foo&&); + bool operator=(Foo&&); + bool operator=(volatile Foo&&); + bool operator=(const volatile Foo&&); + + // Positive-check that the recognition works for templated classes too + template + class Bar { + bool operator=(const Bar&&); + bool operator=(Bar&&); + bool operator=(volatile Bar&&); + bool operator=(const volatile Bar&&); + }; + """ + source_without_move_assignment_operators = """ + struct Foo { + // Those are not move-assignment operators + template + bool operator=(const T&&); + bool operator=(const bool&&); + bool operator=(char&&); + bool operator=(volatile unsigned int&&); + bool operator=(const volatile unsigned char&&); + bool operator=(int); + bool operator=(Foo); + }; + """ + tu_with_move_assignment_operators = get_tu( + source_with_move_assignment_operators, lang="cpp" + ) + tu_without_move_assignment_operators = get_tu( + source_without_move_assignment_operators, lang="cpp" + ) + + move_assignment_operators_cursors = get_cursors( + tu_with_move_assignment_operators, "operator=" + ) + non_move_assignment_operators_cursors = get_cursors( + tu_without_move_assignment_operators, "operator=" + ) + + self.assertEqual(len(move_assignment_operators_cursors), 8) + self.assertTrue(len(non_move_assignment_operators_cursors), 7) + + self.assertTrue(all([ + cursor.is_move_assignment_operator_method() + for cursor in move_assignment_operators_cursors + ])) + self.assertFalse(any([ + cursor.is_move_assignment_operator_method() + for cursor in non_move_assignment_operators_cursors + ])) + def test_is_mutable_field(self): """Ensure Cursor.is_mutable_field works.""" source = 'class X { int x_; mutable int y_; };' diff --git a/gnu/llvm/clang/bindings/python/tests/cindex/test_diagnostics.py b/gnu/llvm/clang/bindings/python/tests/cindex/test_diagnostics.py index 8b0f0425688..f7e6e18c91d 100644 --- a/gnu/llvm/clang/bindings/python/tests/cindex/test_diagnostics.py +++ b/gnu/llvm/clang/bindings/python/tests/cindex/test_diagnostics.py @@ -26,7 +26,7 @@ class TestDiagnostics(unittest.TestCase): # FIXME: We aren't getting notes here for some reason. tu = get_tu('#define A x\nvoid *A = 1;\n') self.assertEqual(len(tu.diagnostics), 1) - self.assertEqual(tu.diagnostics[0].severity, Diagnostic.Warning) + self.assertEqual(tu.diagnostics[0].severity, Diagnostic.Error) self.assertEqual(tu.diagnostics[0].location.line, 2) self.assertEqual(tu.diagnostics[0].location.column, 7) self.assertIn('incompatible', tu.diagnostics[0].spelling) @@ -53,7 +53,7 @@ class TestDiagnostics(unittest.TestCase): def test_diagnostic_range(self): tu = get_tu('void f() { int i = "a"; }') self.assertEqual(len(tu.diagnostics), 1) - self.assertEqual(tu.diagnostics[0].severity, Diagnostic.Warning) + self.assertEqual(tu.diagnostics[0].severity, Diagnostic.Error) self.assertEqual(tu.diagnostics[0].location.line, 1) self.assertEqual(tu.diagnostics[0].location.column, 16) self.assertRegex(tu.diagnostics[0].spelling, diff --git a/gnu/llvm/clang/bindings/python/tests/cindex/test_type.py b/gnu/llvm/clang/bindings/python/tests/cindex/test_type.py index bcdbeff9d99..efe9b0f50be 100644 --- a/gnu/llvm/clang/bindings/python/tests/cindex/test_type.py +++ b/gnu/llvm/clang/bindings/python/tests/cindex/test_type.py @@ -58,7 +58,7 @@ class TestType(unittest.TestCase): self.assertIsNotNone(fields[1].translation_unit) self.assertEqual(fields[1].spelling, 'b') self.assertFalse(fields[1].type.is_const_qualified()) - self.assertEqual(fields[1].type.kind, TypeKind.TYPEDEF) + self.assertEqual(fields[1].type.kind, TypeKind.ELABORATED) self.assertEqual(fields[1].type.get_canonical().kind, TypeKind.INT) self.assertEqual(fields[1].type.get_declaration().spelling, 'I') self.assertEqual(fields[1].type.get_typedef_name(), 'I') @@ -175,10 +175,10 @@ class TestType(unittest.TestCase): self.assertIsNotNone(i) self.assertIsNotNone(x) self.assertIsNotNone(v) - self.assertEqual(c.type.spelling, "int [5]") - self.assertEqual(i.type.spelling, "int []") + self.assertEqual(c.type.spelling, "int[5]") + self.assertEqual(i.type.spelling, "int[]") self.assertEqual(x.type.spelling, "int") - self.assertEqual(v.type.spelling, "int [x]") + self.assertEqual(v.type.spelling, "int[x]") def test_typekind_spelling(self): """Ensure TypeKind.spelling works.""" diff --git a/gnu/llvm/clang/cmake/caches/3-stage-base.cmake b/gnu/llvm/clang/cmake/caches/3-stage-base.cmake index 31391aa4def..63a1c21528d 100644 --- a/gnu/llvm/clang/cmake/caches/3-stage-base.cmake +++ b/gnu/llvm/clang/cmake/caches/3-stage-base.cmake @@ -1,6 +1,8 @@ set(CMAKE_BUILD_TYPE RELEASE CACHE STRING "") set(CLANG_ENABLE_BOOTSTRAP ON CACHE BOOL "") -set(LLVM_BUILD_EXTERNAL_COMPILER_RT ON CACHE BOOL "") + +set(LLVM_ENABLE_PROJECTS "clang;lld" CACHE STRING "") +set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi" CACHE STRING "") if(APPLE) # Use LLD to have fewer requirements on system linker, unless we're on an apple diff --git a/gnu/llvm/clang/cmake/caches/Apple-stage2.cmake b/gnu/llvm/clang/cmake/caches/Apple-stage2.cmake index a2eb42efbaf..72cdedd611b 100644 --- a/gnu/llvm/clang/cmake/caches/Apple-stage2.cmake +++ b/gnu/llvm/clang/cmake/caches/Apple-stage2.cmake @@ -1,7 +1,7 @@ # This file sets up a CMakeCache for Apple-style stage2 bootstrap. It is # specified by the stage1 build. -set(LLVM_TARGETS_TO_BUILD X86 ARM AArch64 CACHE STRING "") +set(LLVM_TARGETS_TO_BUILD X86 ARM AArch64 CACHE STRING "") set(PACKAGE_VENDOR Apple CACHE STRING "") set(CLANG_VENDOR_UTI com.apple.clang CACHE STRING "") set(LLVM_INCLUDE_EXAMPLES OFF CACHE BOOL "") @@ -36,10 +36,6 @@ if(LLVM_ENABLE_LTO AND NOT LLVM_ENABLE_LTO STREQUAL "THIN") endif() set(CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "") -set(LIBCXX_INSTALL_LIBRARY OFF CACHE BOOL "") -set(LIBCXX_INSTALL_HEADERS ON CACHE BOOL "") -set(LIBCXX_INCLUDE_TESTS OFF CACHE BOOL "") -set(LIBCXX_USE_COMPILER_RT ON CACHE BOOL "") set(LLVM_LTO_VERSION_OFFSET 3000 CACHE STRING "") # Generating Xcode toolchains is useful for developers wanting to build and use @@ -74,12 +70,19 @@ set(LLVM_DISTRIBUTION_COMPONENTS LTO clang-format clang-resource-headers - cxx-headers Remarks ${LLVM_TOOLCHAIN_TOOLS} ${LLVM_TOOLCHAIN_UTILITIES} CACHE STRING "") +# Build the libc++ headers +set(LLVM_ENABLE_RUNTIMES "libcxx;libcxxabi" CACHE STRING "") +set(LLVM_RUNTIME_DISTRIBUTION_COMPONENTS cxx-headers CACHE STRING "") +set(LIBCXX_INSTALL_LIBRARY OFF CACHE BOOL "") +set(LIBCXX_INSTALL_HEADERS ON CACHE BOOL "") +set(LIBCXX_INCLUDE_TESTS OFF CACHE BOOL "") +set(LIBCXX_USE_COMPILER_RT ON CACHE BOOL "") + # test args set(LLVM_LIT_ARGS "--xunit-xml-output=testresults.xunit.xml -v" CACHE STRING "") diff --git a/gnu/llvm/clang/cmake/caches/BOLT-PGO.cmake b/gnu/llvm/clang/cmake/caches/BOLT-PGO.cmake new file mode 100644 index 00000000000..54827c124bc --- /dev/null +++ b/gnu/llvm/clang/cmake/caches/BOLT-PGO.cmake @@ -0,0 +1,11 @@ +set(LLVM_ENABLE_PROJECTS "bolt;clang;lld" CACHE STRING "") + +set(CLANG_BOOTSTRAP_TARGETS + stage2-clang++-bolt + CACHE STRING "") +set(BOOTSTRAP_CLANG_BOOTSTRAP_TARGETS + clang++-bolt + CACHE STRING "") + +set(PGO_BUILD_CONFIGURATION ${CMAKE_CURRENT_LIST_DIR}/BOLT.cmake CACHE STRING "") +include(${CMAKE_CURRENT_LIST_DIR}/PGO.cmake) diff --git a/gnu/llvm/clang/cmake/caches/BOLT.cmake b/gnu/llvm/clang/cmake/caches/BOLT.cmake new file mode 100644 index 00000000000..65444c8044c --- /dev/null +++ b/gnu/llvm/clang/cmake/caches/BOLT.cmake @@ -0,0 +1,15 @@ +set(CMAKE_BUILD_TYPE Release CACHE STRING "") +set(CLANG_BOLT_INSTRUMENT ON CACHE BOOL "") +set(CLANG_BOLT_INSTRUMENT_PROJECTS "llvm" CACHE STRING "") +set(CLANG_BOLT_INSTRUMENT_TARGETS "count" CACHE STRING "") +set(CMAKE_EXE_LINKER_FLAGS "-Wl,--emit-relocs,-znow" CACHE STRING "") +set(CLANG_BOLT_INSTRUMENT_EXTRA_CMAKE_FLAGS "" CACHE STRING "") + +set(LLVM_ENABLE_PROJECTS "bolt;clang" CACHE STRING "") +set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "") + +# Disable function splitting enabled by default in GCC8+ +if("${CMAKE_CXX_COMPILER_ID}" MATCHES "GNU") + set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fno-reorder-blocks-and-partition") + set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-reorder-blocks-and-partition") +endif() diff --git a/gnu/llvm/clang/cmake/caches/BaremetalARM.cmake b/gnu/llvm/clang/cmake/caches/BaremetalARM.cmake index 85295d9db39..e44355cfcbd 100644 --- a/gnu/llvm/clang/cmake/caches/BaremetalARM.cmake +++ b/gnu/llvm/clang/cmake/caches/BaremetalARM.cmake @@ -31,6 +31,7 @@ set(LLVM_TOOLCHAIN_TOOLS llvm-dwarfdump llvm-nm llvm-objdump + llvm-pdbutil llvm-ranlib llvm-readobj llvm-size diff --git a/gnu/llvm/clang/cmake/caches/CrossWinToARMLinux.cmake b/gnu/llvm/clang/cmake/caches/CrossWinToARMLinux.cmake index 778494ee9f1..e6f5650eac4 100644 --- a/gnu/llvm/clang/cmake/caches/CrossWinToARMLinux.cmake +++ b/gnu/llvm/clang/cmake/caches/CrossWinToARMLinux.cmake @@ -10,7 +10,7 @@ # # Configure: # cmake -G Ninja ^ -# -DTARGET_TRIPLE=armv7-linux-gnueabihf ^ +# -DTOOLCHAIN_TARGET_TRIPLE=armv7-unknown-linux-gnueabihf ^ # -DCMAKE_INSTALL_PREFIX=../install ^ # -DDEFAULT_SYSROOT= ^ # -DLLVM_AR=/bin/llvm-ar[.exe] ^ @@ -25,10 +25,10 @@ # cmake --build . --target check-llvm # cmake --build . --target check-clang # cmake --build . --target check-lld -# cmake --build . --target check-compiler-rt -# cmake --build . --target check-cxxabi -# cmake --build . --target check-unwind -# cmake --build . --target check-cxx +# cmake --build . --target check-compiler-rt- +# cmake --build . --target check-cxxabi- +# cmake --build . --target check-unwind- +# cmake --build . --target check-cxx- # LLVM_PROJECT_DIR is the path to the llvm-project directory. # The right way to compute it would probably be to use "${CMAKE_SOURCE_DIR}/../", @@ -42,9 +42,6 @@ if (NOT DEFINED DEFAULT_SYSROOT) message(WARNING "DEFAULT_SYSROOT must be specified for the cross toolchain build.") endif() -if (DEFINED LLVM_AR) - set(CMAKE_AR "${LLVM_AR}" CACHE STRING "") -endif() if (NOT DEFINED LLVM_TARGETS_TO_BUILD) set(LLVM_TARGETS_TO_BUILD "ARM" CACHE STRING "") endif() @@ -58,76 +55,48 @@ if (NOT DEFINED LLVM_ENABLE_RUNTIMES) set(LLVM_ENABLE_RUNTIMES "compiler-rt;libunwind;libcxxabi;libcxx" CACHE STRING "") endif() -if (NOT DEFINED TARGET_TRIPLE) - set(TARGET_TRIPLE "armv7-unknown-linux-gnueabihf") +if (NOT DEFINED TOOLCHAIN_TARGET_TRIPLE) + set(TOOLCHAIN_TARGET_TRIPLE "armv7-unknown-linux-gnueabihf") else() #NOTE: we must normalize specified target triple to a fully specified triple, # including the vendor part. It is necessary to synchronize the runtime library # installation path and operable target triple by Clang to get a correct runtime # path through `-print-runtime-dir` Clang option. - string(REPLACE "-" ";" TARGET_TRIPLE "${TARGET_TRIPLE}") - list(LENGTH TARGET_TRIPLE TARGET_TRIPLE_LEN) - if (TARGET_TRIPLE_LEN LESS 3) + string(REPLACE "-" ";" TOOLCHAIN_TARGET_TRIPLE "${TOOLCHAIN_TARGET_TRIPLE}") + list(LENGTH TOOLCHAIN_TARGET_TRIPLE TOOLCHAIN_TARGET_TRIPLE_LEN) + if (TOOLCHAIN_TARGET_TRIPLE_LEN LESS 3) message(FATAL_ERROR "invalid target triple") endif() # We suppose missed vendor's part. - if (TARGET_TRIPLE_LEN LESS 4) - list(INSERT TARGET_TRIPLE 1 "unknown") + if (TOOLCHAIN_TARGET_TRIPLE_LEN LESS 4) + list(INSERT TOOLCHAIN_TARGET_TRIPLE 1 "unknown") endif() - string(REPLACE ";" "-" TARGET_TRIPLE "${TARGET_TRIPLE}") + string(REPLACE ";" "-" TOOLCHAIN_TARGET_TRIPLE "${TOOLCHAIN_TARGET_TRIPLE}") endif() if (NOT DEFINED CMAKE_BUILD_TYPE) set(CMAKE_BUILD_TYPE "Release" CACHE STRING "") endif() -message(STATUS "Toolchain target triple: ${TARGET_TRIPLE}") +message(STATUS "Toolchain target triple: ${TOOLCHAIN_TARGET_TRIPLE}") set(CMAKE_CROSSCOMPILING ON CACHE BOOL "") set(CMAKE_CL_SHOWINCLUDES_PREFIX "Note: including file: " CACHE STRING "") # Required if COMPILER_RT_DEFAULT_TARGET_ONLY is ON -set(CMAKE_C_COMPILER_TARGET "${TARGET_TRIPLE}" CACHE STRING "") +set(CMAKE_C_COMPILER_TARGET "${TOOLCHAIN_TARGET_TRIPLE}" CACHE STRING "") +set(CMAKE_CXX_COMPILER_TARGET "${TOOLCHAIN_TARGET_TRIPLE}" CACHE STRING "") -set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR ON CACHE BOOL "") -set(LLVM_DEFAULT_TARGET_TRIPLE "${TARGET_TRIPLE}" CACHE STRING "") -set(LLVM_TARGET_ARCH "${TARGET_TRIPLE}" CACHE STRING "") +set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR ON CACHE BOOL "") +set(LLVM_DEFAULT_TARGET_TRIPLE "${TOOLCHAIN_TARGET_TRIPLE}" CACHE STRING "") +set(LLVM_TARGET_ARCH "${TOOLCHAIN_TARGET_TRIPLE}" CACHE STRING "") set(LLVM_LIT_ARGS "-vv ${LLVM_LIT_ARGS}" CACHE STRING "" FORCE) set(CLANG_DEFAULT_LINKER "lld" CACHE STRING "") -set(COMPILER_RT_BUILD_BUILTINS ON CACHE BOOL "") -set(COMPILER_RT_BUILD_SANITIZERS OFF CACHE BOOL "") -set(COMPILER_RT_BUILD_XRAY OFF CACHE BOOL "") -set(COMPILER_RT_BUILD_LIBFUZZER OFF CACHE BOOL "") -set(COMPILER_RT_BUILD_PROFILE OFF CACHE BOOL "") -set(COMPILER_RT_BUILD_CRT OFF CACHE BOOL "") -set(COMPILER_RT_DEFAULT_TARGET_ONLY ON CACHE BOOL "") -set(COMPILER_RT_INCLUDE_TESTS ON CACHE BOOL "") - -set(LIBUNWIND_USE_COMPILER_RT ON CACHE BOOL "") -set(LIBUNWIND_TARGET_TRIPLE "${TARGET_TRIPLE}" CACHE STRING "") -set(LIBUNWIND_SYSROOT "${DEFAULT_SYSROOT}" CACHE STRING "") -set(LIBUNWIND_ENABLE_SHARED OFF CACHE BOOL "") - -set(LIBCXXABI_USE_LLVM_UNWINDER ON CACHE BOOL "") -set(LIBCXXABI_ENABLE_STATIC_UNWINDER ON CACHE BOOL "") -set(LIBCXXABI_USE_COMPILER_RT ON CACHE BOOL "") -set(LIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS OFF CACHE BOOL "") -set(LIBCXXABI_TARGET_TRIPLE "${TARGET_TRIPLE}" CACHE STRING "") -set(LIBCXXABI_SYSROOT "${DEFAULT_SYSROOT}" CACHE STRING "") -set(LIBCXXABI_LINK_TESTS_WITH_SHARED_LIBCXXABI OFF CACHE BOOL "") -set(LIBCXXABI_LINK_TESTS_WITH_SHARED_LIBCXX OFF CACHE BOOL "") -set(LIBCXX_LINK_TESTS_WITH_SHARED_LIBCXXABI OFF CACHE BOOL "") -set(LIBCXX_LINK_TESTS_WITH_SHARED_LIBCXX OFF CACHE BOOL "") - -set(LIBCXX_USE_COMPILER_RT ON CACHE BOOL "") -set(LIBCXX_TARGET_TRIPLE "${TARGET_TRIPLE}" CACHE STRING "") -set(LIBCXX_SYSROOT "${DEFAULT_SYSROOT}" CACHE STRING "") -set(LIBCXX_ENABLE_SHARED OFF CACHE BOOL "") -set(LIBCXX_CXX_ABI "libcxxabi" CACHE STRING "") -set(LIBCXX_CXX_ABI_INCLUDE_PATHS "${LLVM_PROJECT_DIR}/libcxxabi/include" CACHE PATH "") -set(LIBCXX_CXX_ABI_LIBRARY_PATH "${CMAKE_BINARY_DIR}/lib/${LIBCXX_TARGET_TRIPLE}" CACHE PATH "") -set(LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS ON CACHE BOOL "") +if(WIN32) + set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded" CACHE STRING "") + set(LLVM_USE_CRT_RELEASE "MT" CACHE STRING "") +endif() # Set up RPATH for the target runtime/builtin libraries. # See some details here: https://reviews.llvm.org/D91099 @@ -135,41 +104,71 @@ if (NOT DEFINED RUNTIMES_INSTALL_RPATH) set(RUNTIMES_INSTALL_RPATH "\$ORIGIN/../lib;${CMAKE_INSTALL_PREFIX}/lib") endif() -set(BUILTINS_CMAKE_ARGS "-DCMAKE_SYSTEM_NAME=Linux;-DCMAKE_AR=${CMAKE_AR};-DCMAKE_INSTALL_RPATH=${RUNTIMES_INSTALL_RPATH};-DCMAKE_BUILD_WITH_INSTALL_RPATH=ON" CACHE STRING "") -set(RUNTIMES_CMAKE_ARGS "-DCMAKE_SYSTEM_NAME=Linux;-DCMAKE_AR=${CMAKE_AR};-DCMAKE_INSTALL_RPATH=${RUNTIMES_INSTALL_RPATH};-DCMAKE_BUILD_WITH_INSTALL_RPATH=ON" CACHE STRING "") +set(LLVM_BUILTIN_TARGETS "${TOOLCHAIN_TARGET_TRIPLE}" CACHE STRING "") + +set(BUILTINS_${TOOLCHAIN_TARGET_TRIPLE}_CMAKE_SYSTEM_NAME "Linux" CACHE STRING "") +set(BUILTINS_${TOOLCHAIN_TARGET_TRIPLE}_CMAKE_SYSROOT "${DEFAULT_SYSROOT}" CACHE STRING "") +set(BUILTINS_${TOOLCHAIN_TARGET_TRIPLE}_CMAKE_INSTALL_RPATH "${RUNTIMES_INSTALL_RPATH}" CACHE STRING "") +set(BUILTINS_${TOOLCHAIN_TARGET_TRIPLE}_CMAKE_BUILD_WITH_INSTALL_RPATH ON CACHE BOOL "") + + +set(LLVM_RUNTIME_TARGETS "${TOOLCHAIN_TARGET_TRIPLE}" CACHE STRING "") + +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_LLVM_ENABLE_RUNTIMES "${LLVM_ENABLE_RUNTIMES}" CACHE STRING "") + +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_CMAKE_SYSTEM_NAME "Linux" CACHE STRING "") +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_CMAKE_SYSROOT "${DEFAULT_SYSROOT}" CACHE STRING "") +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_CMAKE_INSTALL_RPATH "${RUNTIMES_INSTALL_RPATH}" CACHE STRING "") +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_CMAKE_BUILD_WITH_INSTALL_RPATH ON CACHE BOOL "") + +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_COMPILER_RT_BUILD_BUILTINS ON CACHE BOOL "") +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_COMPILER_RT_BUILD_SANITIZERS OFF CACHE BOOL "") +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_COMPILER_RT_BUILD_XRAY OFF CACHE BOOL "") +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_COMPILER_RT_BUILD_LIBFUZZER OFF CACHE BOOL "") +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_COMPILER_RT_BUILD_PROFILE OFF CACHE BOOL "") +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_COMPILER_RT_BUILD_CRT OFF CACHE BOOL "") +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_COMPILER_RT_BUILD_ORC OFF CACHE BOOL "") +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_COMPILER_RT_DEFAULT_TARGET_ONLY ON CACHE BOOL "") +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_COMPILER_RT_INCLUDE_TESTS ON CACHE BOOL "") +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_COMPILER_RT_CAN_EXECUTE_TESTS ON CACHE BOOL "") + +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_COMPILER_RT_USE_BUILTINS_LIBRARY ON CACHE BOOL "") + +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_LIBUNWIND_USE_COMPILER_RT ON CACHE BOOL "") +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_LIBUNWIND_ENABLE_SHARED OFF CACHE BOOL "") + +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_LIBCXXABI_USE_LLVM_UNWINDER ON CACHE BOOL "") +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_LIBCXXABI_ENABLE_STATIC_UNWINDER ON CACHE BOOL "") +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_LIBCXXABI_USE_COMPILER_RT ON CACHE BOOL "") +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_LIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS OFF CACHE BOOL "") +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_LIBCXXABI_ENABLE_SHARED OFF CACHE BOOL "") + +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_LIBCXX_USE_COMPILER_RT ON CACHE BOOL "") +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_LIBCXX_ENABLE_SHARED OFF CACHE BOOL "") +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_LIBCXX_ABI_VERSION 2 CACHE STRING "") +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_LIBCXX_CXX_ABI "libcxxabi" CACHE STRING "") #!!! +set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS ON CACHE BOOL "") + find_package(Python3 COMPONENTS Interpreter) # Remote test configuration. if(DEFINED REMOTE_TEST_HOST) - set(DEFAULT_TEST_EXECUTOR "\\\"${Python3_EXECUTABLE}\\\" \\\"${LLVM_PROJECT_DIR}/libcxx/utils/ssh.py\\\" --host='${REMOTE_TEST_USER}@${REMOTE_TEST_HOST}'") - set(DEFAULT_TEST_TARGET_INFO "libcxx.test.target_info.LinuxRemoteTI") - # Allow override with the custom values. - if(NOT DEFINED COMPILER_RT_EMULATOR) - set(COMPILER_RT_EMULATOR "\\\"${Python3_EXECUTABLE}\\\" \\\"${LLVM_PROJECT_DIR}/llvm/utils/remote-exec.py\\\" --execdir %%T --exec-pattern='.*\\.c.*\\.tmp.*' --host='${REMOTE_TEST_USER}@${REMOTE_TEST_HOST}'" CACHE STRING "") - endif() - if(NOT DEFINED LIBUNWIND_TARGET_INFO) - set(LIBUNWIND_TARGET_INFO "${DEFAULT_TEST_TARGET_INFO}" CACHE STRING "") - endif() - if(NOT DEFINED LIBUNWIND_EXECUTOR) - set(LIBUNWIND_EXECUTOR "${DEFAULT_TEST_EXECUTOR}" CACHE STRING "") - endif() - if(NOT DEFINED LIBCXXABI_TARGET_INFO) - set(LIBCXXABI_TARGET_INFO "${DEFAULT_TEST_TARGET_INFO}" CACHE STRING "") - endif() - if(NOT DEFINED LIBCXXABI_EXECUTOR) - set(LIBCXXABI_EXECUTOR "${DEFAULT_TEST_EXECUTOR}" CACHE STRING "") - endif() - if(NOT DEFINED LIBCXX_TARGET_INFO) - set(LIBCXX_TARGET_INFO "${DEFAULT_TEST_TARGET_INFO}" CACHE STRING "") - endif() - if(NOT DEFINED LIBCXX_EXECUTOR) - set(LIBCXX_EXECUTOR "${DEFAULT_TEST_EXECUTOR}" CACHE STRING "") + if(NOT DEFINED DEFAULT_TEST_EXECUTOR) + set(DEFAULT_TEST_EXECUTOR "\\\"${Python3_EXECUTABLE}\\\" \\\"${LLVM_PROJECT_DIR}/libcxx/utils/ssh.py\\\" --host=${REMOTE_TEST_USER}@${REMOTE_TEST_HOST}") endif() + + set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_COMPILER_RT_EMULATOR + "\\\"${Python3_EXECUTABLE}\\\" \\\"${LLVM_PROJECT_DIR}/llvm/utils/remote-exec.py\\\" --host=${REMOTE_TEST_USER}@${REMOTE_TEST_HOST}" + CACHE STRING "") + + set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_LIBUNWIND_EXECUTOR "${DEFAULT_TEST_EXECUTOR}" CACHE STRING "") + set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_LIBCXXABI_EXECUTOR "${DEFAULT_TEST_EXECUTOR}" CACHE STRING "") + set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_LIBCXX_EXECUTOR "${DEFAULT_TEST_EXECUTOR}" CACHE STRING "") endif() -set(LLVM_INSTALL_TOOLCHAIN_ONLY ON CACHE BOOL "") +set(LLVM_INSTALL_TOOLCHAIN_ONLY ON CACHE BOOL "") set(LLVM_TOOLCHAIN_TOOLS llvm-ar llvm-cov @@ -178,6 +177,7 @@ set(LLVM_TOOLCHAIN_TOOLS llvm-lib llvm-nm llvm-objdump + llvm-pdbutil llvm-profdata llvm-ranlib llvm-readobj diff --git a/gnu/llvm/clang/cmake/caches/Fuchsia-stage2.cmake b/gnu/llvm/clang/cmake/caches/Fuchsia-stage2.cmake index e50681484ff..a4984f095a2 100644 --- a/gnu/llvm/clang/cmake/caches/Fuchsia-stage2.cmake +++ b/gnu/llvm/clang/cmake/caches/Fuchsia-stage2.cmake @@ -4,25 +4,23 @@ set(LLVM_TARGETS_TO_BUILD X86;ARM;AArch64;RISCV CACHE STRING "") set(PACKAGE_VENDOR Fuchsia CACHE STRING "") -set(LLVM_ENABLE_PROJECTS "clang;clang-tools-extra;lld;llvm;polly" CACHE STRING "") +set(LLVM_ENABLE_PROJECTS "bolt;clang;clang-tools-extra;lld;llvm;polly" CACHE STRING "") set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi;libunwind" CACHE STRING "") set(LLVM_ENABLE_BACKTRACES OFF CACHE BOOL "") set(LLVM_ENABLE_DIA_SDK OFF CACHE BOOL "") -if(NOT APPLE) - # TODO: Remove this once we switch to ld64.lld. - set(LLVM_ENABLE_LLD ON CACHE BOOL "") -endif() +set(LLVM_ENABLE_LIBCXX ON CACHE BOOL "") +set(LLVM_ENABLE_LIBEDIT OFF CACHE BOOL "") +set(LLVM_ENABLE_LLD ON CACHE BOOL "") set(LLVM_ENABLE_LTO ON CACHE BOOL "") set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR ON CACHE BOOL "") -set(LLVM_ENABLE_LIBCXX ON CACHE BOOL "") +set(LLVM_ENABLE_PLUGINS OFF CACHE BOOL "") set(LLVM_ENABLE_TERMINFO OFF CACHE BOOL "") set(LLVM_ENABLE_UNWIND_TABLES OFF CACHE BOOL "") set(LLVM_ENABLE_Z3_SOLVER OFF CACHE BOOL "") set(LLVM_ENABLE_ZLIB ON CACHE BOOL "") set(LLVM_INCLUDE_DOCS OFF CACHE BOOL "") set(LLVM_INCLUDE_EXAMPLES OFF CACHE BOOL "") -set(LLVM_INCLUDE_GO_TESTS OFF CACHE BOOL "") set(LLVM_STATIC_LINK_CXX_STDLIB ON CACHE BOOL "") set(LLVM_USE_RELATIVE_PATHS_IN_FILES ON CACHE BOOL "") @@ -31,12 +29,10 @@ if(WIN32) endif() set(CLANG_DEFAULT_CXX_STDLIB libc++ CACHE STRING "") -if(NOT APPLE) - # TODO: Remove this once we switch to ld64.lld. - set(CLANG_DEFAULT_LINKER lld CACHE STRING "") - set(CLANG_DEFAULT_OBJCOPY llvm-objcopy CACHE STRING "") -endif() +set(CLANG_DEFAULT_LINKER lld CACHE STRING "") +set(CLANG_DEFAULT_OBJCOPY llvm-objcopy CACHE STRING "") set(CLANG_DEFAULT_RTLIB compiler-rt CACHE STRING "") +set(CLANG_DEFAULT_UNWINDLIB libunwind CACHE STRING "") set(CLANG_ENABLE_ARCMT OFF CACHE BOOL "") set(CLANG_ENABLE_STATIC_ANALYZER ON CACHE BOOL "") set(CLANG_PLUGIN_SUPPORT OFF CACHE BOOL "") @@ -60,21 +56,17 @@ if(APPLE) set(COMPILER_RT_USE_BUILTINS_LIBRARY ON CACHE BOOL "") set(LIBUNWIND_ENABLE_SHARED OFF CACHE BOOL "") - set(LIBUNWIND_INSTALL_LIBRARY OFF CACHE BOOL "") set(LIBUNWIND_USE_COMPILER_RT ON CACHE BOOL "") set(LIBCXXABI_ENABLE_SHARED OFF CACHE BOOL "") set(LIBCXXABI_ENABLE_STATIC_UNWINDER ON CACHE BOOL "") set(LIBCXXABI_INSTALL_LIBRARY OFF CACHE BOOL "") set(LIBCXXABI_USE_COMPILER_RT ON CACHE BOOL "") set(LIBCXXABI_USE_LLVM_UNWINDER ON CACHE BOOL "") - set(LIBCXX_USE_COMPILER_RT ON CACHE BOOL "") + set(LIBCXX_ABI_VERSION 2 CACHE STRING "") set(LIBCXX_ENABLE_SHARED OFF CACHE BOOL "") set(LIBCXX_ENABLE_STATIC_ABI_LIBRARY ON CACHE BOOL "") - set(LIBCXX_ABI_VERSION 2 CACHE STRING "") - set(DARWIN_ios_ARCHS armv7;armv7s;arm64 CACHE STRING "") - set(DARWIN_iossim_ARCHS i386;x86_64 CACHE STRING "") - set(DARWIN_osx_ARCHS arm64;x86_64 CACHE STRING "") - set(SANITIZER_MIN_OSX_VERSION 10.7 CACHE STRING "") + set(LIBCXX_USE_COMPILER_RT ON CACHE BOOL "") + set(RUNTIMES_CMAKE_ARGS "-DCMAKE_OSX_DEPLOYMENT_TARGET=10.13;-DCMAKE_OSX_ARCHITECTURES=arm64|x86_64" CACHE STRING "") endif() if(WIN32) @@ -88,7 +80,6 @@ if(WIN32) set(RUNTIMES_${target}_CMAKE_SYSTEM_NAME Windows CACHE STRING "") set(RUNTIMES_${target}_CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "") set(RUNTIMES_${target}_LIBCXX_ABI_VERSION 2 CACHE STRING "") - set(RUNTIMES_${target}_LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY OFF CACHE BOOL "") set(RUNTIMES_${target}_LIBCXX_ENABLE_FILESYSTEM OFF CACHE BOOL "") set(RUNTIMES_${target}_LIBCXX_ENABLE_ABI_LINKER_SCRIPT OFF CACHE BOOL "") set(RUNTIMES_${target}_LIBCXX_ENABLE_SHARED OFF CACHE BOOL "") @@ -120,14 +111,15 @@ foreach(target aarch64-unknown-linux-gnu;armv7-unknown-linux-gnueabihf;i386-unkn set(RUNTIMES_${target}_CMAKE_SHARED_LINKER_FLAGS "-fuse-ld=lld" CACHE STRING "") set(RUNTIMES_${target}_CMAKE_MODULE_LINKER_FLAGS "-fuse-ld=lld" CACHE STRING "") set(RUNTIMES_${target}_CMAKE_EXE_LINKER_FLAGS "-fuse-ld=lld" CACHE STRING "") + set(RUNTIMES_${target}_COMPILER_RT_CXX_LIBRARY "libcxx" CACHE STRING "") set(RUNTIMES_${target}_COMPILER_RT_USE_BUILTINS_LIBRARY ON CACHE BOOL "") + set(RUNTIMES_${target}_COMPILER_RT_USE_LLVM_UNWINDER ON CACHE BOOL "") + set(RUNTIMES_${target}_COMPILER_RT_CAN_EXECUTE_TESTS ON CACHE BOOL "") set(RUNTIMES_${target}_LIBUNWIND_ENABLE_SHARED OFF CACHE BOOL "") set(RUNTIMES_${target}_LIBUNWIND_USE_COMPILER_RT ON CACHE BOOL "") - set(RUNTIMES_${target}_LIBUNWIND_INSTALL_LIBRARY OFF CACHE BOOL "") set(RUNTIMES_${target}_LIBCXXABI_USE_COMPILER_RT ON CACHE BOOL "") set(RUNTIMES_${target}_LIBCXXABI_ENABLE_SHARED OFF CACHE BOOL "") set(RUNTIMES_${target}_LIBCXXABI_USE_LLVM_UNWINDER ON CACHE BOOL "") - set(RUNTIMES_${target}_LIBCXXABI_ENABLE_STATIC_UNWINDER ON CACHE BOOL "") set(RUNTIMES_${target}_LIBCXXABI_INSTALL_LIBRARY OFF CACHE BOOL "") set(RUNTIMES_${target}_LIBCXX_USE_COMPILER_RT ON CACHE BOOL "") set(RUNTIMES_${target}_LIBCXX_ENABLE_SHARED OFF CACHE BOOL "") @@ -136,6 +128,9 @@ foreach(target aarch64-unknown-linux-gnu;armv7-unknown-linux-gnueabihf;i386-unkn set(RUNTIMES_${target}_LLVM_ENABLE_ASSERTIONS OFF CACHE BOOL "") set(RUNTIMES_${target}_SANITIZER_CXX_ABI "libc++" CACHE STRING "") set(RUNTIMES_${target}_SANITIZER_CXX_ABI_INTREE ON CACHE BOOL "") + set(RUNTIMES_${target}_SANITIZER_TEST_CXX "libc++" CACHE STRING "") + set(RUNTIMES_${target}_SANITIZER_TEST_CXX_INTREE ON CACHE BOOL "") + set(RUNTIMES_${target}_LLVM_TOOLS_DIR "${CMAKE_BINARY_DIR}/bin" CACHE BOOL "") set(RUNTIMES_${target}_LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi;libunwind" CACHE STRING "") # Use .build-id link. @@ -181,16 +176,15 @@ if(FUCHSIA_SDK) set(RUNTIMES_${target}_CMAKE_MODULE_LINKER_FLAGS ${FUCHSIA_${target}_LINKER_FLAGS} CACHE STRING "") set(RUNTIMES_${target}_CMAKE_EXE_LINKER_FLAGS ${FUCHSIA_${target}_LINKER_FLAGS} CACHE STRING "") set(RUNTIMES_${target}_CMAKE_SYSROOT ${FUCHSIA_${target}_SYSROOT} CACHE PATH "") + set(RUNTIMES_${target}_COMPILER_RT_CXX_LIBRARY "libcxx" CACHE STRING "") set(RUNTIMES_${target}_COMPILER_RT_USE_BUILTINS_LIBRARY ON CACHE BOOL "") + set(RUNTIMES_${target}_COMPILER_RT_USE_LLVM_UNWINDER ON CACHE BOOL "") set(RUNTIMES_${target}_LIBUNWIND_USE_COMPILER_RT ON CACHE BOOL "") set(RUNTIMES_${target}_LIBUNWIND_HIDE_SYMBOLS ON CACHE BOOL "") - set(RUNTIMES_${target}_LIBUNWIND_INSTALL_STATIC_LIBRARY OFF CACHE BOOL "") set(RUNTIMES_${target}_LIBCXXABI_USE_COMPILER_RT ON CACHE BOOL "") set(RUNTIMES_${target}_LIBCXXABI_USE_LLVM_UNWINDER ON CACHE BOOL "") - set(RUNTIMES_${target}_LIBCXXABI_ENABLE_STATIC_UNWINDER ON CACHE BOOL "") set(RUNTIMES_${target}_LIBCXXABI_HERMETIC_STATIC_LIBRARY ON CACHE BOOL "") set(RUNTIMES_${target}_LIBCXXABI_INSTALL_STATIC_LIBRARY OFF CACHE BOOL "") - set(RUNTIMES_${target}_LIBCXXABI_STATICALLY_LINK_UNWINDER_IN_SHARED_LIBRARY OFF CACHE BOOL "") set(RUNTIMES_${target}_LIBCXX_USE_COMPILER_RT ON CACHE BOOL "") set(RUNTIMES_${target}_LIBCXX_ENABLE_STATIC_ABI_LIBRARY ON CACHE BOOL "") set(RUNTIMES_${target}_LIBCXX_HERMETIC_STATIC_LIBRARY ON CACHE BOOL "") @@ -225,11 +219,30 @@ if(FUCHSIA_SDK) list(APPEND RUNTIME_BUILD_ID_LINK "${target}") endforeach() - set(LLVM_RUNTIME_MULTILIBS "asan;noexcept;compat;asan+noexcept" CACHE STRING "") + # HWAsan + set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_LLVM_BUILD_COMPILER_RT OFF CACHE BOOL "") + set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_LLVM_USE_SANITIZER "HWAddress" CACHE STRING "") + set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_LIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS OFF CACHE BOOL "") + set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS OFF CACHE BOOL "") + set(RUNTIMES_aarch64-unknown-fuchsia+hwasan_CMAKE_CXX_FLAGS "${FUCHSIA_aarch64-unknown-fuchsia_COMPILER_FLAGS} -mllvm --hwasan-globals=0" CACHE STRING "") + + # HWASan+noexcept + set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LLVM_BUILD_COMPILER_RT OFF CACHE BOOL "") + set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LLVM_USE_SANITIZER "HWAddress" CACHE STRING "") + set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS OFF CACHE BOOL "") + set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS OFF CACHE BOOL "") + set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LIBCXXABI_ENABLE_EXCEPTIONS OFF CACHE BOOL "") + set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_LIBCXX_ENABLE_EXCEPTIONS OFF CACHE BOOL "") + set(RUNTIMES_aarch64-unknown-fuchsia+hwasan+noexcept_CMAKE_CXX_FLAGS "${FUCHSIA_aarch64-unknown-fuchsia_COMPILER_FLAGS} -mllvm --hwasan-globals=0" CACHE STRING "") + + set(LLVM_RUNTIME_MULTILIBS "asan;noexcept;compat;asan+noexcept;hwasan;hwasan+noexcept" CACHE STRING "") + set(LLVM_RUNTIME_MULTILIB_asan_TARGETS "x86_64-unknown-fuchsia;aarch64-unknown-fuchsia" CACHE STRING "") set(LLVM_RUNTIME_MULTILIB_noexcept_TARGETS "x86_64-unknown-fuchsia;aarch64-unknown-fuchsia" CACHE STRING "") set(LLVM_RUNTIME_MULTILIB_compat_TARGETS "x86_64-unknown-fuchsia;aarch64-unknown-fuchsia" CACHE STRING "") set(LLVM_RUNTIME_MULTILIB_asan+noexcept_TARGETS "x86_64-unknown-fuchsia;aarch64-unknown-fuchsia" CACHE STRING "") + set(LLVM_RUNTIME_MULTILIB_hwasan_TARGETS "aarch64-unknown-fuchsia" CACHE STRING "") + set(LLVM_RUNTIME_MULTILIB_hwasan+noexcept_TARGETS "aarch64-unknown-fuchsia" CACHE STRING "") endif() set(LLVM_BUILTIN_TARGETS "${BUILTIN_TARGETS}" CACHE STRING "") @@ -242,18 +255,22 @@ set(LLVM_TOOLCHAIN_TOOLS llvm-ar llvm-cov llvm-cxxfilt + llvm-debuginfod-find llvm-dlltool llvm-dwarfdump llvm-dwp llvm-ifs llvm-gsymutil llvm-lib + llvm-libtool-darwin llvm-lipo + llvm-ml llvm-mt llvm-nm llvm-objcopy llvm-objdump llvm-otool + llvm-pdbutil llvm-profdata llvm-rc llvm-ranlib @@ -262,12 +279,14 @@ set(LLVM_TOOLCHAIN_TOOLS llvm-size llvm-strip llvm-symbolizer + llvm-undname llvm-xray sancov scan-build-py CACHE STRING "") set(LLVM_DISTRIBUTION_COMPONENTS + bolt clang lld LTO @@ -280,6 +299,7 @@ set(LLVM_DISTRIBUTION_COMPONENTS clang-scan-deps clang-tidy clangd + find-all-symbols builtins runtimes ${LLVM_TOOLCHAIN_TOOLS} diff --git a/gnu/llvm/clang/cmake/caches/Fuchsia.cmake b/gnu/llvm/clang/cmake/caches/Fuchsia.cmake index a98354b7782..7537bf8a3ee 100644 --- a/gnu/llvm/clang/cmake/caches/Fuchsia.cmake +++ b/gnu/llvm/clang/cmake/caches/Fuchsia.cmake @@ -4,10 +4,11 @@ set(LLVM_TARGETS_TO_BUILD X86;ARM;AArch64;RISCV CACHE STRING "") set(PACKAGE_VENDOR Fuchsia CACHE STRING "") -set(LLVM_ENABLE_PROJECTS "clang;clang-tools-extra;lld;llvm;polly" CACHE STRING "") +set(LLVM_ENABLE_PROJECTS "bolt;clang;clang-tools-extra;lld;llvm;polly" CACHE STRING "") -set(LLVM_ENABLE_BACKTRACES OFF CACHE BOOL "") set(LLVM_ENABLE_DIA_SDK OFF CACHE BOOL "") +set(LLVM_ENABLE_LIBEDIT OFF CACHE BOOL "") +set(LLVM_ENABLE_LIBXML2 OFF CACHE BOOL "") set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR ON CACHE BOOL "") set(LLVM_ENABLE_TERMINFO OFF CACHE BOOL "") set(LLVM_ENABLE_UNWIND_TABLES OFF CACHE BOOL "") @@ -15,27 +16,25 @@ set(LLVM_ENABLE_Z3_SOLVER OFF CACHE BOOL "") set(LLVM_ENABLE_ZLIB OFF CACHE BOOL "") set(LLVM_INCLUDE_DOCS OFF CACHE BOOL "") set(LLVM_INCLUDE_EXAMPLES OFF CACHE BOOL "") -set(LLVM_INCLUDE_GO_TESTS OFF CACHE BOOL "") if(WIN32) set(LLVM_USE_CRT_RELEASE "MT" CACHE STRING "") endif() set(CLANG_DEFAULT_CXX_STDLIB libc++ CACHE STRING "") -if(NOT APPLE) - # TODO: Remove this once we switch to ld64.lld. - set(CLANG_DEFAULT_LINKER lld CACHE STRING "") - set(CLANG_DEFAULT_OBJCOPY llvm-objcopy CACHE STRING "") -endif() +set(CLANG_DEFAULT_LINKER lld CACHE STRING "") +set(CLANG_DEFAULT_OBJCOPY llvm-objcopy CACHE STRING "") set(CLANG_DEFAULT_RTLIB compiler-rt CACHE STRING "") +set(CLANG_DEFAULT_UNWINDLIB libunwind CACHE STRING "") set(CLANG_ENABLE_ARCMT OFF CACHE BOOL "") -set(CLANG_ENABLE_STATIC_ANALYZER ON CACHE BOOL "") +set(CLANG_ENABLE_STATIC_ANALYZER OFF CACHE BOOL "") set(CLANG_PLUGIN_SUPPORT OFF CACHE BOOL "") set(ENABLE_LINKER_BUILD_ID ON CACHE BOOL "") set(ENABLE_X86_RELAX_RELOCATIONS ON CACHE BOOL "") set(LLVM_ENABLE_ASSERTIONS ON CACHE BOOL "") +set(LLVM_ENABLE_BACKTRACES ON CACHE BOOL "") set(CMAKE_BUILD_TYPE Release CACHE STRING "") if(APPLE) set(CMAKE_OSX_DEPLOYMENT_TARGET "10.13" CACHE STRING "") @@ -49,28 +48,29 @@ if(APPLE) set(COMPILER_RT_ENABLE_WATCHOS OFF CACHE BOOL "") endif() -set(LIBUNWIND_ENABLE_SHARED OFF CACHE BOOL "") -set(LIBUNWIND_INSTALL_LIBRARY OFF CACHE BOOL "") -set(LIBUNWIND_USE_COMPILER_RT ON CACHE BOOL "") -set(LIBCXXABI_ENABLE_SHARED OFF CACHE BOOL "") -set(LIBCXXABI_ENABLE_STATIC_UNWINDER ON CACHE BOOL "") -set(LIBCXXABI_INSTALL_LIBRARY OFF CACHE BOOL "") -set(LIBCXXABI_USE_COMPILER_RT ON CACHE BOOL "") -set(LIBCXXABI_USE_LLVM_UNWINDER ON CACHE BOOL "") -set(LIBCXX_ABI_VERSION 2 CACHE STRING "") -set(LIBCXX_ENABLE_SHARED OFF CACHE BOOL "") if(WIN32) - set(LIBCXX_HAS_WIN32_THREAD_API ON CACHE BOOL "") - set(LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY OFF CACHE BOOL "") + set(LIBCXX_ABI_VERSION 2 CACHE STRING "") set(LIBCXX_ENABLE_FILESYSTEM OFF CACHE BOOL "") set(LIBCXX_ENABLE_ABI_LINKER_SCRIPT OFF CACHE BOOL "") - set(LIBCXX_ENABLE_STATIC_ABI_LIBRARY OFF CACHE BOOL "") + set(LIBCXX_ENABLE_SHARED OFF CACHE BOOL "") set(BUILTINS_CMAKE_ARGS -DCMAKE_SYSTEM_NAME=Windows CACHE STRING "") set(RUNTIMES_CMAKE_ARGS -DCMAKE_SYSTEM_NAME=Windows CACHE STRING "") set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx" CACHE STRING "") else() + set(LIBUNWIND_ENABLE_SHARED OFF CACHE BOOL "") + set(LIBUNWIND_INSTALL_LIBRARY OFF CACHE BOOL "") + set(LIBUNWIND_USE_COMPILER_RT ON CACHE BOOL "") + set(LIBCXXABI_ENABLE_SHARED OFF CACHE BOOL "") + set(LIBCXXABI_ENABLE_STATIC_UNWINDER ON CACHE BOOL "") + set(LIBCXXABI_INSTALL_LIBRARY OFF CACHE BOOL "") + set(LIBCXXABI_USE_COMPILER_RT ON CACHE BOOL "") + set(LIBCXXABI_USE_LLVM_UNWINDER ON CACHE BOOL "") + set(LIBCXX_ABI_VERSION 2 CACHE STRING "") + set(LIBCXX_ENABLE_SHARED OFF CACHE BOOL "") set(LIBCXX_ENABLE_STATIC_ABI_LIBRARY ON CACHE BOOL "") + set(LIBCXX_USE_COMPILER_RT ON CACHE BOOL "") set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi;libunwind" CACHE STRING "") + set(RUNTIMES_CMAKE_ARGS "-DCMAKE_OSX_DEPLOYMENT_TARGET=10.13;-DCMAKE_OSX_ARCHITECTURES=arm64|x86_64" CACHE STRING "") endif() if(BOOTSTRAP_CMAKE_SYSTEM_NAME) @@ -111,11 +111,8 @@ if(UNIX) set(BOOTSTRAP_CMAKE_EXE_LINKER_FLAGS "-ldl -lpthread" CACHE STRING "") endif() +set(BOOTSTRAP_LLVM_ENABLE_LLD ON CACHE BOOL "") set(BOOTSTRAP_LLVM_ENABLE_LTO ON CACHE BOOL "") -if(NOT APPLE) - # TODO: Remove this once we switch to ld64.lld. - set(BOOTSTRAP_LLVM_ENABLE_LLD ON CACHE BOOL "") -endif() set(CLANG_BOOTSTRAP_TARGETS check-all diff --git a/gnu/llvm/clang/cmake/caches/HLSL.cmake b/gnu/llvm/clang/cmake/caches/HLSL.cmake new file mode 100644 index 00000000000..71f81e53f6b --- /dev/null +++ b/gnu/llvm/clang/cmake/caches/HLSL.cmake @@ -0,0 +1,13 @@ +# Including the native target is important because some of LLVM's tests fail if +# you don't. +set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "") + +# Include the DirectX target for DXIL code generation, eventually we'll include +# SPIR-V here too. +set(LLVM_EXPERIMENTAL_TARGETS_TO_BUILD DirectX CACHE STRING "") + +# HLSL support is currently limted to clang, eventually it will expand to +# clang-tools-extra too. +set(LLVM_ENABLE_PROJECTS "clang" CACHE STRING "") + +set(CLANG_ENABLE_HLSL On CACHE BOOL "") diff --git a/gnu/llvm/clang/cmake/caches/MultiDistributionExample.cmake b/gnu/llvm/clang/cmake/caches/MultiDistributionExample.cmake index 0c97611e252..de10dcc11b9 100644 --- a/gnu/llvm/clang/cmake/caches/MultiDistributionExample.cmake +++ b/gnu/llvm/clang/cmake/caches/MultiDistributionExample.cmake @@ -1,5 +1,5 @@ # This file sets up a CMakeCache for a simple build with multiple distributions. -# Note that for a real distribution, you likely want to perform a boostrap +# Note that for a real distribution, you likely want to perform a bootstrap # build; see clang/cmake/caches/DistributionExample.cmake and the # BuildingADistribution documentation for details. This cache file doesn't # demonstrate bootstrapping so it can focus on the configuration details diff --git a/gnu/llvm/clang/cmake/caches/PGO-stage2.cmake b/gnu/llvm/clang/cmake/caches/PGO-stage2.cmake index 2080cd405f2..b9b2f62e9ca 100644 --- a/gnu/llvm/clang/cmake/caches/PGO-stage2.cmake +++ b/gnu/llvm/clang/cmake/caches/PGO-stage2.cmake @@ -1,2 +1,3 @@ set(CMAKE_BUILD_TYPE RELEASE CACHE STRING "") -set(LLVM_BUILD_EXTERNAL_COMPILER_RT ON CACHE BOOL "") +set(LLVM_ENABLE_PROJECTS "clang;lld" CACHE STRING "") +set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi" CACHE STRING "") diff --git a/gnu/llvm/clang/cmake/caches/PGO.cmake b/gnu/llvm/clang/cmake/caches/PGO.cmake index 7e4a001129c..e1d0585e453 100644 --- a/gnu/llvm/clang/cmake/caches/PGO.cmake +++ b/gnu/llvm/clang/cmake/caches/PGO.cmake @@ -1,8 +1,10 @@ set(CMAKE_BUILD_TYPE RELEASE CACHE STRING "") set(CLANG_ENABLE_BOOTSTRAP ON CACHE BOOL "") -set(LLVM_BUILD_EXTERNAL_COMPILER_RT ON CACHE BOOL "") -set(LLVM_TARGETS_TO_BUILD X86 CACHE STRING "") +set(LLVM_ENABLE_PROJECTS "clang;lld" CACHE STRING "") +set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi" CACHE STRING "") + +set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "") set(BOOTSTRAP_LLVM_BUILD_INSTRUMENTED ON CACHE BOOL "") set(CLANG_BOOTSTRAP_TARGETS generate-profdata diff --git a/gnu/llvm/clang/cmake/modules/AddClang.cmake b/gnu/llvm/clang/cmake/modules/AddClang.cmake index 5752f427744..75b0080f671 100644 --- a/gnu/llvm/clang/cmake/modules/AddClang.cmake +++ b/gnu/llvm/clang/cmake/modules/AddClang.cmake @@ -1,3 +1,4 @@ +include(GNUInstallDirs) include(LLVMDistributionSupport) function(clang_tablegen) @@ -36,7 +37,7 @@ macro(set_clang_windows_version_resource_properties name) VERSION_MAJOR ${CLANG_VERSION_MAJOR} VERSION_MINOR ${CLANG_VERSION_MINOR} VERSION_PATCHLEVEL ${CLANG_VERSION_PATCHLEVEL} - VERSION_STRING "${CLANG_VERSION} (${BACKEND_PACKAGE_STRING})" + VERSION_STRING "${CLANG_VERSION}" PRODUCT_NAME "clang") endif() endmacro() @@ -69,7 +70,7 @@ macro(add_clang_library name) ${CLANG_SOURCE_DIR}/include/clang/${lib_path}/*.td ) source_group("TableGen descriptions" FILES ${tds}) - set_source_files_properties(${tds}} PROPERTIES HEADER_FILE_ONLY ON) + set_source_files_properties(${tds} PROPERTIES HEADER_FILE_ONLY ON) if(headers OR tds) set(srcs ${headers} ${tds}) @@ -120,7 +121,7 @@ macro(add_clang_library name) ${export_to_clangtargets} LIBRARY DESTINATION lib${LLVM_LIBDIR_SUFFIX} ARCHIVE DESTINATION lib${LLVM_LIBDIR_SUFFIX} - RUNTIME DESTINATION bin) + RUNTIME DESTINATION "${CMAKE_INSTALL_BINDIR}") if (NOT LLVM_ENABLE_IDE) add_llvm_install_targets(install-${lib} @@ -148,40 +149,66 @@ macro(add_clang_executable name) endmacro(add_clang_executable) macro(add_clang_tool name) + cmake_parse_arguments(ARG "DEPENDS;GENERATE_DRIVER" "" "" ${ARGN}) if (NOT CLANG_BUILD_TOOLS) set(EXCLUDE_FROM_ALL ON) endif() - - add_clang_executable(${name} ${ARGN}) - add_dependencies(${name} clang-resource-headers) - - if (CLANG_BUILD_TOOLS) - get_target_export_arg(${name} Clang export_to_clangtargets) - install(TARGETS ${name} - ${export_to_clangtargets} - RUNTIME DESTINATION bin - COMPONENT ${name}) - - if(NOT LLVM_ENABLE_IDE) - add_llvm_install_targets(install-${name} - DEPENDS ${name} - COMPONENT ${name}) + if(ARG_GENERATE_DRIVER + AND LLVM_TOOL_LLVM_DRIVER_BUILD + AND (NOT LLVM_DISTRIBUTION_COMPONENTS OR ${name} IN_LIST LLVM_DISTRIBUTION_COMPONENTS) + ) + set(get_obj_args ${ARGN}) + list(FILTER get_obj_args EXCLUDE REGEX "^SUPPORT_PLUGINS$") + generate_llvm_objects(${name} ${get_obj_args}) + add_custom_target(${name} DEPENDS llvm-driver clang-resource-headers) + else() + add_clang_executable(${name} ${ARGN}) + add_dependencies(${name} clang-resource-headers) + + if (CLANG_BUILD_TOOLS) + get_target_export_arg(${name} Clang export_to_clangtargets) + install(TARGETS ${name} + ${export_to_clangtargets} + RUNTIME DESTINATION "${CMAKE_INSTALL_BINDIR}" + COMPONENT ${name}) + + if(NOT LLVM_ENABLE_IDE) + add_llvm_install_targets(install-${name} + DEPENDS ${name} + COMPONENT ${name}) + endif() + set_property(GLOBAL APPEND PROPERTY CLANG_EXPORTS ${name}) endif() - set_property(GLOBAL APPEND PROPERTY CLANG_EXPORTS ${name}) endif() endmacro() macro(add_clang_symlink name dest) - add_llvm_tool_symlink(${name} ${dest} ALWAYS_GENERATE) - # Always generate install targets - llvm_install_symlink(${name} ${dest} ALWAYS_GENERATE) + get_property(LLVM_DRIVER_TOOLS GLOBAL PROPERTY LLVM_DRIVER_TOOLS) + if(LLVM_TOOL_LLVM_DRIVER_BUILD + AND ${dest} IN_LIST LLVM_DRIVER_TOOLS + AND (NOT LLVM_DISTRIBUTION_COMPONENTS OR ${dest} IN_LIST LLVM_DISTRIBUTION_COMPONENTS) + ) + set_property(GLOBAL APPEND PROPERTY LLVM_DRIVER_TOOL_ALIASES_${dest} ${name}) + else() + llvm_add_tool_symlink(CLANG ${name} ${dest} ALWAYS_GENERATE) + # Always generate install targets + llvm_install_symlink(CLANG ${name} ${dest} ALWAYS_GENERATE) + endif() endmacro() function(clang_target_link_libraries target type) + if (TARGET obj.${target}) + target_link_libraries(obj.${target} ${ARGN}) + endif() + + get_property(LLVM_DRIVER_TOOLS GLOBAL PROPERTY LLVM_DRIVER_TOOLS) + if(LLVM_TOOL_LLVM_DRIVER_BUILD AND ${target} IN_LIST LLVM_DRIVER_TOOLS) + set(target llvm-driver) + endif() + if (CLANG_LINK_CLANG_DYLIB) target_link_libraries(${target} ${type} clang-cpp) else() target_link_libraries(${target} ${type} ${ARGN}) endif() - endfunction() diff --git a/gnu/llvm/clang/cmake/modules/AddGRPC.cmake b/gnu/llvm/clang/cmake/modules/AddGRPC.cmake new file mode 100644 index 00000000000..8989bd757d2 --- /dev/null +++ b/gnu/llvm/clang/cmake/modules/AddGRPC.cmake @@ -0,0 +1,11 @@ +include(FindGRPC) + +function(generate_clang_protos_library LibraryName ProtoFile) + # Take the first two args and forward the remaining to generate_proto_sources. + cmake_parse_arguments(PARSE_ARGV 2 PROTO "" "" "") + generate_proto_sources(ProtoSource ${ProtoFile} ${PROTO_UNPARSED_ARGUMENTS}) + + add_clang_library(${LibraryName} ${ProtoSource} + PARTIAL_SOURCES_INTENDED + LINK_LIBS PUBLIC grpc++ protobuf) +endfunction() diff --git a/gnu/llvm/clang/cmake/modules/CMakeLists.txt b/gnu/llvm/clang/cmake/modules/CMakeLists.txt index 561665d58ca..d2d68121371 100644 --- a/gnu/llvm/clang/cmake/modules/CMakeLists.txt +++ b/gnu/llvm/clang/cmake/modules/CMakeLists.txt @@ -1,14 +1,22 @@ +include(GNUInstallPackageDir) +include(ExtendPath) include(LLVMDistributionSupport) +include(FindPrefixFromConfig) # Generate a list of CMake library targets so that other CMake projects can # link against them. LLVM calls its version of this file LLVMExports.cmake, but # the usual CMake convention seems to be ${Project}Targets.cmake. -set(CLANG_INSTALL_PACKAGE_DIR lib${LLVM_LIBDIR_SUFFIX}/cmake/clang) -set(clang_cmake_builddir "${CMAKE_BINARY_DIR}/${CLANG_INSTALL_PACKAGE_DIR}") +set(CLANG_INSTALL_PACKAGE_DIR "${CMAKE_INSTALL_PACKAGEDIR}/clang" CACHE STRING + "Path for CMake subdirectory for Clang (defaults to '${CMAKE_INSTALL_PACKAGEDIR}/clang')") +# CMAKE_INSTALL_PACKAGEDIR might be absolute, so don't reuse below. +set(clang_cmake_builddir "${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/clang") # Keep this in sync with llvm/cmake/CMakeLists.txt! -set(LLVM_INSTALL_PACKAGE_DIR lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm) -set(llvm_cmake_builddir "${LLVM_BINARY_DIR}/${LLVM_INSTALL_PACKAGE_DIR}") +set(LLVM_INSTALL_PACKAGE_DIR "${CMAKE_INSTALL_PACKAGEDIR}/llvm" CACHE STRING + "Path for CMake subdirectory for LLVM (defaults to '${CMAKE_INSTALL_PACKAGEDIR}/llvm')") +# CMAKE_INSTALL_PACKAGEDIR might be absolute, so don't reuse below. +string(REPLACE "${CMAKE_CFG_INTDIR}" "." llvm_cmake_builddir "${LLVM_LIBRARY_DIR}") +set(llvm_cmake_builddir "${llvm_cmake_builddir}/cmake/llvm") get_property(CLANG_EXPORTS GLOBAL PROPERTY CLANG_EXPORTS) export(TARGETS ${CLANG_EXPORTS} FILE ${clang_cmake_builddir}/ClangTargets.cmake) @@ -25,30 +33,41 @@ configure_file( ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake.in ${clang_cmake_builddir}/ClangConfig.cmake @ONLY) +configure_file( + ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfigVersion.cmake.in + ${clang_cmake_builddir}/ClangConfigVersion.cmake + @ONLY) set(CLANG_CONFIG_CMAKE_DIR) set(CLANG_CONFIG_LLVM_CMAKE_DIR) +# For compatibility with projects that include(ClangConfig) +# via CMAKE_MODULE_PATH, place API modules next to it. +# Copy without source permissions because the source could be read-only, +# but we need to write into the copied folder. +file(COPY . + DESTINATION ${clang_cmake_builddir} + NO_SOURCE_PERMISSIONS + FILES_MATCHING PATTERN *.cmake + PATTERN CMakeFiles EXCLUDE + ) + # Generate ClangConfig.cmake for the install tree. -set(CLANG_CONFIG_CODE " -# Compute the installation prefix from this LLVMConfig.cmake file location. -get_filename_component(CLANG_INSTALL_PREFIX \"\${CMAKE_CURRENT_LIST_FILE}\" PATH)") -# Construct the proper number of get_filename_component(... PATH) -# calls to compute the installation prefix. -string(REGEX REPLACE "/" ";" _count "${CLANG_INSTALL_PACKAGE_DIR}") -foreach(p ${_count}) - set(CLANG_CONFIG_CODE "${CLANG_CONFIG_CODE} -get_filename_component(CLANG_INSTALL_PREFIX \"\${CLANG_INSTALL_PREFIX}\" PATH)") -endforeach(p) -set(CLANG_CONFIG_CMAKE_DIR "\${CLANG_INSTALL_PREFIX}/${CLANG_INSTALL_PACKAGE_DIR}") -set(CLANG_CONFIG_LLVM_CMAKE_DIR "\${CLANG_INSTALL_PREFIX}/${LLVM_INSTALL_PACKAGE_DIR}") +find_prefix_from_config(CLANG_CONFIG_CODE CLANG_INSTALL_PREFIX "${CLANG_INSTALL_PACKAGE_DIR}") +extend_path(CLANG_CONFIG_CMAKE_DIR "\${CLANG_INSTALL_PREFIX}" "${CLANG_INSTALL_PACKAGE_DIR}") +extend_path(CLANG_CONFIG_LLVM_CMAKE_DIR "\${CLANG_INSTALL_PREFIX}" "${LLVM_INSTALL_PACKAGE_DIR}") get_config_exports_includes(Clang CLANG_CONFIG_INCLUDE_EXPORTS) +extend_path(base_includedir "\${CLANG_INSTALL_PREFIX}" "${CMAKE_INSTALL_INCLUDEDIR}") set(CLANG_CONFIG_INCLUDE_DIRS - "\${CLANG_INSTALL_PREFIX}/include" + "${base_includedir}" ) configure_file( ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfig.cmake.in ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/ClangConfig.cmake @ONLY) +configure_file( + ${CMAKE_CURRENT_SOURCE_DIR}/ClangConfigVersion.cmake.in + ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/ClangConfigVersion.cmake + @ONLY) set(CLANG_CONFIG_CODE) set(CLANG_CONFIG_CMAKE_DIR) @@ -57,6 +76,7 @@ if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY) install(FILES ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/ClangConfig.cmake + ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/ClangConfigVersion.cmake ${CMAKE_CURRENT_SOURCE_DIR}/AddClang.cmake DESTINATION ${CLANG_INSTALL_PACKAGE_DIR} COMPONENT clang-cmake-exports) diff --git a/gnu/llvm/clang/cmake/modules/ClangConfig.cmake.in b/gnu/llvm/clang/cmake/modules/ClangConfig.cmake.in index 2a254463d6f..5f67681649c 100644 --- a/gnu/llvm/clang/cmake/modules/ClangConfig.cmake.in +++ b/gnu/llvm/clang/cmake/modules/ClangConfig.cmake.in @@ -2,7 +2,8 @@ @CLANG_CONFIG_CODE@ -find_package(LLVM REQUIRED CONFIG +set(LLVM_VERSION @LLVM_VERSION_MAJOR@.@LLVM_VERSION_MINOR@.@LLVM_VERSION_PATCH@) +find_package(LLVM ${LLVM_VERSION} EXACT REQUIRED CONFIG HINTS "@CLANG_CONFIG_LLVM_CMAKE_DIR@") set(CLANG_EXPORTED_TARGETS "@CLANG_EXPORTS@") diff --git a/gnu/llvm/clang/cmake/modules/ClangConfigVersion.cmake.in b/gnu/llvm/clang/cmake/modules/ClangConfigVersion.cmake.in new file mode 100644 index 00000000000..e9ac4ed2da7 --- /dev/null +++ b/gnu/llvm/clang/cmake/modules/ClangConfigVersion.cmake.in @@ -0,0 +1,13 @@ +set(PACKAGE_VERSION "@PACKAGE_VERSION@") + +# LLVM is API-compatible only with matching major.minor versions +# and patch versions not less than that requested. +if("@LLVM_VERSION_MAJOR@.@LLVM_VERSION_MINOR@" VERSION_EQUAL + "${PACKAGE_FIND_VERSION_MAJOR}.${PACKAGE_FIND_VERSION_MINOR}" + AND NOT "@LLVM_VERSION_PATCH@" VERSION_LESS "${PACKAGE_FIND_VERSION_PATCH}") + set(PACKAGE_VERSION_COMPATIBLE 1) + if("@LLVM_VERSION_PATCH@" VERSION_EQUAL + "${PACKAGE_FIND_VERSION_PATCH}") + set(PACKAGE_VERSION_EXACT 1) + endif() +endif() diff --git a/gnu/llvm/clang/cmake/modules/ProtobufMutator.cmake b/gnu/llvm/clang/cmake/modules/ProtobufMutator.cmake index 15fe95ed6e8..071f11bc343 100644 --- a/gnu/llvm/clang/cmake/modules/ProtobufMutator.cmake +++ b/gnu/llvm/clang/cmake/modules/ProtobufMutator.cmake @@ -1,5 +1,9 @@ include(ExternalProject) -set(PBM_PREFIX protobuf_mutator) + +if (NOT PBM_PREFIX) + set (PBM_PREFIX protobuf_mutator) +endif() + set(PBM_PATH ${CMAKE_CURRENT_BINARY_DIR}/${PBM_PREFIX}/src/${PBM_PREFIX}) set(PBM_LIB_PATH ${PBM_PATH}-build/src/libprotobuf-mutator.a) set(PBM_FUZZ_LIB_PATH ${PBM_PATH}-build/src/libfuzzer/libprotobuf-mutator-libfuzzer.a) diff --git a/gnu/llvm/clang/docs/APINotes.rst b/gnu/llvm/clang/docs/APINotes.rst index 4ac4c01cdef..a6e200e8bff 100644 --- a/gnu/llvm/clang/docs/APINotes.rst +++ b/gnu/llvm/clang/docs/APINotes.rst @@ -22,11 +22,11 @@ the compiler. That's API notes. API notes use a YAML-based file format. YAML is a format best explained by -example, so here is a `small example`__ from the compiler test suite of API +example, so here is a `small example +`_ +from the compiler test suite of API notes for a hypothetical "SomeKit" framework. -__ test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit.apinotes - Usage ===== diff --git a/gnu/llvm/clang/docs/AddressSanitizer.rst b/gnu/llvm/clang/docs/AddressSanitizer.rst index 7befbc3173d..37f34cb0cc9 100644 --- a/gnu/llvm/clang/docs/AddressSanitizer.rst +++ b/gnu/llvm/clang/docs/AddressSanitizer.rst @@ -15,7 +15,8 @@ following types of bugs: * Out-of-bounds accesses to heap, stack and globals * Use-after-free * Use-after-return (clang flag ``-fsanitize-address-use-after-return=(never|runtime|always)`` default: ``runtime``) - * Enable ``runtime`` with: ``ASAN_OPTIONS=detect_stack_use_after_return=1`` + * Enable with: ``ASAN_OPTIONS=detect_stack_use_after_return=1`` (already enabled on Linux). + * Disable with: ``ASAN_OPTIONS=detect_stack_use_after_return=0``. * Use-after-scope (clang flag ``-fsanitize-address-use-after-scope``) * Double-free, invalid free * Memory leaks (experimental) @@ -143,8 +144,8 @@ Stack Use After Return (UAR) AddressSanitizer can optionally detect stack use after return problems. This is available by default, or explicitly (``-fsanitize-address-use-after-return=runtime``). -To enable this check at runtime, set the environment variable -``ASAN_OPTIONS=detect_stack_use_after_return=1``. +To disable this check at runtime, set the environment variable +``ASAN_OPTIONS=detect_stack_use_after_return=0``. Enabling this check (``-fsanitize-address-use-after-return=always``) will reduce code size. The code size may be reduced further by completely @@ -152,8 +153,8 @@ eliminating this check (``-fsanitize-address-use-after-return=never``). To summarize: ``-fsanitize-address-use-after-return=`` * ``never``: Completely disables detection of UAR errors (reduces code size). - * ``runtime``: Adds the code for detection, but must be enabled via the - runtime environment (``ASAN_OPTIONS=detect_stack_use_after_return=1``). + * ``runtime``: Adds the code for detection, but it can be disable via the + runtime environment (``ASAN_OPTIONS=detect_stack_use_after_return=0``). * ``always``: Enables detection of UAR errors in all cases. (reduces code size, but not as much as ``never``). @@ -229,6 +230,12 @@ compilers, so we suggest to use it together with The same attribute used on a global variable prevents AddressSanitizer from adding redzones around it and detecting out of bounds accesses. + +AddressSanitizer also supports +``__attribute__((disable_sanitizer_instrumentation))``. This attribute +works similar to ``__attribute__((no_sanitize("address")))``, but it also +prevents instrumentation performed by other sanitizers. + Suppressing Errors in Recompiled Code (Ignorelist) -------------------------------------------------- @@ -282,11 +289,11 @@ Code generation control Instrumentation code outlining ------------------------------ -By default AddressSanitizer inlines the instumentation code to improve the +By default AddressSanitizer inlines the instrumentation code to improve the run-time performance, which leads to increased binary size. Using the (clang flag ``-fsanitize-address-outline-instrumentation` default: ``false``) -flag forces all code instumentation to be outlined, which reduces the size -of the generated code, but also reduces the run-time performace. +flag forces all code instrumentation to be outlined, which reduces the size +of the generated code, but also reduces the run-time performance. Limitations =========== diff --git a/gnu/llvm/clang/docs/AutomaticReferenceCounting.rst b/gnu/llvm/clang/docs/AutomaticReferenceCounting.rst index 9b0b6b86eb1..5e40fa837b1 100644 --- a/gnu/llvm/clang/docs/AutomaticReferenceCounting.rst +++ b/gnu/llvm/clang/docs/AutomaticReferenceCounting.rst @@ -2380,8 +2380,10 @@ the current pool, and returns an opaque "handle" to it. If ``value`` is null, this call has no effect. Otherwise, it makes a best effort to hand off ownership of a retain count on the object to a call to :ref:`objc_retainAutoreleasedReturnValue -` for the same object in an -enclosing call frame. If this is not possible, the object is autoreleased as +` (or +:ref:`objc_unsafeClaimAutoreleasedReturnValue +`) for the same object in +an enclosing call frame. If this is not possible, the object is autoreleased as above. Always returns ``value``. @@ -2579,8 +2581,8 @@ Always returns ``value``. If ``value`` is null, this call has no effect. Otherwise, it attempts to accept a hand off of a retain count from a call to :ref:`objc_autoreleaseReturnValue ` on -``value`` in a recently-called function or something it calls. If that fails, -it performs a retain operation exactly like :ref:`objc_retain +``value`` in a recently-called function or something it tail-calls. If that +fails, it performs a retain operation exactly like :ref:`objc_retain `. Always returns ``value``. @@ -2639,3 +2641,21 @@ registration updated to point to ``value``. Returns the value of ``object`` after the call. +.. _arc.runtime.objc_unsafeClaimAutoreleasedReturnValue: + +``id objc_unsafeClaimAutoreleasedReturnValue(id value);`` +--------------------------------------------------------- + +*Precondition:* ``value`` is null or a pointer to a valid object. + +If ``value`` is null, this call has no effect. Otherwise, it attempts to +accept a hand off of a retain count from a call to +:ref:`objc_autoreleaseReturnValue ` on +``value`` in a recently-called function or something it tail-calls (in a manner +similar to :ref:`objc_retainAutoreleasedReturnValue +`). If that succeeds, +it performs a release operation exactly like :ref:`objc_release +`. If the handoff fails, this call has no effect. + +Always returns ``value``. + diff --git a/gnu/llvm/clang/docs/Block-ABI-Apple.rst b/gnu/llvm/clang/docs/Block-ABI-Apple.rst index e21a8b68b5c..68f7a3819ca 100644 --- a/gnu/llvm/clang/docs/Block-ABI-Apple.rst +++ b/gnu/llvm/clang/docs/Block-ABI-Apple.rst @@ -43,10 +43,10 @@ the following form: struct Block_literal_1 { void *isa; // initialized to &_NSConcreteStackBlock or &_NSConcreteGlobalBlock int flags; - int reserved; + int reserved; R (*invoke)(struct Block_literal_1 *, P...); struct Block_descriptor_1 { - unsigned long int reserved; // NULL + unsigned long int reserved; // NULL unsigned long int size; // sizeof(struct Block_literal_1) // optional helper functions void (*copy_helper)(void *dst, void *src); // IFF (1<<25) @@ -74,7 +74,7 @@ The following flags bits are in use thusly for a possible ABI.2010.3.16: BLOCK_HAS_CTOR = (1 << 26), // helpers have C++ code BLOCK_IS_GLOBAL = (1 << 28), BLOCK_HAS_STRET = (1 << 29), // IFF BLOCK_HAS_SIGNATURE - BLOCK_HAS_SIGNATURE = (1 << 30), + BLOCK_HAS_SIGNATURE = (1 << 30), }; In 10.6.ABI the (1<<29) was usually set and was always ignored by the runtime - @@ -104,25 +104,25 @@ When a ``Block`` literal expression is evaluated the stack based structure is initialized as follows: 1. A ``static`` descriptor structure is declared and initialized as follows: - + a. The ``invoke`` function pointer is set to a function that takes the ``Block`` structure as its first argument and the rest of the arguments (if any) to the ``Block`` and executes the ``Block`` compound statement. - + b. The ``size`` field is set to the size of the following ``Block`` literal structure. - + c. The ``copy_helper`` and ``dispose_helper`` function pointers are set to respective helper functions if they are required by the ``Block`` literal. 2. A stack (or global) ``Block`` literal data structure is created and initialized as follows: - + a. The ``isa`` field is set to the address of the external ``_NSConcreteStackBlock``, which is a block of uninitialized memory supplied in ``libSystem``, or ``_NSConcreteGlobalBlock`` if this is a static or file level ``Block`` literal. - + b. The ``flags`` field is set to zero unless there are variables imported into the ``Block`` that need helper functions for program level ``Block_copy()`` and ``Block_release()`` operations, in which case the @@ -141,15 +141,15 @@ would cause the following to be created on a 32-bit system: struct __block_literal_1 { void *isa; int flags; - int reserved; + int reserved; void (*invoke)(struct __block_literal_1 *); struct __block_descriptor_1 *descriptor; }; - + void __block_invoke_1(struct __block_literal_1 *_block) { printf("hello world\n"); } - + static struct __block_descriptor_1 { unsigned long int reserved; unsigned long int Block_size; @@ -214,20 +214,20 @@ The simplest example is that of importing a variable of type ``int``: which would be compiled to: .. code-block:: c - + struct __block_literal_2 { void *isa; int flags; - int reserved; + int reserved; void (*invoke)(struct __block_literal_2 *); struct __block_descriptor_2 *descriptor; const int x; }; - + void __block_invoke_2(struct __block_literal_2 *_block) { printf("x is %d\n", _block->x); } - + static struct __block_descriptor_2 { unsigned long int reserved; unsigned long int Block_size; @@ -266,33 +266,33 @@ A quick example: void (^existingBlock)(void) = ...; void (^vv)(void) = ^{ existingBlock(); } vv(); - + struct __block_literal_3 { ...; // existing block }; - + struct __block_literal_4 { void *isa; int flags; - int reserved; + int reserved; void (*invoke)(struct __block_literal_4 *); struct __block_literal_3 *const existingBlock; }; - + void __block_invoke_4(struct __block_literal_2 *_block) { __block->existingBlock->invoke(__block->existingBlock); } - + void __block_copy_4(struct __block_literal_4 *dst, struct __block_literal_4 *src) { //_Block_copy_assign(&dst->existingBlock, src->existingBlock, 0); _Block_object_assign(&dst->existingBlock, src->existingBlock, BLOCK_FIELD_IS_BLOCK); } - + void __block_dispose_4(struct __block_literal_4 *src) { // was _Block_destroy _Block_object_dispose(src->existingBlock, BLOCK_FIELD_IS_BLOCK); } - + static struct __block_descriptor_4 { unsigned long int reserved; unsigned long int Block_size; @@ -344,7 +344,7 @@ would have the following helper functions generated: void __block_copy_foo(struct __block_literal_5 *dst, struct __block_literal_5 *src) { _Block_object_assign(&dst->objectPointer, src-> objectPointer, BLOCK_FIELD_IS_OBJECT); } - + void __block_dispose_foo(struct __block_literal_5 *src) { _Block_object_dispose(src->objectPointer, BLOCK_FIELD_IS_OBJECT); } @@ -392,17 +392,17 @@ The structure is initialized such that: a. The ``forwarding`` pointer is set to the beginning of its enclosing structure. - + b. The ``size`` field is initialized to the total size of the enclosing - structure. - + structure. + c. The ``flags`` field is set to either 0 if no helper functions are needed - or (1<<25) if they are. - - d. The helper functions are initialized (if present). - - e. The variable itself is set to its initial value. - + or (1<<25) if they are. + + d. The helper functions are initialized (if present). + + e. The variable itself is set to its initial value. + f. The ``isa`` field is set to ``NULL``. Access to ``__block`` variables from within its lexical scope @@ -428,7 +428,7 @@ would be rewritten to be: int size; int captured_i; } i = { NULL, &i, 0, sizeof(struct _block_byref_i), 10 }; - + i.forwarding->captured_i = 11; In the case of a ``Block`` reference variable being marked ``__block`` the @@ -454,12 +454,12 @@ would translate into: void (*byref_dispose)(struct _block_byref_voidBlock *); void (^captured_voidBlock)(void); }; - + void _block_byref_keep_helper(struct _block_byref_voidBlock *dst, struct _block_byref_voidBlock *src) { //_Block_copy_assign(&dst->captured_voidBlock, src->captured_voidBlock, 0); _Block_object_assign(&dst->captured_voidBlock, src->captured_voidBlock, BLOCK_FIELD_IS_BLOCK | BLOCK_BYREF_CALLER); } - + void _block_byref_dispose_helper(struct _block_byref_voidBlock *param) { //_Block_destroy(param->captured_voidBlock, 0); _Block_object_dispose(param->captured_voidBlock, BLOCK_FIELD_IS_BLOCK | BLOCK_BYREF_CALLER)} @@ -471,7 +471,7 @@ and: struct _block_byref_voidBlock voidBlock = {( .forwarding=&voidBlock, .flags=(1<<25), .size=sizeof(struct _block_byref_voidBlock *), .byref_keep=_block_byref_keep_helper, .byref_dispose=_block_byref_dispose_helper, .captured_voidBlock=blockA )}; - + voidBlock.forwarding->captured_voidBlock = blockB; Importing ``__block`` variables into ``Blocks`` @@ -503,31 +503,31 @@ would translate to: void (*byref_dispose)(struct _block_byref_i *); int captured_i; }; - - + + struct __block_literal_5 { void *isa; int flags; - int reserved; + int reserved; void (*invoke)(struct __block_literal_5 *); struct __block_descriptor_5 *descriptor; struct _block_byref_i *i_holder; }; - + void __block_invoke_5(struct __block_literal_5 *_block) { _block->forwarding->captured_i = 10; } - + void __block_copy_5(struct __block_literal_5 *dst, struct __block_literal_5 *src) { //_Block_byref_assign_copy(&dst->captured_i, src->captured_i); _Block_object_assign(&dst->captured_i, src->captured_i, BLOCK_FIELD_IS_BYREF | BLOCK_BYREF_CALLER); } - + void __block_dispose_5(struct __block_literal_5 *src) { //_Block_byref_release(src->captured_i); _Block_object_dispose(src->captured_i, BLOCK_FIELD_IS_BYREF | BLOCK_BYREF_CALLER); } - + static struct __block_descriptor_5 { unsigned long int reserved; unsigned long int Block_size; @@ -660,12 +660,12 @@ would translate to: void (*byref_dispose)(struct _block_byref_i *); id captured_obj; }; - + void _block_byref_obj_keep(struct _block_byref_voidBlock *dst, struct _block_byref_voidBlock *src) { //_Block_copy_assign(&dst->captured_obj, src->captured_obj, 0); _Block_object_assign(&dst->captured_obj, src->captured_obj, BLOCK_FIELD_IS_OBJECT | BLOCK_FIELD_IS_WEAK | BLOCK_BYREF_CALLER); } - + void _block_byref_obj_dispose(struct _block_byref_voidBlock *param) { //_Block_destroy(param->captured_obj, 0); _Block_object_dispose(param->captured_obj, BLOCK_FIELD_IS_OBJECT | BLOCK_FIELD_IS_WEAK | BLOCK_BYREF_CALLER); @@ -678,26 +678,26 @@ for the block ``byref`` part and: struct __block_literal_5 { void *isa; int flags; - int reserved; + int reserved; void (*invoke)(struct __block_literal_5 *); struct __block_descriptor_5 *descriptor; struct _block_byref_obj *byref_obj; }; - + void __block_invoke_5(struct __block_literal_5 *_block) { [objc_read_weak(&_block->byref_obj->forwarding->captured_obj) somemessage]; } - + void __block_copy_5(struct __block_literal_5 *dst, struct __block_literal_5 *src) { //_Block_byref_assign_copy(&dst->byref_obj, src->byref_obj); _Block_object_assign(&dst->byref_obj, src->byref_obj, BLOCK_FIELD_IS_BYREF | BLOCK_FIELD_IS_WEAK); } - + void __block_dispose_5(struct __block_literal_5 *src) { //_Block_byref_release(src->byref_obj); _Block_object_dispose(src->byref_obj, BLOCK_FIELD_IS_BYREF | BLOCK_FIELD_IS_WEAK); } - + static struct __block_descriptor_5 { unsigned long int reserved; unsigned long int Block_size; @@ -712,7 +712,7 @@ and within the compound statement: truct _block_byref_obj obj = {( .forwarding=&obj, .flags=(1<<25), .size=sizeof(struct _block_byref_obj), .byref_keep=_block_byref_obj_keep, .byref_dispose=_block_byref_obj_dispose, .captured_obj = )}; - + truct __block_literal_5 _block_literal = { &_NSConcreteStackBlock, (1<<25)|(1<<29), , @@ -720,8 +720,8 @@ and within the compound statement: &__block_descriptor_5, &obj, // a reference to the on-stack structure containing "captured_obj" }; - - + + functioncall(_block_literal->invoke(&_block_literal)); C++ Support @@ -755,24 +755,24 @@ The compiler would synthesize: struct __block_literal_10 { void *isa; int flags; - int reserved; + int reserved; void (*invoke)(struct __block_literal_10 *); struct __block_descriptor_10 *descriptor; const FOO foo; }; - + void __block_invoke_10(struct __block_literal_10 *_block) { printf("%d\n", _block->foo.value()); } - - void __block_literal_10(struct __block_literal_10 *dst, struct __block_literal_10 *src) { + + void __block_copy_10(struct __block_literal_10 *dst, struct __block_literal_10 *src) { FOO_ctor(&dst->foo, &src->foo); } - + void __block_dispose_10(struct __block_literal_10 *src) { FOO_dtor(&src->foo); } - + static struct __block_descriptor_10 { unsigned long int reserved; unsigned long int Block_size; @@ -837,7 +837,7 @@ copy/dispose helpers: void _block_byref_obj_keep(struct _block_byref_blockStorageFoo *dst, struct _block_byref_blockStorageFoo *src) { FOO_ctor(&dst->blockStorageFoo, &src->blockStorageFoo); } - + void _block_byref_obj_dispose(struct _block_byref_blockStorageFoo *src) { FOO_dtor(&src->blockStorageFoo); } @@ -881,9 +881,9 @@ in the dispose helper where ```` is: BLOCK_FIELD_IS_OBJECT = 3, // id, NSObject, __attribute__((NSObject)), block, ... BLOCK_FIELD_IS_BLOCK = 7, // a block variable BLOCK_FIELD_IS_BYREF = 8, // the on stack structure holding the __block variable - + BLOCK_FIELD_IS_WEAK = 16, // declared __weak - + BLOCK_BYREF_CALLER = 128, // called from byref copy/dispose helpers }; @@ -903,7 +903,7 @@ this causes the addition of ``BLOCK_FIELD_IS_WEAK`` orred onto the The prototypes, and summary, of the helper functions are: .. code-block:: c - + /* Certain field types require runtime assistance when being copied to the heap. The following function is used to copy fields of types: blocks, pointers to byref structures, and objects (including @@ -912,7 +912,7 @@ The prototypes, and summary, of the helper functions are: helper will one see BLOCK_FIELD_IS_BYREF. */ void _Block_object_assign(void *destAddr, const void *object, const int flags); - + /* Similarly a compiler generated dispose helper needs to call back for each field of the byref data structure. (Currently the implementation only packs one field into the byref structure but in principle there could be diff --git a/gnu/llvm/clang/docs/CMakeLists.txt b/gnu/llvm/clang/docs/CMakeLists.txt index 2d3ac5dbdd1..532907385df 100644 --- a/gnu/llvm/clang/docs/CMakeLists.txt +++ b/gnu/llvm/clang/docs/CMakeLists.txt @@ -114,8 +114,12 @@ if (LLVM_ENABLE_SPHINX) # directory before we run sphinx. add_custom_target(copy-clang-rst-docs COMMAND "${CMAKE_COMMAND}" -E copy_directory - "${CMAKE_CURRENT_SOURCE_DIR}" - "${CMAKE_CURRENT_BINARY_DIR}") + "${CMAKE_CURRENT_SOURCE_DIR}" "${CMAKE_CURRENT_BINARY_DIR}" + + COMMAND "${CMAKE_COMMAND}" -E copy_if_different + "${CMAKE_CURRENT_SOURCE_DIR}/../CodeOwners.rst" + "${CMAKE_CURRENT_BINARY_DIR}" + ) add_dependencies(docs-clang-html copy-clang-rst-docs) add_custom_command(TARGET docs-clang-html POST_BUILD diff --git a/gnu/llvm/clang/docs/ClangFormat.rst b/gnu/llvm/clang/docs/ClangFormat.rst index 4a1422e85b0..98350a04ccd 100644 --- a/gnu/llvm/clang/docs/ClangFormat.rst +++ b/gnu/llvm/clang/docs/ClangFormat.rst @@ -13,9 +13,11 @@ Standalone Tool :program:`clang-format` is located in `clang/tools/clang-format` and can be used to format C/C++/Java/JavaScript/JSON/Objective-C/Protobuf/C# code. +.. START_FORMAT_HELP + .. code-block:: console - $ clang-format -help + $ clang-format --help OVERVIEW: A tool to format C/C++/Java/JavaScript/JSON/Objective-C/Protobuf/C# code. If no arguments are specified, it formats the code from standard input @@ -24,75 +26,98 @@ to format C/C++/Java/JavaScript/JSON/Objective-C/Protobuf/C# code. together with s, the files are edited in-place. Otherwise, the result is written to the standard output. - USAGE: clang-format [options] [ ...] + USAGE: clang-format [options] [@] [ ...] OPTIONS: Clang-format options: - --Werror - If set, changes formatting warnings to errors - --Wno-error= - If set don't error out on the specified warning type. - =unknown - If set, unknown format options are only warned about. - This can be used to enable formatting, even if the - configuration contains unknown (newer) options. - Use with caution, as this might lead to dramatically - differing format depending on an option being - supported or not. - --assume-filename= - Override filename used to determine the language. - When reading from stdin, clang-format assumes this - filename to determine the language. - --cursor= - The position of the cursor when invoking - clang-format from an editor integration - --dry-run - If set, do not actually make the formatting changes - --dump-config - Dump configuration options to stdout and exit. - Can be used with -style option. - --fallback-style= - The name of the predefined style used as a - fallback in case clang-format is invoked with - -style=file, but can not find the .clang-format - file to use. - Use -fallback-style=none to skip formatting. - --ferror-limit= - Set the maximum number of clang-format errors to - emit before stopping (0 = no limit). Used only - with --dry-run or -n - -i - Inplace edit s, if specified. - --length= - Format a range of this length (in bytes). - Multiple ranges can be formatted by specifying - several -offset and -length pairs. - When only a single -offset is specified without - -length, clang-format will format up to the end - of the file. - Can only be used with one input file. - --lines= - : - format a range of - lines (both 1-based). - Multiple ranges can be formatted by specifying - several -lines arguments. - Can't be used with -offset and -length. - Can only be used with one input file. - -n - Alias for --dry-run - --offset= - Format a range starting at this byte offset. - Multiple ranges can be formatted by specifying - several -offset and -length pairs. - Can only be used with one input file. - --output-replacements-xml - Output replacements as XML. - --sort-includes - If set, overrides the include sorting behavior - determined by the SortIncludes style flag - --style= - Coding style, currently supports: - LLVM, Google, Chromium, Mozilla, WebKit. - Use -style=file to load style configuration from - .clang-format file located in one of the parent - directories of the source file (or current - directory for stdin). - Use -style="{key: value, ...}" to set specific - parameters, e.g.: - -style="{BasedOnStyle: llvm, IndentWidth: 8}" - --verbose - If set, shows the list of processed files + --Werror - If set, changes formatting warnings to errors + --Wno-error= - If set don't error out on the specified warning type. + =unknown - If set, unknown format options are only warned about. + This can be used to enable formatting, even if the + configuration contains unknown (newer) options. + Use with caution, as this might lead to dramatically + differing format depending on an option being + supported or not. + --assume-filename= - Set filename used to determine the language and to find + .clang-format file. + Only used when reading from stdin. + If this is not passed, the .clang-format file is searched + relative to the current working directory when reading stdin. + Unrecognized filenames are treated as C++. + supported: + CSharp: .cs + Java: .java + JavaScript: .mjs .js .ts + Json: .json + Objective-C: .m .mm + Proto: .proto .protodevel + TableGen: .td + TextProto: .textpb .pb.txt .textproto .asciipb + Verilog: .sv .svh .v .vh + --cursor= - The position of the cursor when invoking + clang-format from an editor integration + --dry-run - If set, do not actually make the formatting changes + --dump-config - Dump configuration options to stdout and exit. + Can be used with -style option. + --fallback-style= - The name of the predefined style used as a + fallback in case clang-format is invoked with + -style=file, but can not find the .clang-format + file to use. Defaults to 'LLVM'. + Use -fallback-style=none to skip formatting. + --ferror-limit= - Set the maximum number of clang-format errors to emit + before stopping (0 = no limit). + Used only with --dry-run or -n + --files= - A file containing a list of files to process, one + per line. + -i - Inplace edit s, if specified. + --length= - Format a range of this length (in bytes). + Multiple ranges can be formatted by specifying + several -offset and -length pairs. + When only a single -offset is specified without + -length, clang-format will format up to the end + of the file. + Can only be used with one input file. + --lines= - : - format a range of + lines (both 1-based). + Multiple ranges can be formatted by specifying + several -lines arguments. + Can't be used with -offset and -length. + Can only be used with one input file. + -n - Alias for --dry-run + --offset= - Format a range starting at this byte offset. + Multiple ranges can be formatted by specifying + several -offset and -length pairs. + Can only be used with one input file. + --output-replacements-xml - Output replacements as XML. + --qualifier-alignment= - If set, overrides the qualifier alignment style + determined by the QualifierAlignment style flag + --sort-includes - If set, overrides the include sorting behavior + determined by the SortIncludes style flag + --style= - Set coding style. can be: + 1. A preset: LLVM, GNU, Google, Chromium, Microsoft, + Mozilla, WebKit. + 2. 'file' to load style configuration from a + .clang-format file in one of the parent directories + of the source file (for stdin, see --assume-filename). + If no .clang-format file is found, falls back to + --fallback-style. + --style=file is the default. + 3. 'file:' to explicitly specify + the configuration file. + 4. "{key: value, ...}" to set specific parameters, e.g.: + --style="{BasedOnStyle: llvm, IndentWidth: 8}" + --verbose - If set, shows the list of processed files Generic Options: - --help - Display available options (--help-hidden for more) - --help-list - Display list of available options (--help-list-hidden for more) - --version - Display the version of this program + --help - Display available options (--help-hidden for more) + --help-list - Display list of available options (--help-list-hidden for more) + --version - Display the version of this program + +.. END_FORMAT_HELP When the desired code formatting style is different from the available options, the style can be customized using the ``-style="{key: value, ...}"`` option or @@ -143,7 +168,7 @@ your `.vimrc`: function! Formatonsave() let l:formatdiff = 1 - pyf ~/llvm/tools/clang/tools/clang-format/clang-format.py + pyf /clang-format.py endfunction autocmd BufWritePre *.h,*.cc,*.cpp call Formatonsave() @@ -205,46 +230,103 @@ Visual Studio Code Integration Get the latest Visual Studio Code extension from the `Visual Studio Marketplace `_. The default key-binding is Alt-Shift-F. +Git integration +=============== -Script for patch reformatting -============================= - -The python script `clang/tools/clang-format/clang-format-diff.py` parses the -output of a unified diff and reformats all contained lines with -:program:`clang-format`. +The script `clang/tools/clang-format/git-clang-format` can be used to +format just the lines touched in git commits: .. code-block:: console - usage: clang-format-diff.py [-h] [-i] [-p NUM] [-regex PATTERN] [-style STYLE] + % git clang-format -h + usage: git clang-format [OPTIONS] [] [|--staged] [--] [...] + + If zero or one commits are given, run clang-format on all lines that differ + between the working directory and , which defaults to HEAD. Changes are + only applied to the working directory, or in the stage/index. + + Examples: + To format staged changes, i.e everything that's been `git add`ed: + git clang-format + + To also format everything touched in the most recent commit: + git clang-format HEAD~1 + + If you're on a branch off main, to format everything touched on your branch: + git clang-format main - Reformat changed lines in diff. Without -i option just output the diff that - would be introduced. + If two commits are given (requires --diff), run clang-format on all lines in the + second that differ from the first . + + The following git-config settings set the default of the corresponding option: + clangFormat.binary + clangFormat.commit + clangFormat.extensions + clangFormat.style + + positional arguments: + revision from which to compute the diff + ... if specified, only consider differences in these files optional arguments: - -h, --help show this help message and exit - -i apply edits to files instead of displaying a diff - -p NUM strip the smallest prefix containing P slashes - -regex PATTERN custom pattern selecting file paths to reformat - -style STYLE formatting style to apply (LLVM, Google, Chromium, Mozilla, - WebKit) + -h, --help show this help message and exit + --binary BINARY path to clang-format + --commit COMMIT default commit to use if none is specified + --diff print a diff instead of applying the changes + --diffstat print a diffstat instead of applying the changes + --extensions EXTENSIONS + comma-separated list of file extensions to format, excluding the period and case-insensitive + -f, --force allow changes to unstaged files + -p, --patch select hunks interactively + -q, --quiet print less information + --staged, --cached format lines in the stage instead of the working dir + --style STYLE passed to clang-format + -v, --verbose print extra information -So to reformat all the lines in the latest :program:`git` commit, just do: + +Script for patch reformatting +============================= + +The python script `clang/tools/clang-format/clang-format-diff.py` parses the +output of a unified diff and reformats all contained lines with +:program:`clang-format`. .. code-block:: console - git diff -U0 --no-color HEAD^ | clang-format-diff.py -i -p1 + usage: clang-format-diff.py [-h] [-i] [-p NUM] [-regex PATTERN] [-iregex PATTERN] [-sort-includes] [-v] [-style STYLE] + [-fallback-style FALLBACK_STYLE] [-binary BINARY] -With Mercurial/:program:`hg`: + This script reads input from a unified diff and reformats all the changed + lines. This is useful to reformat all the lines touched by a specific patch. + Example usage for git/svn users: -.. code-block:: console + git diff -U0 --no-color --relative HEAD^ | clang-format-diff.py -p1 -i + svn diff --diff-cmd=diff -x-U0 | clang-format-diff.py -i - hg diff -U0 --color=never | clang-format-diff.py -i -p1 + It should be noted that the filename contained in the diff is used unmodified + to determine the source file to update. Users calling this script directly + should be careful to ensure that the path in the diff is correct relative to the + current working directory. -In an SVN client, you can do: + optional arguments: + -h, --help show this help message and exit + -i apply edits to files instead of displaying a diff + -p NUM strip the smallest prefix containing P slashes + -regex PATTERN custom pattern selecting file paths to reformat (case sensitive, overrides -iregex) + -iregex PATTERN custom pattern selecting file paths to reformat (case insensitive, overridden by -regex) + -sort-includes let clang-format sort include blocks + -v, --verbose be more verbose, ineffective without -i + -style STYLE formatting style to apply (LLVM, GNU, Google, Chromium, Microsoft, Mozilla, WebKit) + -fallback-style FALLBACK_STYLE + The name of the predefined style used as a fallback in case clang-format is invoked with-style=file, but can not + find the .clang-formatfile to use. + -binary BINARY location of binary to use for clang-format + +To reformat all the lines in the latest Mercurial/:program:`hg` commit, do: .. code-block:: console - svn diff --diff-cmd=diff -x -U0 | clang-format-diff.py -i + hg diff -U0 --color=never | clang-format-diff.py -i -p1 The option `-U0` will create a diff without context lines (the script would format those as well). diff --git a/gnu/llvm/clang/docs/ClangFormatStyleOptions.rst b/gnu/llvm/clang/docs/ClangFormatStyleOptions.rst index 96d89db7a5c..3316b5d3cda 100644 --- a/gnu/llvm/clang/docs/ClangFormatStyleOptions.rst +++ b/gnu/llvm/clang/docs/ClangFormatStyleOptions.rst @@ -1,3 +1,17 @@ +.. + !!!!NOTE!!!! + This file is automatically generated, in part. Do not edit the style options + in this file directly. Instead, modify them in include/clang/Format/Format.h + and run the docs/tools/dump_format_style.py script to update this file. + +.. raw:: html + + + +.. role:: versionbadge + ========================== Clang-Format Style Options ========================== @@ -24,6 +38,10 @@ try to find the ``.clang-format`` file located in the closest parent directory of the input file. When the standard input is used, the search is started from the current directory. +When using ``-style=file:``, :program:`clang-format` for +each input file will use the format file located at ``. +The path may be absolute or relative to the working directory. + The ``.clang-format`` file uses YAML format: .. code-block:: yaml @@ -124,8 +142,9 @@ each option. For enumeration types possible values are specified both as a C++ enumeration member (with a prefix, e.g. ``LS_Auto``), and as a value usable in the configuration (without a prefix: ``Auto``). +.. _BasedOnStyle: -**BasedOnStyle** (``string``) +**BasedOnStyle** (``String``) :ref:`¶ ` The style used for all options not specifically set in the configuration. This option is supported only in the :program:`clang-format` configuration @@ -141,16 +160,16 @@ the configuration (without a prefix: ``Auto``). `_ * ``Chromium`` A style complying with `Chromium's style guide - `_ + `_ * ``Mozilla`` A style complying with `Mozilla's style guide - `_ + `_ * ``WebKit`` A style complying with `WebKit's style guide `_ * ``Microsoft`` A style complying with `Microsoft's style guide - `_ + `_ * ``GNU`` A style complying with the `GNU coding standards `_ @@ -166,10 +185,14 @@ the configuration (without a prefix: ``Auto``). .. START_FORMAT_STYLE_OPTIONS -**AccessModifierOffset** (``int``) +.. _AccessModifierOffset: + +**AccessModifierOffset** (``Integer``) :versionbadge:`clang-format 3.3` :ref:`¶ ` The extra indent or outdent of access modifiers, e.g. ``public:``. -**AlignAfterOpenBracket** (``BracketAlignmentStyle``) +.. _AlignAfterOpenBracket: + +**AlignAfterOpenBracket** (``BracketAlignmentStyle``) :versionbadge:`clang-format 3.8` :ref:`¶ ` If ``true``, horizontally aligns arguments after an open bracket. This applies to round brackets (parentheses), angle brackets and square @@ -202,12 +225,33 @@ the configuration (without a prefix: ``Auto``). someLongFunction( argument1, argument2); + * ``BAS_BlockIndent`` (in configuration: ``BlockIndent``) + Always break after an open bracket, if the parameters don't fit + on a single line. Closing brackets will be placed on a new line. + E.g.: + + .. code-block:: c++ + + someLongFunction( + argument1, argument2 + ) + + + .. warning:: + + Note: This currently only applies to parentheses. + -**AlignArrayOfStructures** (``ArrayInitializerAlignmentStyle``) +.. _AlignArrayOfStructures: + +**AlignArrayOfStructures** (``ArrayInitializerAlignmentStyle``) :versionbadge:`clang-format 13` :ref:`¶ ` if not ``None``, when using initialization for an array of structs aligns the fields into columns. + NOTE: As of clang-format 15 this option only applied to arrays with equal + number of columns per row. + Possible values: * ``AIAS_Left`` (in configuration: ``Left``) @@ -239,7 +283,9 @@ the configuration (without a prefix: ``Auto``). -**AlignConsecutiveAssignments** (``AlignConsecutiveStyle``) +.. _AlignConsecutiveAssignments: + +**AlignConsecutiveAssignments** (``AlignConsecutiveStyle``) :versionbadge:`clang-format 3.8` :ref:`¶ ` Style of aligning consecutive assignments. ``Consecutive`` will result in formattings like: @@ -250,70 +296,121 @@ the configuration (without a prefix: ``Auto``). int somelongname = 2; double c = 3; - Possible values: + Nested configuration flags: + + Alignment options. + + They can also be read as a whole for compatibility. The choices are: + - None + - Consecutive + - AcrossEmptyLines + - AcrossComments + - AcrossEmptyLinesAndComments + + For example, to align across empty lines and not across comments, either + of these work. + + .. code-block:: c++ + + AlignConsecutiveMacros: AcrossEmptyLines + + AlignConsecutiveMacros: + Enabled: true + AcrossEmptyLines: true + AcrossComments: false + + * ``bool Enabled`` Whether aligning is enabled. + + .. code-block:: c++ + + #define SHORT_NAME 42 + #define LONGER_NAME 0x007f + #define EVEN_LONGER_NAME (2) + #define foo(x) (x * x) + #define bar(y, z) (y + z) - * ``ACS_None`` (in configuration: ``None``) - Do not align assignments on consecutive lines. + int a = 1; + int somelongname = 2; + double c = 3; - * ``ACS_Consecutive`` (in configuration: ``Consecutive``) - Align assignments on consecutive lines. This will result in - formattings like: + int aaaa : 1; + int b : 12; + int ccc : 8; - .. code-block:: c++ + int aaaa = 12; + float b = 23; + std::string ccc; - int a = 1; - int somelongname = 2; - double c = 3; + * ``bool AcrossEmptyLines`` Whether to align across empty lines. - int d = 3; - /* A comment. */ - double e = 4; + .. code-block:: c++ + + true: + int a = 1; + int somelongname = 2; + double c = 3; + + int d = 3; + + false: + int a = 1; + int somelongname = 2; + double c = 3; + + int d = 3; + + * ``bool AcrossComments`` Whether to align across comments. - * ``ACS_AcrossEmptyLines`` (in configuration: ``AcrossEmptyLines``) - Same as ACS_Consecutive, but also spans over empty lines, e.g. + .. code-block:: c++ + + true: + int d = 3; + /* A comment. */ + double e = 4; + + false: + int d = 3; + /* A comment. */ + double e = 4; - .. code-block:: c++ + * ``bool AlignCompound`` Only for ``AlignConsecutiveAssignments``. Whether compound assignments + like ``+=`` are aligned along with ``=``. - int a = 1; - int somelongname = 2; - double c = 3; + .. code-block:: c++ - int d = 3; - /* A comment. */ - double e = 4; + true: + a &= 2; + bbb = 2; - * ``ACS_AcrossComments`` (in configuration: ``AcrossComments``) - Same as ACS_Consecutive, but also spans over lines only containing - comments, e.g. + false: + a &= 2; + bbb = 2; - .. code-block:: c++ + * ``bool PadOperators`` Only for ``AlignConsecutiveAssignments``. Whether short assignment + operators are left-padded to the same length as long ones in order to + put all assignment operators to the right of the left hand side. - int a = 1; - int somelongname = 2; - double c = 3; + .. code-block:: c++ - int d = 3; - /* A comment. */ - double e = 4; + true: + a >>= 2; + bbb = 2; - * ``ACS_AcrossEmptyLinesAndComments`` - (in configuration: ``AcrossEmptyLinesAndComments``) + a = 2; + bbb >>= 2; - Same as ACS_Consecutive, but also spans over lines only containing - comments and empty lines, e.g. + false: + a >>= 2; + bbb = 2; - .. code-block:: c++ + a = 2; + bbb >>= 2; - int a = 1; - int somelongname = 2; - double c = 3; - int d = 3; - /* A comment. */ - double e = 4; +.. _AlignConsecutiveBitFields: -**AlignConsecutiveBitFields** (``AlignConsecutiveStyle``) - Style of aligning consecutive bit field. +**AlignConsecutiveBitFields** (``AlignConsecutiveStyle``) :versionbadge:`clang-format 11` :ref:`¶ ` + Style of aligning consecutive bit fields. ``Consecutive`` will align the bitfield separators of consecutive lines. This will result in formattings like: @@ -324,69 +421,120 @@ the configuration (without a prefix: ``Auto``). int b : 12; int ccc : 8; - Possible values: + Nested configuration flags: + + Alignment options. + + They can also be read as a whole for compatibility. The choices are: + - None + - Consecutive + - AcrossEmptyLines + - AcrossComments + - AcrossEmptyLinesAndComments + + For example, to align across empty lines and not across comments, either + of these work. + + .. code-block:: c++ + + AlignConsecutiveMacros: AcrossEmptyLines + + AlignConsecutiveMacros: + Enabled: true + AcrossEmptyLines: true + AcrossComments: false + + * ``bool Enabled`` Whether aligning is enabled. + + .. code-block:: c++ + + #define SHORT_NAME 42 + #define LONGER_NAME 0x007f + #define EVEN_LONGER_NAME (2) + #define foo(x) (x * x) + #define bar(y, z) (y + z) - * ``ACS_None`` (in configuration: ``None``) - Do not align bit fields on consecutive lines. + int a = 1; + int somelongname = 2; + double c = 3; - * ``ACS_Consecutive`` (in configuration: ``Consecutive``) - Align bit fields on consecutive lines. This will result in - formattings like: + int aaaa : 1; + int b : 12; + int ccc : 8; - .. code-block:: c++ + int aaaa = 12; + float b = 23; + std::string ccc; - int aaaa : 1; - int b : 12; - int ccc : 8; + * ``bool AcrossEmptyLines`` Whether to align across empty lines. - int d : 2; - /* A comment. */ - int ee : 3; + .. code-block:: c++ + + true: + int a = 1; + int somelongname = 2; + double c = 3; + + int d = 3; + + false: + int a = 1; + int somelongname = 2; + double c = 3; + + int d = 3; + + * ``bool AcrossComments`` Whether to align across comments. - * ``ACS_AcrossEmptyLines`` (in configuration: ``AcrossEmptyLines``) - Same as ACS_Consecutive, but also spans over empty lines, e.g. + .. code-block:: c++ + + true: + int d = 3; + /* A comment. */ + double e = 4; + + false: + int d = 3; + /* A comment. */ + double e = 4; - .. code-block:: c++ + * ``bool AlignCompound`` Only for ``AlignConsecutiveAssignments``. Whether compound assignments + like ``+=`` are aligned along with ``=``. - int aaaa : 1; - int b : 12; - int ccc : 8; + .. code-block:: c++ - int d : 2; - /* A comment. */ - int ee : 3; + true: + a &= 2; + bbb = 2; - * ``ACS_AcrossComments`` (in configuration: ``AcrossComments``) - Same as ACS_Consecutive, but also spans over lines only containing - comments, e.g. + false: + a &= 2; + bbb = 2; - .. code-block:: c++ + * ``bool PadOperators`` Only for ``AlignConsecutiveAssignments``. Whether short assignment + operators are left-padded to the same length as long ones in order to + put all assignment operators to the right of the left hand side. - int aaaa : 1; - int b : 12; - int ccc : 8; + .. code-block:: c++ - int d : 2; - /* A comment. */ - int ee : 3; + true: + a >>= 2; + bbb = 2; - * ``ACS_AcrossEmptyLinesAndComments`` - (in configuration: ``AcrossEmptyLinesAndComments``) + a = 2; + bbb >>= 2; - Same as ACS_Consecutive, but also spans over lines only containing - comments and empty lines, e.g. + false: + a >>= 2; + bbb = 2; - .. code-block:: c++ + a = 2; + bbb >>= 2; - int aaaa : 1; - int b : 12; - int ccc : 8; - int d : 2; - /* A comment. */ - int ee : 3; +.. _AlignConsecutiveDeclarations: -**AlignConsecutiveDeclarations** (``AlignConsecutiveStyle``) +**AlignConsecutiveDeclarations** (``AlignConsecutiveStyle``) :versionbadge:`clang-format 3.8` :ref:`¶ ` Style of aligning consecutive declarations. ``Consecutive`` will align the declaration names of consecutive lines. @@ -398,69 +546,120 @@ the configuration (without a prefix: ``Auto``). float b = 23; std::string ccc; - Possible values: + Nested configuration flags: + + Alignment options. + + They can also be read as a whole for compatibility. The choices are: + - None + - Consecutive + - AcrossEmptyLines + - AcrossComments + - AcrossEmptyLinesAndComments + + For example, to align across empty lines and not across comments, either + of these work. + + .. code-block:: c++ + + AlignConsecutiveMacros: AcrossEmptyLines + + AlignConsecutiveMacros: + Enabled: true + AcrossEmptyLines: true + AcrossComments: false + + * ``bool Enabled`` Whether aligning is enabled. + + .. code-block:: c++ + + #define SHORT_NAME 42 + #define LONGER_NAME 0x007f + #define EVEN_LONGER_NAME (2) + #define foo(x) (x * x) + #define bar(y, z) (y + z) - * ``ACS_None`` (in configuration: ``None``) - Do not align bit declarations on consecutive lines. + int a = 1; + int somelongname = 2; + double c = 3; - * ``ACS_Consecutive`` (in configuration: ``Consecutive``) - Align declarations on consecutive lines. This will result in - formattings like: + int aaaa : 1; + int b : 12; + int ccc : 8; - .. code-block:: c++ + int aaaa = 12; + float b = 23; + std::string ccc; - int aaaa = 12; - float b = 23; - std::string ccc; + * ``bool AcrossEmptyLines`` Whether to align across empty lines. - int a = 42; - /* A comment. */ - bool c = false; + .. code-block:: c++ + + true: + int a = 1; + int somelongname = 2; + double c = 3; + + int d = 3; + + false: + int a = 1; + int somelongname = 2; + double c = 3; + + int d = 3; + + * ``bool AcrossComments`` Whether to align across comments. - * ``ACS_AcrossEmptyLines`` (in configuration: ``AcrossEmptyLines``) - Same as ACS_Consecutive, but also spans over empty lines, e.g. + .. code-block:: c++ + + true: + int d = 3; + /* A comment. */ + double e = 4; + + false: + int d = 3; + /* A comment. */ + double e = 4; - .. code-block:: c++ + * ``bool AlignCompound`` Only for ``AlignConsecutiveAssignments``. Whether compound assignments + like ``+=`` are aligned along with ``=``. - int aaaa = 12; - float b = 23; - std::string ccc; + .. code-block:: c++ - int a = 42; - /* A comment. */ - bool c = false; + true: + a &= 2; + bbb = 2; - * ``ACS_AcrossComments`` (in configuration: ``AcrossComments``) - Same as ACS_Consecutive, but also spans over lines only containing - comments, e.g. + false: + a &= 2; + bbb = 2; - .. code-block:: c++ + * ``bool PadOperators`` Only for ``AlignConsecutiveAssignments``. Whether short assignment + operators are left-padded to the same length as long ones in order to + put all assignment operators to the right of the left hand side. - int aaaa = 12; - float b = 23; - std::string ccc; + .. code-block:: c++ - int a = 42; - /* A comment. */ - bool c = false; + true: + a >>= 2; + bbb = 2; - * ``ACS_AcrossEmptyLinesAndComments`` - (in configuration: ``AcrossEmptyLinesAndComments``) + a = 2; + bbb >>= 2; - Same as ACS_Consecutive, but also spans over lines only containing - comments and empty lines, e.g. + false: + a >>= 2; + bbb = 2; - .. code-block:: c++ + a = 2; + bbb >>= 2; - int aaaa = 12; - float b = 23; - std::string ccc; - int a = 42; - /* A comment. */ - bool c = false; +.. _AlignConsecutiveMacros: -**AlignConsecutiveMacros** (``AlignConsecutiveStyle``) +**AlignConsecutiveMacros** (``AlignConsecutiveStyle``) :versionbadge:`clang-format 9` :ref:`¶ ` Style of aligning consecutive macro definitions. ``Consecutive`` will result in formattings like: @@ -473,69 +672,120 @@ the configuration (without a prefix: ``Auto``). #define foo(x) (x * x) #define bar(y, z) (y + z) - Possible values: + Nested configuration flags: + + Alignment options. + + They can also be read as a whole for compatibility. The choices are: + - None + - Consecutive + - AcrossEmptyLines + - AcrossComments + - AcrossEmptyLinesAndComments + + For example, to align across empty lines and not across comments, either + of these work. + + .. code-block:: c++ + + AlignConsecutiveMacros: AcrossEmptyLines + + AlignConsecutiveMacros: + Enabled: true + AcrossEmptyLines: true + AcrossComments: false + + * ``bool Enabled`` Whether aligning is enabled. + + .. code-block:: c++ + + #define SHORT_NAME 42 + #define LONGER_NAME 0x007f + #define EVEN_LONGER_NAME (2) + #define foo(x) (x * x) + #define bar(y, z) (y + z) - * ``ACS_None`` (in configuration: ``None``) - Do not align macro definitions on consecutive lines. + int a = 1; + int somelongname = 2; + double c = 3; - * ``ACS_Consecutive`` (in configuration: ``Consecutive``) - Align macro definitions on consecutive lines. This will result in - formattings like: + int aaaa : 1; + int b : 12; + int ccc : 8; - .. code-block:: c++ + int aaaa = 12; + float b = 23; + std::string ccc; - #define SHORT_NAME 42 - #define LONGER_NAME 0x007f - #define EVEN_LONGER_NAME (2) + * ``bool AcrossEmptyLines`` Whether to align across empty lines. - #define foo(x) (x * x) - /* some comment */ - #define bar(y, z) (y + z) + .. code-block:: c++ + + true: + int a = 1; + int somelongname = 2; + double c = 3; + + int d = 3; + + false: + int a = 1; + int somelongname = 2; + double c = 3; + + int d = 3; + + * ``bool AcrossComments`` Whether to align across comments. - * ``ACS_AcrossEmptyLines`` (in configuration: ``AcrossEmptyLines``) - Same as ACS_Consecutive, but also spans over empty lines, e.g. + .. code-block:: c++ + + true: + int d = 3; + /* A comment. */ + double e = 4; + + false: + int d = 3; + /* A comment. */ + double e = 4; - .. code-block:: c++ + * ``bool AlignCompound`` Only for ``AlignConsecutiveAssignments``. Whether compound assignments + like ``+=`` are aligned along with ``=``. - #define SHORT_NAME 42 - #define LONGER_NAME 0x007f - #define EVEN_LONGER_NAME (2) + .. code-block:: c++ - #define foo(x) (x * x) - /* some comment */ - #define bar(y, z) (y + z) + true: + a &= 2; + bbb = 2; - * ``ACS_AcrossComments`` (in configuration: ``AcrossComments``) - Same as ACS_Consecutive, but also spans over lines only containing - comments, e.g. + false: + a &= 2; + bbb = 2; - .. code-block:: c++ + * ``bool PadOperators`` Only for ``AlignConsecutiveAssignments``. Whether short assignment + operators are left-padded to the same length as long ones in order to + put all assignment operators to the right of the left hand side. - #define SHORT_NAME 42 - #define LONGER_NAME 0x007f - #define EVEN_LONGER_NAME (2) + .. code-block:: c++ - #define foo(x) (x * x) - /* some comment */ - #define bar(y, z) (y + z) + true: + a >>= 2; + bbb = 2; - * ``ACS_AcrossEmptyLinesAndComments`` - (in configuration: ``AcrossEmptyLinesAndComments``) + a = 2; + bbb >>= 2; - Same as ACS_Consecutive, but also spans over lines only containing - comments and empty lines, e.g. + false: + a >>= 2; + bbb = 2; - .. code-block:: c++ + a = 2; + bbb >>= 2; - #define SHORT_NAME 42 - #define LONGER_NAME 0x007f - #define EVEN_LONGER_NAME (2) - #define foo(x) (x * x) - /* some comment */ - #define bar(y, z) (y + z) +.. _AlignEscapedNewlines: -**AlignEscapedNewlines** (``EscapedNewlineAlignmentStyle``) +**AlignEscapedNewlines** (``EscapedNewlineAlignmentStyle``) :versionbadge:`clang-format 5` :ref:`¶ ` Options for aligning backslashes in escaped newlines. Possible values: @@ -575,7 +825,9 @@ the configuration (without a prefix: ``Auto``). -**AlignOperands** (``OperandAlignmentStyle``) +.. _AlignOperands: + +**AlignOperands** (``OperandAlignmentStyle``) :versionbadge:`clang-format 3.5` :ref:`¶ ` If ``true``, horizontally align operands of binary and ternary expressions. @@ -619,16 +871,94 @@ the configuration (without a prefix: ``Auto``). -**AlignTrailingComments** (``bool``) - If ``true``, aligns trailing comments. +.. _AlignTrailingComments: - .. code-block:: c++ +**AlignTrailingComments** (``TrailingCommentsAlignmentStyle``) :versionbadge:`clang-format 3.7` :ref:`¶ ` + Control of trailing comments. + + NOTE: As of clang-format 16 this option is not a bool but can be set + to the options. Conventional bool options still can be parsed as before. + + + .. code-block:: yaml + + # Example of usage: + AlignTrailingComments: + Kind: Always + OverEmptyLines: 2 + + Nested configuration flags: + + Alignment options + + * ``TrailingCommentsAlignmentKinds Kind`` + Specifies the way to align trailing comments. + + Possible values: + + * ``TCAS_Leave`` (in configuration: ``Leave``) + Leave trailing comments as they are. + + .. code-block:: c++ + + int a; // comment + int ab; // comment + + int abc; // comment + int abcd; // comment + + * ``TCAS_Always`` (in configuration: ``Always``) + Align trailing comments. + + .. code-block:: c++ + + int a; // comment + int ab; // comment + + int abc; // comment + int abcd; // comment + + * ``TCAS_Never`` (in configuration: ``Never``) + Don't align trailing comments but other formatter applies. + + .. code-block:: c++ + + int a; // comment + int ab; // comment + + int abc; // comment + int abcd; // comment + + + * ``unsigned OverEmptyLines`` How many empty lines to apply alignment. + When both ``MaxEmptyLinesToKeep`` and ``OverEmptyLines`` are set to 2, + it formats like below. + + .. code-block:: c++ + + int a; // all these + + int ab; // comments are + + + int abcdef; // aligned + + When ``MaxEmptyLinesToKeep`` is set to 2 and ``OverEmptyLines`` is set + to 1, it formats like below. + + .. code-block:: c++ + + int a; // these are + + int ab; // aligned + + + int abcdef; // but this isn't - true: false: - int a; // My comment a vs. int a; // My comment a - int b = 2; // comment b int b = 2; // comment about b -**AllowAllArgumentsOnNextLine** (``bool``) +.. _AllowAllArgumentsOnNextLine: + +**AllowAllArgumentsOnNextLine** (``Boolean``) :versionbadge:`clang-format 9` :ref:`¶ ` If a function call or braced initializer list doesn't fit on a line, allow putting all arguments onto the next line, even if ``BinPackArguments`` is ``false``. @@ -645,25 +975,15 @@ the configuration (without a prefix: ``Auto``). c, d); -**AllowAllConstructorInitializersOnNextLine** (``bool``) - If a constructor definition with a member initializer list doesn't - fit on a single line, allow putting all member initializers onto the next - line, if ```ConstructorInitializerAllOnOneLineOrOnePerLine``` is true. - Note that this parameter has no effect if - ```ConstructorInitializerAllOnOneLineOrOnePerLine``` is false. - - .. code-block:: c++ +.. _AllowAllConstructorInitializersOnNextLine: - true: - MyClass::MyClass() : - member0(0), member1(2) {} +**AllowAllConstructorInitializersOnNextLine** (``Boolean``) :versionbadge:`clang-format 9` :ref:`¶ ` + This option is **deprecated**. See ``NextLine`` of + ``PackConstructorInitializers``. - false: - MyClass::MyClass() : - member0(0), - member1(2) {} +.. _AllowAllParametersOfDeclarationOnNextLine: -**AllowAllParametersOfDeclarationOnNextLine** (``bool``) +**AllowAllParametersOfDeclarationOnNextLine** (``Boolean``) :versionbadge:`clang-format 3.3` :ref:`¶ ` If the function declaration doesn't fit on a line, allow putting all parameters of a function declaration onto the next line even if ``BinPackParameters`` is ``false``. @@ -681,7 +1001,9 @@ the configuration (without a prefix: ``Auto``). int d, int e); -**AllowShortBlocksOnASingleLine** (``ShortBlockStyle``) +.. _AllowShortBlocksOnASingleLine: + +**AllowShortBlocksOnASingleLine** (``ShortBlockStyle``) :versionbadge:`clang-format 3.5` :ref:`¶ ` Dependent on the value, ``while (true) { continue; }`` can be put on a single line. @@ -718,7 +1040,9 @@ the configuration (without a prefix: ``Auto``). -**AllowShortCaseLabelsOnASingleLine** (``bool``) +.. _AllowShortCaseLabelsOnASingleLine: + +**AllowShortCaseLabelsOnASingleLine** (``Boolean``) :versionbadge:`clang-format 3.6` :ref:`¶ ` If ``true``, short case labels will be contracted to a single line. .. code-block:: c++ @@ -732,7 +1056,9 @@ the configuration (without a prefix: ``Auto``). return; } -**AllowShortEnumsOnASingleLine** (``bool``) +.. _AllowShortEnumsOnASingleLine: + +**AllowShortEnumsOnASingleLine** (``Boolean``) :versionbadge:`clang-format 11` :ref:`¶ ` Allow short enums on a single line. .. code-block:: c++ @@ -741,13 +1067,14 @@ the configuration (without a prefix: ``Auto``). enum { A, B } myEnum; false: - enum - { + enum { A, B } myEnum; -**AllowShortFunctionsOnASingleLine** (``ShortFunctionStyle``) +.. _AllowShortFunctionsOnASingleLine: + +**AllowShortFunctionsOnASingleLine** (``ShortFunctionStyle``) :versionbadge:`clang-format 3.5` :ref:`¶ ` Dependent on the value, ``int f() { return 0; }`` can be put on a single line. @@ -807,7 +1134,9 @@ the configuration (without a prefix: ``Auto``). -**AllowShortIfStatementsOnASingleLine** (``ShortIfStyle``) +.. _AllowShortIfStatementsOnASingleLine: + +**AllowShortIfStatementsOnASingleLine** (``ShortIfStyle``) :versionbadge:`clang-format 3.3` :ref:`¶ ` Dependent on the value, ``if (a) return;`` can be put on a single line. Possible values: @@ -885,7 +1214,9 @@ the configuration (without a prefix: ``Auto``). -**AllowShortLambdasOnASingleLine** (``ShortLambdaStyle``) +.. _AllowShortLambdasOnASingleLine: + +**AllowShortLambdasOnASingleLine** (``ShortLambdaStyle``) :versionbadge:`clang-format 9` :ref:`¶ ` Dependent on the value, ``auto lambda []() { return 0; }`` can be put on a single line. @@ -899,36 +1230,40 @@ the configuration (without a prefix: ``Auto``). .. code-block:: c++ - auto lambda = [](int a) {} + auto lambda = [](int a) {}; auto lambda2 = [](int a) { return a; }; * ``SLS_Inline`` (in configuration: ``Inline``) - Merge lambda into a single line if argument of a function. + Merge lambda into a single line if the lambda is argument of a function. .. code-block:: c++ - auto lambda = [](int a) { - return a; + auto lambda = [](int x, int y) { + return x < y; }; - sort(a.begin(), a.end(), ()[] { return x < y; }) + sort(a.begin(), a.end(), [](int x, int y) { return x < y; }); * ``SLS_All`` (in configuration: ``All``) Merge all lambdas fitting on a single line. .. code-block:: c++ - auto lambda = [](int a) {} + auto lambda = [](int a) {}; auto lambda2 = [](int a) { return a; }; -**AllowShortLoopsOnASingleLine** (``bool``) +.. _AllowShortLoopsOnASingleLine: + +**AllowShortLoopsOnASingleLine** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ ` If ``true``, ``while (true) continue;`` can be put on a single line. -**AlwaysBreakAfterDefinitionReturnType** (``DefinitionReturnTypeBreakingStyle``) +.. _AlwaysBreakAfterDefinitionReturnType: + +**AlwaysBreakAfterDefinitionReturnType** (``DefinitionReturnTypeBreakingStyle``) :versionbadge:`clang-format 3.7` :ref:`¶ ` The function definition return type breaking style to use. This option is **deprecated** and is retained for backwards compatibility. @@ -946,7 +1281,9 @@ the configuration (without a prefix: ``Auto``). -**AlwaysBreakAfterReturnType** (``ReturnTypeBreakingStyle``) +.. _AlwaysBreakAfterReturnType: + +**AlwaysBreakAfterReturnType** (``ReturnTypeBreakingStyle``) :versionbadge:`clang-format 3.8` :ref:`¶ ` The function declaration return type breaking style to use. Possible values: @@ -1029,7 +1366,9 @@ the configuration (without a prefix: ``Auto``). -**AlwaysBreakBeforeMultilineStrings** (``bool``) +.. _AlwaysBreakBeforeMultilineStrings: + +**AlwaysBreakBeforeMultilineStrings** (``Boolean``) :versionbadge:`clang-format 3.4` :ref:`¶ ` If ``true``, always break before multiline string literals. This flag is mean to make cases where there are multiple multiline strings @@ -1044,7 +1383,9 @@ the configuration (without a prefix: ``Auto``). "bbbb" "cccc"; "cccc"; -**AlwaysBreakTemplateDeclarations** (``BreakTemplateDeclarationsStyle``) +.. _AlwaysBreakTemplateDeclarations: + +**AlwaysBreakTemplateDeclarations** (``BreakTemplateDeclarationsStyle``) :versionbadge:`clang-format 3.4` :ref:`¶ ` The template declaration breaking style to use. Possible values: @@ -1089,7 +1430,9 @@ the configuration (without a prefix: ``Auto``). -**AttributeMacros** (``std::vector``) +.. _AttributeMacros: + +**AttributeMacros** (``List of Strings``) :versionbadge:`clang-format 12` :ref:`¶ ` A vector of strings that should be interpreted as attributes/qualifiers instead of identifiers. This can be useful for language extensions or static analyzer annotations. @@ -1108,7 +1451,9 @@ the configuration (without a prefix: ``Auto``). AttributeMacros: ['__capability', '__output', '__ununsed'] -**BinPackArguments** (``bool``) +.. _BinPackArguments: + +**BinPackArguments** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ ` If ``false``, a function call's arguments will either be all on the same line or will have one line each. @@ -1127,7 +1472,9 @@ the configuration (without a prefix: ``Auto``). aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa); } -**BinPackParameters** (``bool``) +.. _BinPackParameters: + +**BinPackParameters** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ ` If ``false``, a function declaration's or function definition's parameters will either all be on the same line or will have one line each. @@ -1142,7 +1489,9 @@ the configuration (without a prefix: ``Auto``). int aaaaaaaaaaaaaaaaaaaa, int aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa) {} -**BitFieldColonSpacing** (``BitFieldColonSpacingStyle``) +.. _BitFieldColonSpacing: + +**BitFieldColonSpacing** (``BitFieldColonSpacingStyle``) :versionbadge:`clang-format 12` :ref:`¶ ` The BitFieldColonSpacingStyle to use for bitfields. Possible values: @@ -1179,7 +1528,9 @@ the configuration (without a prefix: ``Auto``). -**BraceWrapping** (``BraceWrappingFlags``) +.. _BraceWrapping: + +**BraceWrapping** (``BraceWrappingFlags``) :versionbadge:`clang-format 3.8` :ref:`¶ ` Control of individual brace wrapping cases. If ``BreakBeforeBraces`` is set to ``BS_Custom``, use this to specify how @@ -1196,6 +1547,14 @@ the configuration (without a prefix: ``Auto``). Nested configuration flags: + Precise control over the wrapping of braces. + + .. code-block:: c++ + + # Should be declared this way: + BreakBeforeBraces: Custom + BraceWrapping: + AfterClass: true * ``bool AfterCaseLabel`` Wrap case labels. @@ -1219,12 +1578,12 @@ the configuration (without a prefix: ``Auto``). .. code-block:: c++ true: - class foo {}; - - false: class foo {}; + false: + class foo {}; + * ``BraceWrappingAfterControlStatementStyle AfterControlStatement`` Wrap control statements (``if``/``for``/``while``/``switch``/..). @@ -1438,6 +1797,7 @@ the configuration (without a prefix: ``Auto``). .. code-block:: c++ + false: true: int f() vs. int f() {} { } @@ -1449,6 +1809,7 @@ the configuration (without a prefix: ``Auto``). .. code-block:: c++ + false: true: class Foo vs. class Foo {} { } @@ -1460,12 +1821,52 @@ the configuration (without a prefix: ``Auto``). .. code-block:: c++ + false: true: namespace Foo vs. namespace Foo {} { } -**BreakAfterJavaFieldAnnotations** (``bool``) +.. _BreakAfterAttributes: + +**BreakAfterAttributes** (``AttributeBreakingStyle``) :versionbadge:`clang-format 16` :ref:`¶ ` + Break after a group of C++11 attributes before a function + declaration/definition name. + + Possible values: + + * ``ABS_Always`` (in configuration: ``Always``) + Always break after attributes. + + .. code-block:: c++ + + [[nodiscard]] + inline int f(); + [[gnu::const]] [[nodiscard]] + int g(); + + * ``ABS_Leave`` (in configuration: ``Leave``) + Leave the line breaking after attributes as is. + + .. code-block:: c++ + + [[nodiscard]] inline int f(); + [[gnu::const]] [[nodiscard]] + int g(); + + * ``ABS_Never`` (in configuration: ``Never``) + Never break after attributes. + + .. code-block:: c++ + + [[nodiscard]] inline int f(); + [[gnu::const]] [[nodiscard]] int g(); + + + +.. _BreakAfterJavaFieldAnnotations: + +**BreakAfterJavaFieldAnnotations** (``Boolean``) :versionbadge:`clang-format 3.8` :ref:`¶ ` Break after each annotation on a field in Java files. .. code-block:: java @@ -1475,7 +1876,28 @@ the configuration (without a prefix: ``Auto``). @Mock DataLoad loader; -**BreakBeforeBinaryOperators** (``BinaryOperatorStyle``) +.. _BreakArrays: + +**BreakArrays** (``Boolean``) :versionbadge:`clang-format 16` :ref:`¶ ` + If ``true``, clang-format will always break after a Json array `[` + otherwise it will scan until the closing `]` to determine if it should add + newlines between elements (prettier compatible). + + NOTE: This is currently only for formatting JSON. + + .. code-block:: c++ + + true: false: + [ vs. [1, 2, 3, 4] + 1, + 2, + 3, + 4 + ] + +.. _BreakBeforeBinaryOperators: + +**BreakBeforeBinaryOperators** (``BinaryOperatorStyle``) :versionbadge:`clang-format 3.6` :ref:`¶ ` The way to wrap binary operators. Possible values: @@ -1524,7 +1946,9 @@ the configuration (without a prefix: ``Auto``). -**BreakBeforeBraces** (``BraceBreakingStyle``) +.. _BreakBeforeBraces: + +**BreakBeforeBraces** (``BraceBreakingStyle``) :versionbadge:`clang-format 3.7` :ref:`¶ ` The brace breaking style to use. Possible values: @@ -1975,19 +2399,75 @@ the configuration (without a prefix: ``Auto``). -**BreakBeforeConceptDeclarations** (``bool``) - If ``true``, concept will be placed on a new line. +.. _BreakBeforeConceptDeclarations: - .. code-block:: c++ +**BreakBeforeConceptDeclarations** (``BreakBeforeConceptDeclarationsStyle``) :versionbadge:`clang-format 12` :ref:`¶ ` + The concept declaration style to use. - true: - template - concept ... + Possible values: - false: - template concept ... + * ``BBCDS_Never`` (in configuration: ``Never``) + Keep the template declaration line together with ``concept``. + + .. code-block:: c++ + + template concept C = ...; + + * ``BBCDS_Allowed`` (in configuration: ``Allowed``) + Breaking between template declaration and ``concept`` is allowed. The + actual behavior depends on the content and line breaking rules and + penalities. + + * ``BBCDS_Always`` (in configuration: ``Always``) + Always break before ``concept``, putting it in the line after the + template declaration. + + .. code-block:: c++ + + template + concept C = ...; + + + +.. _BreakBeforeInlineASMColon: + +**BreakBeforeInlineASMColon** (``BreakBeforeInlineASMColonStyle``) :versionbadge:`clang-format 16` :ref:`¶ ` + The inline ASM colon style to use. + + Possible values: + + * ``BBIAS_Never`` (in configuration: ``Never``) + No break before inline ASM colon. + + .. code-block:: c++ + + asm volatile("string", : : val); + + * ``BBIAS_OnlyMultiline`` (in configuration: ``OnlyMultiline``) + Break before inline ASM colon if the line length is longer than column + limit. + + .. code-block:: c++ + + asm volatile("string", : : val); + asm("cmoveq %1, %2, %[result]" + : [result] "=r"(result) + : "r"(test), "r"(new), "[result]"(old)); + + * ``BBIAS_Always`` (in configuration: ``Always``) + Always break before inline ASM colon. + + .. code-block:: c++ + + asm volatile("string", + : + : val); -**BreakBeforeTernaryOperators** (``bool``) + + +.. _BreakBeforeTernaryOperators: + +**BreakBeforeTernaryOperators** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ ` If ``true``, ternary operators will be placed after line breaks. .. code-block:: c++ @@ -2002,8 +2482,10 @@ the configuration (without a prefix: ``Auto``). firstValue : SecondValueVeryVeryVeryVeryLong; -**BreakConstructorInitializers** (``BreakConstructorInitializersStyle``) - The constructor initializers style to use. +.. _BreakConstructorInitializers: + +**BreakConstructorInitializers** (``BreakConstructorInitializersStyle``) :versionbadge:`clang-format 5` :ref:`¶ ` + The break constructor initializers style to use. Possible values: @@ -2037,7 +2519,9 @@ the configuration (without a prefix: ``Auto``). -**BreakInheritanceList** (``BreakInheritanceListStyle``) +.. _BreakInheritanceList: + +**BreakInheritanceList** (``BreakInheritanceListStyle``) :versionbadge:`clang-format 7` :ref:`¶ ` The inheritance list style to use. Possible values: @@ -2084,7 +2568,9 @@ the configuration (without a prefix: ``Auto``). -**BreakStringLiterals** (``bool``) +.. _BreakStringLiterals: + +**BreakStringLiterals** (``Boolean``) :versionbadge:`clang-format 3.9` :ref:`¶ ` Allow breaking string literals when formatting. .. code-block:: c++ @@ -2098,14 +2584,18 @@ the configuration (without a prefix: ``Auto``). const char* x = "veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongString"; -**ColumnLimit** (``unsigned``) +.. _ColumnLimit: + +**ColumnLimit** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ ` The column limit. A column limit of ``0`` means that there is no column limit. In this case, clang-format will respect the input's line breaking decisions within statements unless they contradict other rules. -**CommentPragmas** (``std::string``) +.. _CommentPragmas: + +**CommentPragmas** (``String``) :versionbadge:`clang-format 3.7` :ref:`¶ ` A regular expression that describes comments with special meaning, which should not be split into lines or otherwise changed. @@ -2115,7 +2605,9 @@ the configuration (without a prefix: ``Auto``). // Will leave the following line unaffected #include // FOOBAR pragma: keep -**CompactNamespaces** (``bool``) +.. _CompactNamespaces: + +**CompactNamespaces** (``Boolean``) :versionbadge:`clang-format 5` :ref:`¶ ` If ``true``, consecutive namespace declarations will be on the same line. If ``false``, each namespace is declared on a new line. @@ -2140,30 +2632,21 @@ the configuration (without a prefix: ``Auto``). namespace Extra { }}} -**ConstructorInitializerAllOnOneLineOrOnePerLine** (``bool``) - If the constructor initializers don't fit on a line, put each - initializer on its own line. - - .. code-block:: c++ +.. _ConstructorInitializerAllOnOneLineOrOnePerLine: - true: - SomeClass::Constructor() - : aaaaaaaa(aaaaaaaa), aaaaaaaa(aaaaaaaa), aaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaa) { - return 0; - } +**ConstructorInitializerAllOnOneLineOrOnePerLine** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ ` + This option is **deprecated**. See ``CurrentLine`` of + ``PackConstructorInitializers``. - false: - SomeClass::Constructor() - : aaaaaaaa(aaaaaaaa), aaaaaaaa(aaaaaaaa), - aaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaa) { - return 0; - } +.. _ConstructorInitializerIndentWidth: -**ConstructorInitializerIndentWidth** (``unsigned``) +**ConstructorInitializerIndentWidth** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ ` The number of characters to use for indentation of constructor initializer lists as well as inheritance lists. -**ContinuationIndentWidth** (``unsigned``) +.. _ContinuationIndentWidth: + +**ContinuationIndentWidth** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ ` Indent width for line continuations. .. code-block:: c++ @@ -2174,7 +2657,9 @@ the configuration (without a prefix: ``Auto``). longFunction( // Again a long comment arg); -**Cpp11BracedListStyle** (``bool``) +.. _Cpp11BracedListStyle: + +**Cpp11BracedListStyle** (``Boolean``) :versionbadge:`clang-format 3.4` :ref:`¶ ` If ``true``, format braced lists as best suited for C++11 braced lists. @@ -2197,21 +2682,29 @@ the configuration (without a prefix: ``Auto``). f(MyMap[{composite, key}]); f(MyMap[{ composite, key }]); new int[3]{1, 2, 3}; new int[3]{ 1, 2, 3 }; -**DeriveLineEnding** (``bool``) - Analyze the formatted file for the most used line ending (``\r\n`` - or ``\n``). ``UseCRLF`` is only used as a fallback if none can be derived. +.. _DeriveLineEnding: -**DerivePointerAlignment** (``bool``) +**DeriveLineEnding** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ ` + This option is **deprecated**. See ``DeriveLF`` and ``DeriveCRLF`` of + ``LineEnding``. + +.. _DerivePointerAlignment: + +**DerivePointerAlignment** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ ` If ``true``, analyze the formatted file for the most common alignment of ``&`` and ``*``. Pointer and reference alignment styles are going to be updated according to the preferences found in the file. ``PointerAlignment`` is then used only as fallback. -**DisableFormat** (``bool``) +.. _DisableFormat: + +**DisableFormat** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ ` Disables formatting completely. -**EmptyLineAfterAccessModifier** (``EmptyLineAfterAccessModifierStyle``) +.. _EmptyLineAfterAccessModifier: + +**EmptyLineAfterAccessModifier** (``EmptyLineAfterAccessModifierStyle``) :versionbadge:`clang-format 13` :ref:`¶ ` Defines when to put an empty line after access modifiers. ``EmptyLineBeforeAccessModifier`` configuration handles the number of empty lines between two access modifiers. @@ -2264,7 +2757,9 @@ the configuration (without a prefix: ``Auto``). -**EmptyLineBeforeAccessModifier** (``EmptyLineBeforeAccessModifierStyle``) +.. _EmptyLineBeforeAccessModifier: + +**EmptyLineBeforeAccessModifier** (``EmptyLineBeforeAccessModifierStyle``) :versionbadge:`clang-format 12` :ref:`¶ ` Defines in which cases to put empty line before access modifiers. Possible values: @@ -2333,7 +2828,9 @@ the configuration (without a prefix: ``Auto``). -**ExperimentalAutoDetectBinPacking** (``bool``) +.. _ExperimentalAutoDetectBinPacking: + +**ExperimentalAutoDetectBinPacking** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ ` If ``true``, clang-format detects whether function calls and definitions are formatted with one parameter per line. @@ -2345,20 +2842,27 @@ the configuration (without a prefix: ``Auto``). NOTE: This is an experimental flag, that might go away or be renamed. Do not use this in config files, etc. Use at your own risk. -**FixNamespaceComments** (``bool``) +.. _FixNamespaceComments: + +**FixNamespaceComments** (``Boolean``) :versionbadge:`clang-format 5` :ref:`¶ ` If ``true``, clang-format adds missing namespace end comments for - short namespaces and fixes invalid existing ones. Short ones are - controlled by "ShortNamespaceLines". + namespaces and fixes invalid existing ones. This doesn't affect short + namespaces, which are controlled by ``ShortNamespaceLines``. .. code-block:: c++ true: false: - namespace a { vs. namespace a { - foo(); foo(); - bar(); bar(); + namespace longNamespace { vs. namespace longNamespace { + void foo(); void foo(); + void bar(); void bar(); } // namespace a } + namespace shortNamespace { namespace shortNamespace { + void baz(); void baz(); + } } + +.. _ForEachMacros: -**ForEachMacros** (``std::vector``) +**ForEachMacros** (``List of Strings``) :versionbadge:`clang-format 3.7` :ref:`¶ ` A vector of macros that should be interpreted as foreach loops instead of as function calls. @@ -2377,7 +2881,9 @@ the configuration (without a prefix: ``Auto``). For example: BOOST_FOREACH. -**IfMacros** (``std::vector``) +.. _IfMacros: + +**IfMacros** (``List of Strings``) :versionbadge:`clang-format 13` :ref:`¶ ` A vector of macros that should be interpreted as conditionals instead of as function calls. @@ -2399,7 +2905,9 @@ the configuration (without a prefix: ``Auto``). For example: `KJ_IF_MAYBE `_ -**IncludeBlocks** (``IncludeBlocksStyle``) +.. _IncludeBlocks: + +**IncludeBlocks** (``IncludeBlocksStyle``) :versionbadge:`clang-format 6` :ref:`¶ ` Dependent on the value, multiple ``#include`` blocks can be sorted as one and divided based on category. @@ -2439,7 +2947,9 @@ the configuration (without a prefix: ``Auto``). -**IncludeCategories** (``std::vector``) +.. _IncludeCategories: + +**IncludeCategories** (``List of IncludeCategories``) :versionbadge:`clang-format 3.8` :ref:`¶ ` Regular expressions denoting the different ``#include`` categories used for ordering ``#includes``. @@ -2479,7 +2989,7 @@ the configuration (without a prefix: ``Auto``). Priority: 2 SortPriority: 2 CaseSensitive: true - - Regex: '^(<|"(gtest|gmock|isl|json)/)' + - Regex: '^((<|")(gtest|gmock|isl|json)/)' Priority: 3 - Regex: '<[[:alnum:].]+>' Priority: 4 @@ -2487,7 +2997,9 @@ the configuration (without a prefix: ``Auto``). Priority: 1 SortPriority: 0 -**IncludeIsMainRegex** (``std::string``) +.. _IncludeIsMainRegex: + +**IncludeIsMainRegex** (``String``) :versionbadge:`clang-format 3.9` :ref:`¶ ` Specify a regular expression of suffixes that are allowed in the file-to-main-include mapping. @@ -2500,7 +3012,9 @@ the configuration (without a prefix: ``Auto``). For example, if configured to "(_test)?$", then a header a.h would be seen as the "main" include in both a.cc and a_test.cc. -**IncludeIsMainSourceRegex** (``std::string``) +.. _IncludeIsMainSourceRegex: + +**IncludeIsMainSourceRegex** (``String``) :versionbadge:`clang-format 10` :ref:`¶ ` Specify a regular expression for files being formatted that are allowed to be considered "main" in the file-to-main-include mapping. @@ -2520,7 +3034,9 @@ the configuration (without a prefix: ``Auto``). ``ClassImpl.hpp`` would not have the main include file put on top before any other include. -**IndentAccessModifiers** (``bool``) +.. _IndentAccessModifiers: + +**IndentAccessModifiers** (``Boolean``) :versionbadge:`clang-format 13` :ref:`¶ ` Specify whether access modifiers should have their own indentation level. When ``false``, access modifiers are indented (or outdented) relative to @@ -2547,7 +3063,9 @@ the configuration (without a prefix: ``Auto``). return 1; return 1; } } -**IndentCaseBlocks** (``bool``) +.. _IndentCaseBlocks: + +**IndentCaseBlocks** (``Boolean``) :versionbadge:`clang-format 11` :ref:`¶ ` Indent case label blocks one level from the case label. When ``false``, the block following the case label uses the same @@ -2570,7 +3088,9 @@ the configuration (without a prefix: ``Auto``). } } -**IndentCaseLabels** (``bool``) +.. _IndentCaseLabels: + +**IndentCaseLabels** (``Boolean``) :versionbadge:`clang-format 3.3` :ref:`¶ ` Indent case labels one level from the switch statement. When ``false``, use the same indentation level as for the switch @@ -2589,7 +3109,9 @@ the configuration (without a prefix: ``Auto``). plop(); plop(); } } -**IndentExternBlock** (``IndentExternBlockStyle``) +.. _IndentExternBlock: + +**IndentExternBlock** (``IndentExternBlockStyle``) :versionbadge:`clang-format 11` :ref:`¶ ` IndentExternBlockStyle is the type of indenting of extern blocks. Possible values: @@ -2635,7 +3157,9 @@ the configuration (without a prefix: ``Auto``). -**IndentGotoLabels** (``bool``) +.. _IndentGotoLabels: + +**IndentGotoLabels** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ ` Indent goto labels. When ``false``, goto labels are flushed left. @@ -2652,7 +3176,9 @@ the configuration (without a prefix: ``Auto``). return 1; return 1; } } -**IndentPPDirectives** (``PPDirectiveIndentStyle``) +.. _IndentPPDirectives: + +**IndentPPDirectives** (``PPDirectiveIndentStyle``) :versionbadge:`clang-format 6` :ref:`¶ ` The preprocessor directive indenting style to use. Possible values: @@ -2692,8 +3218,13 @@ the configuration (without a prefix: ``Auto``). -**IndentRequires** (``bool``) - Indent the requires clause in a template +.. _IndentRequiresClause: + +**IndentRequiresClause** (``Boolean``) :versionbadge:`clang-format 15` :ref:`¶ ` + Indent the requires clause in a template. This only applies when + ``RequiresClausePosition`` is ``OwnLine``, or ``WithFollowing``. + + In clang-format 12, 13 and 14 it was named ``IndentRequires``. .. code-block:: c++ @@ -2711,7 +3242,9 @@ the configuration (without a prefix: ``Auto``). //.... } -**IndentWidth** (``unsigned``) +.. _IndentWidth: + +**IndentWidth** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ ` The number of columns to use for indentation. .. code-block:: c++ @@ -2725,7 +3258,9 @@ the configuration (without a prefix: ``Auto``). } } -**IndentWrappedFunctionNames** (``bool``) +.. _IndentWrappedFunctionNames: + +**IndentWrappedFunctionNames** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ ` Indent if a function definition or declaration is wrapped after the type. @@ -2739,7 +3274,49 @@ the configuration (without a prefix: ``Auto``). LoooooooooooooooooooooooooooooooooooooooongReturnType LoooooooooooooooooooooooooooooooongFunctionDeclaration(); -**InsertTrailingCommas** (``TrailingCommaStyle``) +.. _InsertBraces: + +**InsertBraces** (``Boolean``) :versionbadge:`clang-format 15` :ref:`¶ ` + Insert braces after control statements (``if``, ``else``, ``for``, ``do``, + and ``while``) in C++ unless the control statements are inside macro + definitions or the braces would enclose preprocessor directives. + + .. warning:: + + Setting this option to `true` could lead to incorrect code formatting due + to clang-format's lack of complete semantic information. As such, extra + care should be taken to review code changes made by this option. + + .. code-block:: c++ + + false: true: + + if (isa(D)) vs. if (isa(D)) { + handleFunctionDecl(D); handleFunctionDecl(D); + else if (isa(D)) } else if (isa(D)) { + handleVarDecl(D); handleVarDecl(D); + else } else { + return; return; + } + + while (i--) vs. while (i--) { + for (auto *A : D.attrs()) for (auto *A : D.attrs()) { + handleAttr(A); handleAttr(A); + } + } + + do vs. do { + --i; --i; + while (i); } while (i); + +.. _InsertNewlineAtEOF: + +**InsertNewlineAtEOF** (``Boolean``) :versionbadge:`clang-format 16` :ref:`¶ ` + Insert a newline at end of file if missing. + +.. _InsertTrailingCommas: + +**InsertTrailingCommas** (``TrailingCommaStyle``) :versionbadge:`clang-format 11` :ref:`¶ ` If set to ``TCS_Wrapped`` will insert trailing commas in container literals (arrays and objects) that wrap across multiple lines. It is currently only available for JavaScript @@ -2771,7 +3348,92 @@ the configuration (without a prefix: ``Auto``). -**JavaImportGroups** (``std::vector``) +.. _IntegerLiteralSeparator: + +**IntegerLiteralSeparator** (``IntegerLiteralSeparatorStyle``) :versionbadge:`clang-format 16` :ref:`¶ ` + Format integer literal separators (``'`` for C++ and ``_`` for C#, Java, + and JavaScript). + + Nested configuration flags: + + Separator format of integer literals of different bases. + + If negative, remove separators. If ``0``, leave the literal as is. If + positive, insert separators between digits starting from the rightmost + digit. + + For example, the config below will leave separators in binary literals + alone, insert separators in decimal literals to separate the digits into + groups of 3, and remove separators in hexadecimal literals. + + .. code-block:: c++ + + IntegerLiteralSeparator: + Binary: 0 + Decimal: 3 + Hex: -1 + + You can also specify a minimum number of digits (``BinaryMinDigits``, + ``DecimalMinDigits``, and ``HexMinDigits``) the integer literal must + have in order for the separators to be inserted. + + * ``int8_t Binary`` Format separators in binary literals. + + .. code-block:: text + + /* -1: */ b = 0b100111101101; + /* 0: */ b = 0b10011'11'0110'1; + /* 3: */ b = 0b100'111'101'101; + /* 4: */ b = 0b1001'1110'1101; + + * ``int8_t BinaryMinDigits`` Format separators in binary literals with a minimum number of digits. + + .. code-block:: text + + // Binary: 3 + // BinaryMinDigits: 7 + b1 = 0b101101; + b2 = 0b1'101'101; + + * ``int8_t Decimal`` Format separators in decimal literals. + + .. code-block:: text + + /* -1: */ d = 18446744073709550592ull; + /* 0: */ d = 184467'440737'0'95505'92ull; + /* 3: */ d = 18'446'744'073'709'550'592ull; + + * ``int8_t DecimalMinDigits`` Format separators in decimal literals with a minimum number of digits. + + .. code-block:: text + + // Decimal: 3 + // DecimalMinDigits: 5 + d1 = 2023; + d2 = 10'000; + + * ``int8_t Hex`` Format separators in hexadecimal literals. + + .. code-block:: text + + /* -1: */ h = 0xDEADBEEFDEADBEEFuz; + /* 0: */ h = 0xDEAD'BEEF'DE'AD'BEE'Fuz; + /* 2: */ h = 0xDE'AD'BE'EF'DE'AD'BE'EFuz; + + * ``int8_t HexMinDigits`` Format separators in hexadecimal literals with a minimum number of + digits. + + .. code-block:: text + + // Hex: 2 + // HexMinDigits: 6 + h1 = 0xABCDE; + h2 = 0xAB'CD'EF; + + +.. _JavaImportGroups: + +**JavaImportGroups** (``List of Strings``) :versionbadge:`clang-format 8` :ref:`¶ ` A vector of prefixes ordered by the desired groups for Java imports. One group's prefix can be a subset of another - the longest prefix is @@ -2806,7 +3468,9 @@ the configuration (without a prefix: ``Auto``). import org.example.ClassD; -**JavaScriptQuotes** (``JavaScriptQuoteStyle``) +.. _JavaScriptQuotes: + +**JavaScriptQuotes** (``JavaScriptQuoteStyle``) :versionbadge:`clang-format 3.9` :ref:`¶ ` The JavaScriptQuoteStyle to use for JavaScript strings. Possible values: @@ -2837,7 +3501,9 @@ the configuration (without a prefix: ``Auto``). -**JavaScriptWrapImports** (``bool``) +.. _JavaScriptWrapImports: + +**JavaScriptWrapImports** (``Boolean``) :versionbadge:`clang-format 3.9` :ref:`¶ ` Whether to wrap JavaScript import/export statements. .. code-block:: js @@ -2852,7 +3518,9 @@ the configuration (without a prefix: ``Auto``). false: import {VeryLongImportsAreAnnoying, VeryLongImportsAreAnnoying, VeryLongImportsAreAnnoying,} from "some/module.js" -**KeepEmptyLinesAtTheStartOfBlocks** (``bool``) +.. _KeepEmptyLinesAtTheStartOfBlocks: + +**KeepEmptyLinesAtTheStartOfBlocks** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ ` If true, the empty line at the start of blocks is kept. .. code-block:: c++ @@ -2863,7 +3531,9 @@ the configuration (without a prefix: ``Auto``). bar(); } } -**LambdaBodyIndentation** (``LambdaBodyIndentationKind``) +.. _LambdaBodyIndentation: + +**LambdaBodyIndentation** (``LambdaBodyIndentationKind``) :versionbadge:`clang-format 13` :ref:`¶ ` The indentation style of lambda bodies. ``Signature`` (the default) causes the lambda body to be indented one additional level relative to the indentation level of the signature. ``OuterScope`` forces the lambda @@ -2872,7 +3542,7 @@ the configuration (without a prefix: ``Auto``). readability to have the signature indented two levels and to use ``OuterScope``. The KJ style guide requires ``OuterScope``. `KJ style guide - `_ + `_ Possible values: @@ -2899,7 +3569,9 @@ the configuration (without a prefix: ``Auto``). -**Language** (``LanguageKind``) +.. _Language: + +**Language** (``LanguageKind``) :versionbadge:`clang-format 3.5` :ref:`¶ ` Language, this format style is targeted at. Possible values: @@ -2936,9 +3608,37 @@ the configuration (without a prefix: ``Auto``). Should be used for Protocol Buffer messages in text format (https://developers.google.com/protocol-buffers/). + * ``LK_Verilog`` (in configuration: ``Verilog``) + Should be used for Verilog and SystemVerilog. + https://standards.ieee.org/ieee/1800/6700/ + https://sci-hub.st/10.1109/IEEESTD.2018.8299595 + -**MacroBlockBegin** (``std::string``) +.. _LineEnding: + +**LineEnding** (``LineEndingStyle``) :versionbadge:`clang-format 16` :ref:`¶ ` + Line ending style (``\n`` or ``\r\n``) to use. + + Possible values: + + * ``LE_LF`` (in configuration: ``LF``) + Use ``\n``. + + * ``LE_CRLF`` (in configuration: ``CRLF``) + Use ``\r\n``. + + * ``LE_DeriveLF`` (in configuration: ``DeriveLF``) + Use ``\n`` unless the input has more lines ending in ``\r\n``. + + * ``LE_DeriveCRLF`` (in configuration: ``DeriveCRLF``) + Use ``\r\n`` unless the input has more lines ending in ``\n``. + + + +.. _MacroBlockBegin: + +**MacroBlockBegin** (``String``) :versionbadge:`clang-format 3.7` :ref:`¶ ` A regular expression matching macros that start a block. .. code-block:: c++ @@ -2967,10 +3667,14 @@ the configuration (without a prefix: ``Auto``). bar(); NS_TABLE_FOO_END -**MacroBlockEnd** (``std::string``) +.. _MacroBlockEnd: + +**MacroBlockEnd** (``String``) :versionbadge:`clang-format 3.7` :ref:`¶ ` A regular expression matching macros that end a block. -**MaxEmptyLinesToKeep** (``unsigned``) +.. _MaxEmptyLinesToKeep: + +**MaxEmptyLinesToKeep** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ ` The maximum number of consecutive empty lines to keep. .. code-block:: c++ @@ -2984,7 +3688,9 @@ the configuration (without a prefix: ``Auto``). return i; } -**NamespaceIndentation** (``NamespaceIndentationKind``) +.. _NamespaceIndentation: + +**NamespaceIndentation** (``NamespaceIndentationKind``) :versionbadge:`clang-format 3.7` :ref:`¶ ` The indentation used for namespaces. Possible values: @@ -3027,7 +3733,9 @@ the configuration (without a prefix: ``Auto``). -**NamespaceMacros** (``std::vector``) +.. _NamespaceMacros: + +**NamespaceMacros** (``List of Strings``) :versionbadge:`clang-format 9` :ref:`¶ ` A vector of macros which are used to open namespace blocks. These are expected to be macros of the form: @@ -3040,7 +3748,9 @@ the configuration (without a prefix: ``Auto``). For example: TESTSUITE -**ObjCBinPackProtocolList** (``BinPackStyle``) +.. _ObjCBinPackProtocolList: + +**ObjCBinPackProtocolList** (``BinPackStyle``) :versionbadge:`clang-format 7` :ref:`¶ ` Controls bin-packing Objective-C protocol conformance list items into as few lines as possible when they go over ``ColumnLimit``. @@ -3086,7 +3796,9 @@ the configuration (without a prefix: ``Auto``). -**ObjCBlockIndentWidth** (``unsigned``) +.. _ObjCBlockIndentWidth: + +**ObjCBlockIndentWidth** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ ` The number of characters to use for indentation of ObjC blocks. .. code-block:: objc @@ -3097,7 +3809,9 @@ the configuration (without a prefix: ``Auto``). [self onOperationDone]; }]; -**ObjCBreakBeforeNestedBlockParam** (``bool``) +.. _ObjCBreakBeforeNestedBlockParam: + +**ObjCBreakBeforeNestedBlockParam** (``Boolean``) :versionbadge:`clang-format 11` :ref:`¶ ` Break parameters list into lines when there is nested block parameters in a function call. @@ -3121,15 +3835,21 @@ the configuration (without a prefix: ``Auto``). }] } -**ObjCSpaceAfterProperty** (``bool``) +.. _ObjCSpaceAfterProperty: + +**ObjCSpaceAfterProperty** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ ` Add a space after ``@property`` in Objective-C, i.e. use ``@property (readonly)`` instead of ``@property(readonly)``. -**ObjCSpaceBeforeProtocolList** (``bool``) +.. _ObjCSpaceBeforeProtocolList: + +**ObjCSpaceBeforeProtocolList** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ ` Add a space in front of an Objective-C protocol list, i.e. use ``Foo `` instead of ``Foo``. -**PPIndentWidth** (``int``) +.. _PPIndentWidth: + +**PPIndentWidth** (``Integer``) :versionbadge:`clang-format 13` :ref:`¶ ` The number of columns to use for indentation of preprocessor statements. When set to -1 (default) ``IndentWidth`` is used also for preprocessor statements. @@ -3144,36 +3864,116 @@ the configuration (without a prefix: ``Auto``). # define BAR #endif -**PenaltyBreakAssignment** (``unsigned``) +.. _PackConstructorInitializers: + +**PackConstructorInitializers** (``PackConstructorInitializersStyle``) :versionbadge:`clang-format 14` :ref:`¶ ` + The pack constructor initializers style to use. + + Possible values: + + * ``PCIS_Never`` (in configuration: ``Never``) + Always put each constructor initializer on its own line. + + .. code-block:: c++ + + Constructor() + : a(), + b() + + * ``PCIS_BinPack`` (in configuration: ``BinPack``) + Bin-pack constructor initializers. + + .. code-block:: c++ + + Constructor() + : aaaaaaaaaaaaaaaaaaaa(), bbbbbbbbbbbbbbbbbbbb(), + cccccccccccccccccccc() + + * ``PCIS_CurrentLine`` (in configuration: ``CurrentLine``) + Put all constructor initializers on the current line if they fit. + Otherwise, put each one on its own line. + + .. code-block:: c++ + + Constructor() : a(), b() + + Constructor() + : aaaaaaaaaaaaaaaaaaaa(), + bbbbbbbbbbbbbbbbbbbb(), + ddddddddddddd() + + * ``PCIS_NextLine`` (in configuration: ``NextLine``) + Same as ``PCIS_CurrentLine`` except that if all constructor initializers + do not fit on the current line, try to fit them on the next line. + + .. code-block:: c++ + + Constructor() : a(), b() + + Constructor() + : aaaaaaaaaaaaaaaaaaaa(), bbbbbbbbbbbbbbbbbbbb(), ddddddddddddd() + + Constructor() + : aaaaaaaaaaaaaaaaaaaa(), + bbbbbbbbbbbbbbbbbbbb(), + cccccccccccccccccccc() + + + +.. _PenaltyBreakAssignment: + +**PenaltyBreakAssignment** (``Unsigned``) :versionbadge:`clang-format 5` :ref:`¶ ` The penalty for breaking around an assignment operator. -**PenaltyBreakBeforeFirstCallParameter** (``unsigned``) +.. _PenaltyBreakBeforeFirstCallParameter: + +**PenaltyBreakBeforeFirstCallParameter** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ ` The penalty for breaking a function call after ``call(``. -**PenaltyBreakComment** (``unsigned``) +.. _PenaltyBreakComment: + +**PenaltyBreakComment** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ ` The penalty for each line break introduced inside a comment. -**PenaltyBreakFirstLessLess** (``unsigned``) +.. _PenaltyBreakFirstLessLess: + +**PenaltyBreakFirstLessLess** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ ` The penalty for breaking before the first ``<<``. -**PenaltyBreakString** (``unsigned``) +.. _PenaltyBreakOpenParenthesis: + +**PenaltyBreakOpenParenthesis** (``Unsigned``) :versionbadge:`clang-format 14` :ref:`¶ ` + The penalty for breaking after ``(``. + +.. _PenaltyBreakString: + +**PenaltyBreakString** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ ` The penalty for each line break introduced inside a string literal. -**PenaltyBreakTemplateDeclaration** (``unsigned``) +.. _PenaltyBreakTemplateDeclaration: + +**PenaltyBreakTemplateDeclaration** (``Unsigned``) :versionbadge:`clang-format 7` :ref:`¶ ` The penalty for breaking after template declaration. -**PenaltyExcessCharacter** (``unsigned``) +.. _PenaltyExcessCharacter: + +**PenaltyExcessCharacter** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ ` The penalty for each character outside of the column limit. -**PenaltyIndentedWhitespace** (``unsigned``) +.. _PenaltyIndentedWhitespace: + +**PenaltyIndentedWhitespace** (``Unsigned``) :versionbadge:`clang-format 12` :ref:`¶ ` Penalty for each character of whitespace indentation (counted relative to leading non-whitespace column). -**PenaltyReturnTypeOnItsOwnLine** (``unsigned``) - Penalty for putting the return type of a function onto its own - line. +.. _PenaltyReturnTypeOnItsOwnLine: -**PointerAlignment** (``PointerAlignmentStyle``) +**PenaltyReturnTypeOnItsOwnLine** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ ` + Penalty for putting the return type of a function onto its own line. + +.. _PointerAlignment: + +**PointerAlignment** (``PointerAlignmentStyle``) :versionbadge:`clang-format 3.7` :ref:`¶ ` Pointer and reference alignment style. Possible values: @@ -3201,7 +4001,91 @@ the configuration (without a prefix: ``Auto``). -**RawStringFormats** (``std::vector``) +.. _QualifierAlignment: + +**QualifierAlignment** (``QualifierAlignmentStyle``) :versionbadge:`clang-format 14` :ref:`¶ ` + Different ways to arrange specifiers and qualifiers (e.g. const/volatile). + + .. warning:: + + Setting ``QualifierAlignment`` to something other than `Leave`, COULD + lead to incorrect code formatting due to incorrect decisions made due to + clang-formats lack of complete semantic information. + As such extra care should be taken to review code changes made by the use + of this option. + + Possible values: + + * ``QAS_Leave`` (in configuration: ``Leave``) + Don't change specifiers/qualifiers to either Left or Right alignment + (default). + + .. code-block:: c++ + + int const a; + const int *a; + + * ``QAS_Left`` (in configuration: ``Left``) + Change specifiers/qualifiers to be left-aligned. + + .. code-block:: c++ + + const int a; + const int *a; + + * ``QAS_Right`` (in configuration: ``Right``) + Change specifiers/qualifiers to be right-aligned. + + .. code-block:: c++ + + int const a; + int const *a; + + * ``QAS_Custom`` (in configuration: ``Custom``) + Change specifiers/qualifiers to be aligned based on ``QualifierOrder``. + With: + + .. code-block:: yaml + + QualifierOrder: ['inline', 'static', 'type', 'const'] + + + .. code-block:: c++ + + + int const a; + int const *a; + + + +.. _QualifierOrder: + +**QualifierOrder** (``List of Strings``) :versionbadge:`clang-format 14` :ref:`¶ ` + The order in which the qualifiers appear. + Order is an array that can contain any of the following: + + * const + * inline + * static + * friend + * constexpr + * volatile + * restrict + * type + + Note: it MUST contain 'type'. + Items to the left of 'type' will be placed to the left of the type and + aligned in the order supplied. Items to the right of 'type' will be placed + to the right of the type and aligned in the order supplied. + + + .. code-block:: yaml + + QualifierOrder: ['inline', 'static', 'type', 'const', 'volatile' ] + +.. _RawStringFormats: + +**RawStringFormats** (``List of RawStringFormats``) :versionbadge:`clang-format 6` :ref:`¶ ` Defines hints for detecting supported languages code blocks in raw strings. @@ -3239,7 +4123,9 @@ the configuration (without a prefix: ``Auto``). BasedOnStyle: llvm CanonicalDelimiter: 'cc' -**ReferenceAlignment** (``ReferenceAlignmentStyle``) +.. _ReferenceAlignment: + +**ReferenceAlignment** (``ReferenceAlignmentStyle``) :versionbadge:`clang-format 13` :ref:`¶ ` Reference alignment style (overrides ``PointerAlignment`` for references). @@ -3271,8 +4157,12 @@ the configuration (without a prefix: ``Auto``). -**ReflowComments** (``bool``) - If ``true``, clang-format will attempt to re-flow comments. +.. _ReflowComments: + +**ReflowComments** (``Boolean``) :versionbadge:`clang-format 3.8` :ref:`¶ ` + If ``true``, clang-format will attempt to re-flow comments. That is it + will touch a comment and *reflow* long comments into new lines, trying to + obey the ``ColumnLimit``. .. code-block:: c++ @@ -3286,7 +4176,268 @@ the configuration (without a prefix: ``Auto``). /* second veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of * information */ -**ShortNamespaceLines** (``unsigned``) +.. _RemoveBracesLLVM: + +**RemoveBracesLLVM** (``Boolean``) :versionbadge:`clang-format 14` :ref:`¶ ` + Remove optional braces of control statements (``if``, ``else``, ``for``, + and ``while``) in C++ according to the LLVM coding style. + + .. warning:: + + This option will be renamed and expanded to support other styles. + + .. warning:: + + Setting this option to `true` could lead to incorrect code formatting due + to clang-format's lack of complete semantic information. As such, extra + care should be taken to review code changes made by this option. + + .. code-block:: c++ + + false: true: + + if (isa(D)) { vs. if (isa(D)) + handleFunctionDecl(D); handleFunctionDecl(D); + } else if (isa(D)) { else if (isa(D)) + handleVarDecl(D); handleVarDecl(D); + } + + if (isa(D)) { vs. if (isa(D)) { + for (auto *A : D.attrs()) { for (auto *A : D.attrs()) + if (shouldProcessAttr(A)) { if (shouldProcessAttr(A)) + handleAttr(A); handleAttr(A); + } } + } + } + + if (isa(D)) { vs. if (isa(D)) + for (auto *A : D.attrs()) { for (auto *A : D.attrs()) + handleAttr(A); handleAttr(A); + } + } + + if (auto *D = (T)(D)) { vs. if (auto *D = (T)(D)) { + if (shouldProcess(D)) { if (shouldProcess(D)) + handleVarDecl(D); handleVarDecl(D); + } else { else + markAsIgnored(D); markAsIgnored(D); + } } + } + + if (a) { vs. if (a) + b(); b(); + } else { else if (c) + if (c) { d(); + d(); else + } else { e(); + e(); + } + } + +.. _RemoveSemicolon: + +**RemoveSemicolon** (``Boolean``) :versionbadge:`clang-format 16` :ref:`¶ ` + Remove semicolons after the closing brace of a non-empty function. + + .. warning:: + + Setting this option to `true` could lead to incorrect code formatting due + to clang-format's lack of complete semantic information. As such, extra + care should be taken to review code changes made by this option. + + .. code-block:: c++ + + false: true: + + int max(int a, int b) { int max(int a, int b) { + return a > b ? a : b; return a > b ? a : b; + }; } + +.. _RequiresClausePosition: + +**RequiresClausePosition** (``RequiresClausePositionStyle``) :versionbadge:`clang-format 15` :ref:`¶ ` + The position of the ``requires`` clause. + + Possible values: + + * ``RCPS_OwnLine`` (in configuration: ``OwnLine``) + Always put the ``requires`` clause on its own line. + + .. code-block:: c++ + + template + requires C + struct Foo {... + + template + requires C + void bar(T t) {... + + template + void baz(T t) + requires C + {... + + * ``RCPS_WithPreceding`` (in configuration: ``WithPreceding``) + Try to put the clause together with the preceding part of a declaration. + For class templates: stick to the template declaration. + For function templates: stick to the template declaration. + For function declaration followed by a requires clause: stick to the + parameter list. + + .. code-block:: c++ + + template requires C + struct Foo {... + + template requires C + void bar(T t) {... + + template + void baz(T t) requires C + {... + + * ``RCPS_WithFollowing`` (in configuration: ``WithFollowing``) + Try to put the ``requires`` clause together with the class or function + declaration. + + .. code-block:: c++ + + template + requires C struct Foo {... + + template + requires C void bar(T t) {... + + template + void baz(T t) + requires C {... + + * ``RCPS_SingleLine`` (in configuration: ``SingleLine``) + Try to put everything in the same line if possible. Otherwise normal + line breaking rules take over. + + .. code-block:: c++ + + // Fitting: + template requires C struct Foo {... + + template requires C void bar(T t) {... + + template void bar(T t) requires C {... + + // Not fitting, one possible example: + template + requires C + struct Foo {... + + template + requires C + void bar(LongName ln) { + + template + void bar(LongName ln) + requires C { + + + +.. _RequiresExpressionIndentation: + +**RequiresExpressionIndentation** (``RequiresExpressionIndentationKind``) :versionbadge:`clang-format 16` :ref:`¶ ` + The indentation used for requires expression bodies. + + Possible values: + + * ``REI_OuterScope`` (in configuration: ``OuterScope``) + Align requires expression body relative to the indentation level of the + outer scope the requires expression resides in. + This is the default. + + .. code-block:: c++ + + template + concept C = requires(T t) { + ... + } + + * ``REI_Keyword`` (in configuration: ``Keyword``) + Align requires expression body relative to the `requires` keyword. + + .. code-block:: c++ + + template + concept C = requires(T t) { + ... + } + + + +.. _SeparateDefinitionBlocks: + +**SeparateDefinitionBlocks** (``SeparateDefinitionStyle``) :versionbadge:`clang-format 14` :ref:`¶ ` + Specifies the use of empty lines to separate definition blocks, including + classes, structs, enums, and functions. + + .. code-block:: c++ + + Never v.s. Always + #include #include + struct Foo { + int a, b, c; struct Foo { + }; int a, b, c; + namespace Ns { }; + class Bar { + public: namespace Ns { + struct Foobar { class Bar { + int a; public: + int b; struct Foobar { + }; int a; + private: int b; + int t; }; + int method1() { + // ... private: + } int t; + enum List { + ITEM1, int method1() { + ITEM2 // ... + }; } + template + int method2(T x) { enum List { + // ... ITEM1, + } ITEM2 + int i, j, k; }; + int method3(int par) { + // ... template + } int method2(T x) { + }; // ... + class C {}; } + } + int i, j, k; + + int method3(int par) { + // ... + } + }; + + class C {}; + } + + Possible values: + + * ``SDS_Leave`` (in configuration: ``Leave``) + Leave definition blocks as they are. + + * ``SDS_Always`` (in configuration: ``Always``) + Insert an empty line between definition blocks. + + * ``SDS_Never`` (in configuration: ``Never``) + Remove any empty line between definition blocks. + + + +.. _ShortNamespaceLines: + +**ShortNamespaceLines** (``Unsigned``) :versionbadge:`clang-format 13` :ref:`¶ ` The maximal number of unwrapped lines that a short namespace spans. Defaults to 1. @@ -3308,7 +4459,9 @@ the configuration (without a prefix: ``Auto``). int bar; int bar; } // namespace b } // namespace b -**SortIncludes** (``SortIncludesOptions``) +.. _SortIncludes: + +**SortIncludes** (``SortIncludesOptions``) :versionbadge:`clang-format 3.8` :ref:`¶ ` Controls if and how clang-format will sort ``#includes``. If ``Never``, includes are never sorted. If ``CaseInsensitive``, includes are sorted in an ASCIIbetical or case @@ -3353,7 +4506,9 @@ the configuration (without a prefix: ``Auto``). -**SortJavaStaticImport** (``SortJavaStaticImportOptions``) +.. _SortJavaStaticImport: + +**SortJavaStaticImport** (``SortJavaStaticImportOptions``) :versionbadge:`clang-format 12` :ref:`¶ ` When sorting Java imports, by default static imports are placed before non-static imports. If ``JavaStaticImportAfterImport`` is ``After``, static imports are placed after non-static imports. @@ -3380,24 +4535,60 @@ the configuration (without a prefix: ``Auto``). -**SortUsingDeclarations** (``bool``) - If ``true``, clang-format will sort using declarations. +.. _SortUsingDeclarations: - The order of using declarations is defined as follows: - Split the strings by "::" and discard any initial empty strings. The last - element of each list is a non-namespace name; all others are namespace - names. Sort the lists of names lexicographically, where the sort order of - individual names is that all non-namespace names come before all namespace - names, and within those groups, names are in case-insensitive - lexicographic order. +**SortUsingDeclarations** (``SortUsingDeclarationsOptions``) :versionbadge:`clang-format 5` :ref:`¶ ` + Controls if and how clang-format will sort using declarations. - .. code-block:: c++ + Possible values: - false: true: - using std::cout; vs. using std::cin; - using std::cin; using std::cout; + * ``SUD_Never`` (in configuration: ``Never``) + Using declarations are never sorted. + + .. code-block:: c++ + + using std::chrono::duration_cast; + using std::move; + using boost::regex; + using boost::regex_constants::icase; + using std::string; + + * ``SUD_Lexicographic`` (in configuration: ``Lexicographic``) + Using declarations are sorted in the order defined as follows: + Split the strings by "::" and discard any initial empty strings. Sort + the lists of names lexicographically, and within those groups, names are + in case-insensitive lexicographic order. + + .. code-block:: c++ -**SpaceAfterCStyleCast** (``bool``) + using boost::regex; + using boost::regex_constants::icase; + using std::chrono::duration_cast; + using std::move; + using std::string; + + * ``SUD_LexicographicNumeric`` (in configuration: ``LexicographicNumeric``) + Using declarations are sorted in the order defined as follows: + Split the strings by "::" and discard any initial empty strings. The + last element of each list is a non-namespace name; all others are + namespace names. Sort the lists of names lexicographically, where the + sort order of individual names is that all non-namespace names come + before all namespace names, and within those groups, names are in + case-insensitive lexicographic order. + + .. code-block:: c++ + + using boost::regex; + using boost::regex_constants::icase; + using std::move; + using std::string; + using std::chrono::duration_cast; + + + +.. _SpaceAfterCStyleCast: + +**SpaceAfterCStyleCast** (``Boolean``) :versionbadge:`clang-format 3.5` :ref:`¶ ` If ``true``, a space is inserted after C style casts. .. code-block:: c++ @@ -3405,7 +4596,9 @@ the configuration (without a prefix: ``Auto``). true: false: (int) i; vs. (int)i; -**SpaceAfterLogicalNot** (``bool``) +.. _SpaceAfterLogicalNot: + +**SpaceAfterLogicalNot** (``Boolean``) :versionbadge:`clang-format 9` :ref:`¶ ` If ``true``, a space is inserted after the logical not operator (``!``). .. code-block:: c++ @@ -3413,7 +4606,9 @@ the configuration (without a prefix: ``Auto``). true: false: ! someExpression(); vs. !someExpression(); -**SpaceAfterTemplateKeyword** (``bool``) +.. _SpaceAfterTemplateKeyword: + +**SpaceAfterTemplateKeyword** (``Boolean``) :versionbadge:`clang-format 4` :ref:`¶ ` If ``true``, a space will be inserted after the 'template' keyword. .. code-block:: c++ @@ -3421,7 +4616,9 @@ the configuration (without a prefix: ``Auto``). true: false: template void foo(); vs. template void foo(); -**SpaceAroundPointerQualifiers** (``SpaceAroundPointerQualifiersStyle``) +.. _SpaceAroundPointerQualifiers: + +**SpaceAroundPointerQualifiers** (``SpaceAroundPointerQualifiersStyle``) :versionbadge:`clang-format 12` :ref:`¶ ` Defines in which cases to put a space before or after pointer qualifiers Possible values: @@ -3461,7 +4658,9 @@ the configuration (without a prefix: ``Auto``). -**SpaceBeforeAssignmentOperators** (``bool``) +.. _SpaceBeforeAssignmentOperators: + +**SpaceBeforeAssignmentOperators** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ ` If ``false``, spaces will be removed before assignment operators. .. code-block:: c++ @@ -3470,7 +4669,9 @@ the configuration (without a prefix: ``Auto``). int a = 5; vs. int a= 5; a += 42; a+= 42; -**SpaceBeforeCaseColon** (``bool``) +.. _SpaceBeforeCaseColon: + +**SpaceBeforeCaseColon** (``Boolean``) :versionbadge:`clang-format 12` :ref:`¶ ` If ``false``, spaces will be removed before case colon. .. code-block:: c++ @@ -3480,7 +4681,9 @@ the configuration (without a prefix: ``Auto``). case 1 : break; case 1: break; } } -**SpaceBeforeCpp11BracedList** (``bool``) +.. _SpaceBeforeCpp11BracedList: + +**SpaceBeforeCpp11BracedList** (``Boolean``) :versionbadge:`clang-format 7` :ref:`¶ ` If ``true``, a space will be inserted before a C++11 braced list used to initialize an object (after the preceding identifier or type). @@ -3492,7 +4695,9 @@ the configuration (without a prefix: ``Auto``). vector { 1, 2, 3 }; vector{ 1, 2, 3 }; new int[3] { 1, 2, 3 }; new int[3]{ 1, 2, 3 }; -**SpaceBeforeCtorInitializerColon** (``bool``) +.. _SpaceBeforeCtorInitializerColon: + +**SpaceBeforeCtorInitializerColon** (``Boolean``) :versionbadge:`clang-format 7` :ref:`¶ ` If ``false``, spaces will be removed before constructor initializer colon. @@ -3501,7 +4706,9 @@ the configuration (without a prefix: ``Auto``). true: false: Foo::Foo() : a(a) {} Foo::Foo(): a(a) {} -**SpaceBeforeInheritanceColon** (``bool``) +.. _SpaceBeforeInheritanceColon: + +**SpaceBeforeInheritanceColon** (``Boolean``) :versionbadge:`clang-format 7` :ref:`¶ ` If ``false``, spaces will be removed before inheritance colon. .. code-block:: c++ @@ -3509,7 +4716,9 @@ the configuration (without a prefix: ``Auto``). true: false: class Foo : Bar {} vs. class Foo: Bar {} -**SpaceBeforeParens** (``SpaceBeforeParensOptions``) +.. _SpaceBeforeParens: + +**SpaceBeforeParens** (``SpaceBeforeParensStyle``) :versionbadge:`clang-format 3.5` :ref:`¶ ` Defines in which cases to put a space before opening parentheses. Possible values: @@ -3542,7 +4751,7 @@ the configuration (without a prefix: ``Auto``). ForEach and If macros. This is useful in projects where ForEach/If macros are treated as function calls instead of control statements. ``SBPO_ControlStatementsExceptForEachMacros`` remains an alias for - backward compatability. + backward compatibility. .. code-block:: c++ @@ -3579,9 +4788,124 @@ the configuration (without a prefix: ``Auto``). } } + * ``SBPO_Custom`` (in configuration: ``Custom``) + Configure each individual space before parentheses in + `SpaceBeforeParensOptions`. + + + +.. _SpaceBeforeParensOptions: + +**SpaceBeforeParensOptions** (``SpaceBeforeParensCustom``) :versionbadge:`clang-format 14` :ref:`¶ ` + Control of individual space before parentheses. + + If ``SpaceBeforeParens`` is set to ``Custom``, use this to specify + how each individual space before parentheses case should be handled. + Otherwise, this is ignored. + + .. code-block:: yaml + + # Example of usage: + SpaceBeforeParens: Custom + SpaceBeforeParensOptions: + AfterControlStatements: true + AfterFunctionDefinitionName: true + + Nested configuration flags: + + Precise control over the spacing before parentheses. + + .. code-block:: c++ + + # Should be declared this way: + SpaceBeforeParens: Custom + SpaceBeforeParensOptions: + AfterControlStatements: true + AfterFunctionDefinitionName: true + + * ``bool AfterControlStatements`` If ``true``, put space betwee control statement keywords + (for/if/while...) and opening parentheses. + + .. code-block:: c++ + + true: false: + if (...) {} vs. if(...) {} + + * ``bool AfterForeachMacros`` If ``true``, put space between foreach macros and opening parentheses. + + .. code-block:: c++ + + true: false: + FOREACH (...) vs. FOREACH(...) + + * ``bool AfterFunctionDeclarationName`` If ``true``, put a space between function declaration name and opening + parentheses. -**SpaceBeforeRangeBasedForLoopColon** (``bool``) + .. code-block:: c++ + + true: false: + void f (); vs. void f(); + + * ``bool AfterFunctionDefinitionName`` If ``true``, put a space between function definition name and opening + parentheses. + + .. code-block:: c++ + + true: false: + void f () {} vs. void f() {} + + * ``bool AfterIfMacros`` If ``true``, put space between if macros and opening parentheses. + + .. code-block:: c++ + + true: false: + IF (...) vs. IF(...) + + + * ``bool AfterOverloadedOperator`` If ``true``, put a space between operator overloading and opening + parentheses. + + .. code-block:: c++ + + true: false: + void operator++ (int a); vs. void operator++(int a); + object.operator++ (10); object.operator++(10); + + * ``bool AfterRequiresInClause`` If ``true``, put space between requires keyword in a requires clause and + opening parentheses, if there is one. + + .. code-block:: c++ + + true: false: + template vs. template + requires (A && B) requires(A && B) + ... ... + + * ``bool AfterRequiresInExpression`` If ``true``, put space between requires keyword in a requires expression + and opening parentheses. + + .. code-block:: c++ + + true: false: + template vs. template + concept C = requires (T t) { concept C = requires(T t) { + ... ... + } } + + * ``bool BeforeNonEmptyParentheses`` If ``true``, put a space before opening parentheses only if the + parentheses are not empty. + + .. code-block:: c++ + + true: false: + void f (int a); vs. void f(); + f (a); f(); + + +.. _SpaceBeforeRangeBasedForLoopColon: + +**SpaceBeforeRangeBasedForLoopColon** (``Boolean``) :versionbadge:`clang-format 7` :ref:`¶ ` If ``false``, spaces will be removed before range-based for loop colon. @@ -3590,7 +4914,9 @@ the configuration (without a prefix: ``Auto``). true: false: for (auto v : values) {} vs. for(auto v: values) {} -**SpaceBeforeSquareBrackets** (``bool``) +.. _SpaceBeforeSquareBrackets: + +**SpaceBeforeSquareBrackets** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ ` If ``true``, spaces will be before ``[``. Lambdas will not be affected. Only the first ``[`` will get a space added. @@ -3600,7 +4926,9 @@ the configuration (without a prefix: ``Auto``). int a [5]; vs. int a[5]; int a [5][5]; vs. int a[5][5]; -**SpaceInEmptyBlock** (``bool``) +.. _SpaceInEmptyBlock: + +**SpaceInEmptyBlock** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ ` If ``true``, spaces will be inserted into ``{}``. .. code-block:: c++ @@ -3609,7 +4937,9 @@ the configuration (without a prefix: ``Auto``). void f() { } vs. void f() {} while (true) { } while (true) {} -**SpaceInEmptyParentheses** (``bool``) +.. _SpaceInEmptyParentheses: + +**SpaceInEmptyParentheses** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ ` If ``true``, spaces may be inserted into ``()``. .. code-block:: c++ @@ -3622,7 +4952,9 @@ the configuration (without a prefix: ``Auto``). } } } } -**SpacesBeforeTrailingComments** (``unsigned``) +.. _SpacesBeforeTrailingComments: + +**SpacesBeforeTrailingComments** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ ` The number of spaces before trailing line comments (``//`` - comments). @@ -3639,7 +4971,9 @@ the configuration (without a prefix: ``Auto``). } // foo } -**SpacesInAngles** (``SpacesInAnglesStyle``) +.. _SpacesInAngles: + +**SpacesInAngles** (``SpacesInAnglesStyle``) :versionbadge:`clang-format 3.4` :ref:`¶ ` The SpacesInAnglesStyle to use for template argument lists. Possible values: @@ -3666,7 +5000,9 @@ the configuration (without a prefix: ``Auto``). -**SpacesInCStyleCastParentheses** (``bool``) +.. _SpacesInCStyleCastParentheses: + +**SpacesInCStyleCastParentheses** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ ` If ``true``, spaces may be inserted into C style casts. .. code-block:: c++ @@ -3674,7 +5010,9 @@ the configuration (without a prefix: ``Auto``). true: false: x = ( int32 )y vs. x = (int32)y -**SpacesInConditionalStatement** (``bool``) +.. _SpacesInConditionalStatement: + +**SpacesInConditionalStatement** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ ` If ``true``, spaces will be inserted around if/for/switch/while conditions. @@ -3684,7 +5022,9 @@ the configuration (without a prefix: ``Auto``). if ( a ) { ... } vs. if (a) { ... } while ( i < 5 ) { ... } while (i < 5) { ... } -**SpacesInContainerLiterals** (``bool``) +.. _SpacesInContainerLiterals: + +**SpacesInContainerLiterals** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ ` If ``true``, spaces are inserted inside container literals (e.g. ObjC and Javascript array and dict literals). @@ -3694,44 +5034,55 @@ the configuration (without a prefix: ``Auto``). var arr = [ 1, 2, 3 ]; vs. var arr = [1, 2, 3]; f({a : 1, b : 2, c : 3}); f({a: 1, b: 2, c: 3}); -**SpacesInLineCommentPrefix** (``SpacesInLineComment``) +.. _SpacesInLineCommentPrefix: + +**SpacesInLineCommentPrefix** (``SpacesInLineComment``) :versionbadge:`clang-format 13` :ref:`¶ ` How many spaces are allowed at the start of a line comment. To disable the maximum set it to ``-1``, apart from that the maximum takes precedence over the minimum. - Minimum = 1 Maximum = -1 - // One space is forced - // but more spaces are possible + .. code-block:: c++ + + Minimum = 1 + Maximum = -1 + // One space is forced + + // but more spaces are possible - Minimum = 0 - Maximum = 0 - //Forces to start every comment directly after the slashes + Minimum = 0 + Maximum = 0 + //Forces to start every comment directly after the slashes Note that in line comment sections the relative indent of the subsequent lines is kept, that means the following: .. code-block:: c++ - before: after: - Minimum: 1 - //if (b) { // if (b) { - // return true; // return true; - //} // } + before: after: + Minimum: 1 + //if (b) { // if (b) { + // return true; // return true; + //} // } - Maximum: 0 - /// List: ///List: - /// - Foo /// - Foo - /// - Bar /// - Bar + Maximum: 0 + /// List: ///List: + /// - Foo /// - Foo + /// - Bar /// - Bar + + This option has only effect if ``ReflowComments`` is set to ``true``. Nested configuration flags: + Control of spaces within a single line comment. * ``unsigned Minimum`` The minimum number of spaces at the start of the comment. * ``unsigned Maximum`` The maximum number of spaces at the start of the comment. -**SpacesInParentheses** (``bool``) +.. _SpacesInParentheses: + +**SpacesInParentheses** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ ` If ``true``, spaces will be inserted after ``(`` and before ``)``. .. code-block:: c++ @@ -3739,7 +5090,9 @@ the configuration (without a prefix: ``Auto``). true: false: t f( Deleted & ) & = delete; vs. t f(Deleted &) & = delete; -**SpacesInSquareBrackets** (``bool``) +.. _SpacesInSquareBrackets: + +**SpacesInSquareBrackets** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ ` If ``true``, spaces will be inserted after ``[`` and before ``]``. Lambdas without arguments or unspecified size array declarations will not be affected. @@ -3750,7 +5103,9 @@ the configuration (without a prefix: ``Auto``). int a[ 5 ]; vs. int a[5]; std::unique_ptr foo() {} // Won't be affected -**Standard** (``LanguageStandard``) +.. _Standard: + +**Standard** (``LanguageStandard``) :versionbadge:`clang-format 3.7` :ref:`¶ ` Parse and format C++ constructs compatible with this standard. .. code-block:: c++ @@ -3785,7 +5140,9 @@ the configuration (without a prefix: ``Auto``). -**StatementAttributeLikeMacros** (``std::vector``) +.. _StatementAttributeLikeMacros: + +**StatementAttributeLikeMacros** (``List of Strings``) :versionbadge:`clang-format 12` :ref:`¶ ` Macros which are ignored in front of a statement, as if they were an attribute. So that they are not parsed as identifier, for example for Qts emit. @@ -3802,7 +5159,9 @@ the configuration (without a prefix: ``Auto``). unsigned char data = 'x'; emit signal(data); // Now it's fine again. -**StatementMacros** (``std::vector``) +.. _StatementMacros: + +**StatementMacros** (``List of Strings``) :versionbadge:`clang-format 8` :ref:`¶ ` A vector of macros that should be interpreted as complete statements. @@ -3812,10 +5171,14 @@ the configuration (without a prefix: ``Auto``). For example: Q_UNUSED -**TabWidth** (``unsigned``) +.. _TabWidth: + +**TabWidth** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ ` The number of columns used for tab stops. -**TypenameMacros** (``std::vector``) +.. _TypenameMacros: + +**TypenameMacros** (``List of Strings``) :versionbadge:`clang-format 9` :ref:`¶ ` A vector of macros that should be interpreted as type declarations instead of as function calls. @@ -3833,11 +5196,14 @@ the configuration (without a prefix: ``Auto``). For example: OpenSSL STACK_OF, BSD LIST_ENTRY. -**UseCRLF** (``bool``) - Use ``\r\n`` instead of ``\n`` for line breaks. - Also used as fallback if ``DeriveLineEnding`` is true. +.. _UseCRLF: -**UseTab** (``UseTabStyle``) +**UseCRLF** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ ` + This option is **deprecated**. See ``LF`` and ``CRLF`` of ``LineEnding``. + +.. _UseTab: + +**UseTab** (``UseTabStyle``) :versionbadge:`clang-format 3.7` :ref:`¶ ` The way to use tab characters in the resulting file. Possible values: @@ -3862,7 +5228,9 @@ the configuration (without a prefix: ``Auto``). -**WhitespaceSensitiveMacros** (``std::vector``) +.. _WhitespaceSensitiveMacros: + +**WhitespaceSensitiveMacros** (``List of Strings``) :versionbadge:`clang-format 11` :ref:`¶ ` A vector of macros which are whitespace-sensitive and should not be touched. diff --git a/gnu/llvm/clang/docs/ClangFormattedStatus.rst b/gnu/llvm/clang/docs/ClangFormattedStatus.rst index beca555ebc0..6f62c97f85b 100644 --- a/gnu/llvm/clang/docs/ClangFormattedStatus.rst +++ b/gnu/llvm/clang/docs/ClangFormattedStatus.rst @@ -1,10 +1,10 @@ .. raw:: html .. role:: none @@ -17,7 +17,7 @@ Clang Formatted Status ====================== :doc:`ClangFormattedStatus` describes the state of LLVM source -tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 (`e42ee2d50963 `_). +tree in terms of conformance to :doc:`ClangFormat` as of: March 06, 2022 17:32:26 (`830ba4cebe79 `_). .. list-table:: LLVM Clang-Format Status @@ -29,7 +29,102 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - Formatted Files - Unformatted Files - % Complete - * - . + * - bolt/include/bolt/Core + - `15` + - `10` + - `5` + - :part:`66%` + * - bolt/include/bolt/Passes + - `47` + - `47` + - `0` + - :good:`100%` + * - bolt/include/bolt/Profile + - `8` + - `8` + - `0` + - :good:`100%` + * - bolt/include/bolt/Rewrite + - `5` + - `4` + - `1` + - :part:`80%` + * - bolt/include/bolt/RuntimeLibs + - `3` + - `3` + - `0` + - :good:`100%` + * - bolt/include/bolt/Utils + - `4` + - `4` + - `0` + - :good:`100%` + * - bolt/lib/Core + - `14` + - `5` + - `9` + - :part:`35%` + * - bolt/lib/Passes + - `45` + - `21` + - `24` + - :part:`46%` + * - bolt/lib/Profile + - `7` + - `3` + - `4` + - :part:`42%` + * - bolt/lib/Rewrite + - `6` + - `0` + - `6` + - :none:`0%` + * - bolt/lib/RuntimeLibs + - `3` + - `3` + - `0` + - :good:`100%` + * - bolt/lib/Target/AArch64 + - `1` + - `0` + - `1` + - :none:`0%` + * - bolt/lib/Target/X86 + - `1` + - `0` + - `1` + - :none:`0%` + * - bolt/lib/Utils + - `2` + - `1` + - `1` + - :part:`50%` + * - bolt/runtime + - `3` + - `0` + - `3` + - :none:`0%` + * - bolt/tools/driver + - `1` + - `0` + - `1` + - :none:`0%` + * - bolt/tools/heatmap + - `1` + - `1` + - `0` + - :good:`100%` + * - bolt/tools/llvm-bolt-fuzzer + - `1` + - `1` + - `0` + - :good:`100%` + * - bolt/tools/merge-fdata + - `1` + - `0` + - `1` + - :none:`0%` + * - bolt/unittests/Core - `1` - `1` - `0` @@ -59,11 +154,11 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` - * - clang/examples/clang-interpreter + * - clang/examples/PluginsOrder - `1` - - `0` - `1` - - :none:`0%` + - `0` + - :good:`100%` * - clang/examples/PrintFunctionNames - `1` - `0` @@ -85,10 +180,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `2` - :none:`0%` * - clang/include/clang/Analysis/FlowSensitive - - `2` - - `1` + - `16` + - `15` - `1` - - :part:`50%` + - :part:`93%` * - clang/include/clang/Analysis/Support - `1` - `0` @@ -106,9 +201,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :none:`0%` * - clang/include/clang/AST - `114` - - `21` - - `93` - - :part:`18%` + - `20` + - `94` + - :part:`17%` * - clang/include/clang/ASTMatchers - `5` - `1` @@ -120,10 +215,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `3` - :part:`25%` * - clang/include/clang/Basic - - `80` - - `30` + - `82` + - `32` - `50` - - :part:`37%` + - :part:`39%` * - clang/include/clang/CodeGen - `9` - `0` @@ -141,9 +236,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - clang/include/clang/Driver - `17` - - `5` - - `12` - - :part:`29%` + - `4` + - `13` + - :part:`23%` * - clang/include/clang/Edit - `5` - `1` @@ -181,9 +276,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - clang/include/clang/Lex - `29` - - `5` - - `24` - - :part:`17%` + - `6` + - `23` + - :part:`20%` * - clang/include/clang/Parse - `5` - `2` @@ -225,9 +320,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `3` - :part:`25%` * - clang/include/clang/StaticAnalyzer/Core/PathSensitive - - `36` + - `37` - `10` - - `26` + - `27` - :part:`27%` * - clang/include/clang/StaticAnalyzer/Frontend - `5` @@ -256,14 +351,14 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :none:`0%` * - clang/include/clang/Tooling/DependencyScanning - `5` - - `4` - - `1` - - :part:`80%` + - `5` + - `0` + - :good:`100%` * - clang/include/clang/Tooling/Inclusions - - `2` - - `1` - - `1` - - :part:`50%` + - `3` + - `3` + - `0` + - :good:`100%` * - clang/include/clang/Tooling/Refactoring - `15` - `12` @@ -271,9 +366,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :part:`80%` * - clang/include/clang/Tooling/Refactoring/Extract - `2` - - `1` - - `1` - - :part:`50%` + - `2` + - `0` + - :good:`100%` * - clang/include/clang/Tooling/Refactoring/Rename - `6` - `5` @@ -284,6 +379,11 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `5` - `0` - :good:`100%` + * - clang/include/clang/Tooling/Syntax/Pseudo + - `5` + - `5` + - `0` + - :good:`100%` * - clang/include/clang/Tooling/Transformer - `8` - `6` @@ -301,9 +401,14 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :none:`0%` * - clang/lib/Analysis - `28` - - `4` - - `24` - - :part:`14%` + - `3` + - `25` + - :part:`10%` + * - clang/lib/Analysis/FlowSensitive + - `7` + - `7` + - `0` + - :good:`100%` * - clang/lib/Analysis/plugins/CheckerDependencyHandling - `1` - `1` @@ -330,9 +435,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `22` - :none:`0%` * - clang/lib/AST - - `80` + - `81` - `2` - - `78` + - `79` - :part:`2%` * - clang/lib/AST/Interp - `44` @@ -350,20 +455,20 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `5` - :part:`16%` * - clang/lib/Basic - - `37` - - `12` - - `25` - - :part:`32%` + - `39` + - `13` + - `26` + - :part:`33%` * - clang/lib/Basic/Targets - `50` - - `24` - - `26` - - :part:`48%` + - `25` + - `25` + - :part:`50%` * - clang/lib/CodeGen - - `91` - - `12` - - `79` - - :part:`13%` + - `87` + - `9` + - `78` + - :part:`10%` * - clang/lib/CrossTU - `1` - `0` @@ -395,40 +500,35 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - :none:`0%` * - clang/lib/Driver - - `16` - - `3` - - `13` - - :part:`18%` + - `14` + - `2` + - `12` + - :part:`14%` * - clang/lib/Driver/ToolChains - - `87` - - `31` - - `56` - - :part:`35%` + - `94` + - `41` + - `53` + - :part:`43%` * - clang/lib/Driver/ToolChains/Arch - `20` - - `6` - - `14` - - :part:`30%` + - `7` + - `13` + - :part:`35%` * - clang/lib/Edit - `3` - `0` - `3` - :none:`0%` * - clang/lib/Format - - `31` - - `31` + - `35` + - `35` - `0` - :good:`100%` - * - clang/lib/Format/old - - `2` - - `1` - - `1` - - :part:`50%` * - clang/lib/Frontend - `32` - - `3` - - `29` - - :part:`9%` + - `4` + - `28` + - :part:`12%` * - clang/lib/Frontend/Rewrite - `8` - `0` @@ -440,15 +540,15 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - :none:`0%` * - clang/lib/Headers - - `136` - - `12` - - `124` - - :part:`8%` + - `146` + - `14` + - `132` + - :part:`9%` * - clang/lib/Headers/openmp_wrappers - `5` - - `5` - - `0` - - :good:`100%` + - `4` + - `1` + - :part:`80%` * - clang/lib/Headers/ppc_wrappers - `7` - `2` @@ -456,9 +556,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :part:`28%` * - clang/lib/Index - `11` - - `1` - - `10` - - :part:`9%` + - `2` + - `9` + - :part:`18%` * - clang/lib/IndexSerialization - `1` - `1` @@ -470,9 +570,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - clang/lib/Lex - - `23` + - `24` - `1` - - `22` + - `23` - :part:`4%` * - clang/lib/Parse - `15` @@ -491,17 +591,17 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :part:`7%` * - clang/lib/Serialization - `17` - - `1` - - `16` - - :part:`5%` + - `2` + - `15` + - :part:`11%` * - clang/lib/StaticAnalyzer/Checkers - - `117` - - `16` - - `101` - - :part:`13%` + - `122` + - `19` + - `103` + - :part:`15%` * - clang/lib/StaticAnalyzer/Checkers/cert - - `1` - - `1` + - `2` + - `2` - `0` - :good:`100%` * - clang/lib/StaticAnalyzer/Checkers/MPI-Checker @@ -525,9 +625,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `2` - :part:`80%` * - clang/lib/StaticAnalyzer/Core - - `46` + - `47` - `10` - - `36` + - `37` - :part:`21%` * - clang/lib/StaticAnalyzer/Frontend - `8` @@ -556,17 +656,17 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :none:`0%` * - clang/lib/Tooling/DependencyScanning - `5` - - `2` - - `3` - - :part:`40%` + - `4` + - `1` + - :part:`80%` * - clang/lib/Tooling/DumpTool - `4` - `3` - `1` - :part:`75%` * - clang/lib/Tooling/Inclusions - - `2` - - `2` + - `3` + - `3` - `0` - :good:`100%` * - clang/lib/Tooling/Refactoring @@ -589,11 +689,16 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `6` - `1` - :part:`85%` - * - clang/lib/Tooling/Transformer - - `7` - - `3` + * - clang/lib/Tooling/Syntax/Pseudo + - `8` + - `8` + - `0` + - :good:`100%` + * - clang/lib/Tooling/Transformer + - `7` - `4` - - :part:`42%` + - `3` + - :part:`57%` * - clang/tools/amdgpu-arch - `1` - `1` @@ -670,6 +775,16 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `3` - :none:`0%` * - clang/tools/clang-import-test + - `1` + - `0` + - `1` + - :none:`0%` + * - clang/tools/clang-linker-wrapper + - `3` + - `2` + - `1` + - :part:`66%` + * - clang/tools/clang-nvlink-wrapper - `1` - `1` - `0` @@ -684,6 +799,11 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` + * - clang/tools/clang-pseudo + - `1` + - `1` + - `0` + - :good:`100%` * - clang/tools/clang-refactor - `4` - `4` @@ -721,9 +841,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :part:`25%` * - clang/tools/libclang - `35` - - `6` - - `29` - - :part:`17%` + - `5` + - `30` + - :part:`14%` * - clang/tools/scan-build-py/tests/functional/src/include - `1` - `1` @@ -734,11 +854,16 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `2` - `4` - :part:`33%` + * - clang/unittests/Analysis/FlowSensitive + - `14` + - `13` + - `1` + - :part:`92%` * - clang/unittests/AST - - `28` - - `6` + - `30` + - `8` - `22` - - :part:`21%` + - :part:`26%` * - clang/unittests/ASTMatchers - `6` - `3` @@ -750,10 +875,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `3` - :none:`0%` * - clang/unittests/Basic - - `7` - - `3` + - `8` - `4` - - :part:`42%` + - `4` + - :part:`50%` * - clang/unittests/CodeGen - `6` - `1` @@ -775,15 +900,15 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `4` - :part:`20%` * - clang/unittests/Format - - `21` - - `20` - - `1` - - :part:`95%` + - `24` + - `24` + - `0` + - :good:`100%` * - clang/unittests/Frontend - - `10` - - `6` + - `11` + - `7` - `4` - - :part:`60%` + - :part:`63%` * - clang/unittests/Index - `1` - `1` @@ -794,16 +919,21 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `2` - `0` - :good:`100%` + * - clang/unittests/Interpreter/ExceptionTests + - `1` + - `0` + - `1` + - :none:`0%` * - clang/unittests/Introspection - `1` - `0` - `1` - :none:`0%` * - clang/unittests/Lex - - `7` - - `3` + - `8` - `4` - - :part:`42%` + - `4` + - :part:`50%` * - clang/unittests/libclang - `2` - `0` @@ -830,30 +960,35 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - :part:`66%` * - clang/unittests/Serialization - - `1` - - `1` + - `2` + - `2` - `0` - :good:`100%` * - clang/unittests/StaticAnalyzer - - `12` - - `4` - - `8` - - :part:`33%` + - `16` + - `7` + - `9` + - :part:`43%` * - clang/unittests/Tooling - - `29` - - `8` - - `21` - - :part:`27%` + - `30` + - `10` + - `20` + - :part:`33%` * - clang/unittests/Tooling/RecursiveASTVisitorTests - `30` - - `13` - - `17` - - :part:`43%` + - `12` + - `18` + - :part:`40%` * - clang/unittests/Tooling/Syntax - `7` - `3` - `4` - :part:`42%` + * - clang/unittests/Tooling/Syntax/Pseudo + - `4` + - `4` + - `0` + - :good:`100%` * - clang/utils/perf-training/cxx - `1` - `0` @@ -861,9 +996,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :none:`0%` * - clang/utils/TableGen - `22` - - `4` - - `18` - - :part:`18%` + - `3` + - `19` + - :part:`13%` * - clang-tools-extra/clang-apply-replacements/include/clang-apply-replacements/Tooling - `1` - `1` @@ -901,9 +1036,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - clang-tools-extra/clang-include-fixer - `13` - - `7` - - `6` - - :part:`53%` + - `8` + - `5` + - :part:`61%` * - clang-tools-extra/clang-include-fixer/find-all-symbols - `17` - `13` @@ -955,15 +1090,15 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - :none:`0%` * - clang-tools-extra/clang-tidy - - `18` - - `11` - - `7` - - :part:`61%` - * - clang-tools-extra/clang-tidy/abseil - - `40` - - `28` - - `12` + - `20` + - `14` + - `6` - :part:`70%` + * - clang-tools-extra/clang-tidy/abseil + - `42` + - `31` + - `11` + - :part:`73%` * - clang-tools-extra/clang-tidy/altera - `11` - `9` @@ -980,10 +1115,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - clang-tools-extra/clang-tidy/bugprone - - `115` - - `94` - - `21` - - :part:`81%` + - `125` + - `106` + - `19` + - :part:`84%` * - clang-tools-extra/clang-tidy/cert - `29` - `28` @@ -995,8 +1130,8 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - :part:`80%` * - clang-tools-extra/clang-tidy/cppcoreguidelines - - `43` - - `40` + - `45` + - `42` - `3` - :part:`93%` * - clang-tools-extra/clang-tidy/darwin @@ -1035,25 +1170,25 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - clang-tools-extra/clang-tidy/misc - - `29` - - `25` - - `4` - - :part:`86%` + - `33` + - `30` + - `3` + - :part:`90%` * - clang-tools-extra/clang-tidy/modernize - `67` - - `49` - - `18` - - :part:`73%` + - `48` + - `19` + - :part:`71%` * - clang-tools-extra/clang-tidy/mpi - `5` - `5` - `0` - :good:`100%` * - clang-tools-extra/clang-tidy/objc - - `15` - - `10` + - `17` + - `12` - `5` - - :part:`66%` + - :part:`70%` * - clang-tools-extra/clang-tidy/openmp - `5` - `5` @@ -1075,10 +1210,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `2` - :part:`60%` * - clang-tools-extra/clang-tidy/readability - - `77` - - `63` - - `14` - - :part:`81%` + - `88` + - `76` + - `12` + - :part:`86%` * - clang-tools-extra/clang-tidy/tool - `3` - `2` @@ -1086,19 +1221,19 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :part:`66%` * - clang-tools-extra/clang-tidy/utils - `35` - - `30` - - `5` - - :part:`85%` + - `31` + - `4` + - :part:`88%` * - clang-tools-extra/clang-tidy/zircon - `3` - `3` - `0` - :good:`100%` * - clang-tools-extra/clangd - - `93` - - `79` - - `14` - - :part:`84%` + - `97` + - `81` + - `16` + - :part:`83%` * - clang-tools-extra/clangd/benchmarks - `1` - `1` @@ -1116,14 +1251,14 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - clang-tools-extra/clangd/index - `39` - - `37` - - `2` - - :part:`94%` + - `36` + - `3` + - :part:`92%` * - clang-tools-extra/clangd/index/dex - `9` - - `8` - - `1` - - :part:`88%` + - `7` + - `2` + - :part:`77%` * - clang-tools-extra/clangd/index/dex/dexp - `1` - `1` @@ -1160,30 +1295,30 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - clang-tools-extra/clangd/refactor - - `4` - - `3` + - `6` + - `5` - `1` - - :part:`75%` + - :part:`83%` * - clang-tools-extra/clangd/refactor/tweaks - `14` - - `11` - - `3` - - :part:`78%` + - `10` + - `4` + - :part:`71%` * - clang-tools-extra/clangd/support - - `23` - - `22` + - `25` + - `24` - `1` - - :part:`95%` + - :part:`96%` * - clang-tools-extra/clangd/tool - `2` - `2` - `0` - :good:`100%` * - clang-tools-extra/clangd/unittests - - `77` + - `79` - `66` - - `11` - - :part:`85%` + - `13` + - :part:`83%` * - clang-tools-extra/clangd/unittests/decision_forest_model - `1` - `1` @@ -1201,9 +1336,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - clang-tools-extra/clangd/unittests/tweaks - `20` - - `20` - - `0` - - :good:`100%` + - `19` + - `1` + - :part:`95%` * - clang-tools-extra/clangd/unittests/xpc - `1` - `1` @@ -1275,10 +1410,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `2` - :none:`0%` * - clang-tools-extra/unittests/clang-tidy - - `15` - - `6` + - `16` - `9` - - :part:`40%` + - `7` + - :part:`56%` * - clang-tools-extra/unittests/include/common - `1` - `0` @@ -1291,19 +1426,19 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :none:`0%` * - compiler-rt/include/sanitizer - `15` - - `2` - - `13` - - :part:`13%` + - `3` + - `12` + - :part:`20%` * - compiler-rt/include/xray - `3` - `2` - `1` - :part:`66%` * - compiler-rt/lib/asan - - `59` - - `3` - - `56` - - :part:`5%` + - `57` + - `5` + - `52` + - :part:`8%` * - compiler-rt/lib/asan/tests - `17` - `1` @@ -1335,15 +1470,15 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - :none:`0%` * - compiler-rt/lib/dfsan - - `13` - - `8` + - `14` + - `9` - `5` - - :part:`61%` + - :part:`64%` * - compiler-rt/lib/fuzzer - - `45` - - `7` + - `47` + - `9` - `38` - - :part:`15%` + - :part:`19%` * - compiler-rt/lib/fuzzer/afl - `1` - `0` @@ -1376,19 +1511,19 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - compiler-rt/lib/gwp_asan/tests - `15` - - `15` - - `0` - - :good:`100%` + - `14` + - `1` + - :part:`93%` * - compiler-rt/lib/gwp_asan/tests/platform_specific - `1` - `1` - `0` - :good:`100%` * - compiler-rt/lib/hwasan - - `27` - - `7` - - `20` - - :part:`25%` + - `30` + - `9` + - `21` + - :part:`30%` * - compiler-rt/lib/interception - `8` - `1` @@ -1401,14 +1536,19 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :part:`33%` * - compiler-rt/lib/lsan - `20` - - `2` - - `18` - - :part:`10%` + - `4` + - `16` + - :part:`20%` * - compiler-rt/lib/memprof - - `27` - - `26` - - `1` - - :part:`96%` + - `31` + - `29` + - `2` + - :part:`93%` + * - compiler-rt/lib/memprof/tests + - `2` + - `2` + - `0` + - :good:`100%` * - compiler-rt/lib/msan - `18` - `4` @@ -1420,15 +1560,15 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `4` - :none:`0%` * - compiler-rt/lib/orc - - `10` - - `8` - - `2` - - :part:`80%` + - `21` + - `16` + - `5` + - :part:`76%` * - compiler-rt/lib/orc/unittests - - `8` - - `7` + - `10` + - `9` - `1` - - :part:`87%` + - :part:`90%` * - compiler-rt/lib/profile - `6` - `0` @@ -1440,30 +1580,30 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `2` - :part:`33%` * - compiler-rt/lib/sanitizer_common - - `162` - - `18` - - `144` - - :part:`11%` + - `167` + - `29` + - `138` + - :part:`17%` * - compiler-rt/lib/sanitizer_common/symbolizer - `2` - `2` - `0` - :good:`100%` * - compiler-rt/lib/sanitizer_common/tests - - `39` - - `2` - - `37` - - :part:`5%` + - `46` + - `12` + - `34` + - :part:`26%` * - compiler-rt/lib/scudo - `20` - `0` - `20` - :none:`0%` * - compiler-rt/lib/scudo/standalone - - `47` - - `47` - - `0` - - :good:`100%` + - `49` + - `48` + - `1` + - :part:`97%` * - compiler-rt/lib/scudo/standalone/benchmarks - `1` - `1` @@ -1480,10 +1620,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - compiler-rt/lib/scudo/standalone/tests + - `25` - `24` - - `24` - - `0` - - :good:`100%` + - `1` + - :part:`96%` * - compiler-rt/lib/scudo/standalone/tools - `1` - `1` @@ -1510,20 +1650,25 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - :none:`0%` * - compiler-rt/lib/tsan/rtl - - `62` - - `10` - - `52` - - :part:`16%` + - `59` + - `14` + - `45` + - :part:`23%` + * - compiler-rt/lib/tsan/rtl-old + - `61` + - `13` + - `48` + - :part:`21%` * - compiler-rt/lib/tsan/tests/rtl - `10` - `0` - `10` - :none:`0%` * - compiler-rt/lib/tsan/tests/unit - - `10` - - `0` - - `10` - - :none:`0%` + - `11` + - `3` + - `8` + - :part:`27%` * - compiler-rt/lib/ubsan - `27` - `7` @@ -1535,10 +1680,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - :none:`0%` * - compiler-rt/lib/xray - - `39` + - `40` - `27` - - `12` - - :part:`69%` + - `13` + - :part:`67%` * - compiler-rt/lib/xray/tests/unit - `10` - `8` @@ -1549,69 +1694,99 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `2` - `0` - :good:`100%` - * - debuginfo-tests/dexter/feature_tests/commands/penalty + * - cross-project-tests/debuginfo-tests/clang_llvm_roundtrip + - `2` + - `1` + - `1` + - :part:`50%` + * - cross-project-tests/debuginfo-tests/dexter/feature_tests/commands/penalty + - `10` + - `0` + - `10` + - :none:`0%` + * - cross-project-tests/debuginfo-tests/dexter/feature_tests/commands/perfect - `7` - `0` - `7` - :none:`0%` - * - debuginfo-tests/dexter/feature_tests/commands/perfect - - `5` + * - cross-project-tests/debuginfo-tests/dexter/feature_tests/commands/perfect/dex_declare_address + - `7` - `0` - - `5` + - `7` - :none:`0%` - * - debuginfo-tests/dexter/feature_tests/commands/perfect/dex_declare_file/dex_and_source + * - cross-project-tests/debuginfo-tests/dexter/feature_tests/commands/perfect/dex_declare_file/dex_and_source - `1` - `1` - `0` - :good:`100%` - * - debuginfo-tests/dexter/feature_tests/commands/perfect/dex_declare_file/precompiled_binary + * - cross-project-tests/debuginfo-tests/dexter/feature_tests/commands/perfect/dex_declare_file/precompiled_binary - `1` - `1` - `0` - :good:`100%` - * - debuginfo-tests/dexter/feature_tests/commands/perfect/dex_declare_file/precompiled_binary_different_dir/source + * - cross-project-tests/debuginfo-tests/dexter/feature_tests/commands/perfect/dex_declare_file/precompiled_binary_different_dir/source - `1` - `1` - `0` - :good:`100%` - * - debuginfo-tests/dexter/feature_tests/commands/perfect/dex_declare_file/windows_noncanonical_path/source + * - cross-project-tests/debuginfo-tests/dexter/feature_tests/commands/perfect/dex_declare_file/windows_noncanonical_path/source - `1` - `0` - `1` - :none:`0%` - * - debuginfo-tests/dexter/feature_tests/commands/perfect/expect_step_kind + * - cross-project-tests/debuginfo-tests/dexter/feature_tests/commands/perfect/dex_finish_test + - `8` + - `0` + - `8` + - :none:`0%` + * - cross-project-tests/debuginfo-tests/dexter/feature_tests/commands/perfect/expect_step_kind - `5` - `0` - `5` - :none:`0%` - * - debuginfo-tests/dexter/feature_tests/commands/perfect/limit_steps + * - cross-project-tests/debuginfo-tests/dexter/feature_tests/commands/perfect/limit_steps - `8` - `2` - `6` - :part:`25%` - * - debuginfo-tests/dexter/feature_tests/subtools + * - cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools - `1` - `0` - `1` - :none:`0%` - * - debuginfo-tests/dexter/feature_tests/subtools/clang-opt-bisect - - `1` + * - cross-project-tests/debuginfo-tests/dexter/feature_tests/subtools/clang-opt-bisect + - `2` - `0` - - `1` + - `2` - :none:`0%` - * - debuginfo-tests/dexter-tests + * - cross-project-tests/debuginfo-tests/dexter-tests - `15` - `3` - `12` - :part:`20%` - * - debuginfo-tests/llgdb-tests + * - cross-project-tests/debuginfo-tests/llgdb-tests - `8` - `0` - `8` - :none:`0%` - * - debuginfo-tests/llvm-prettyprinters/gdb - - `2` + * - cross-project-tests/debuginfo-tests/llvm-prettyprinters/gdb - `2` + - `1` + - `1` + - :part:`50%` + * - flang/examples + - `1` + - `1` + - `0` + - :good:`100%` + * - flang/examples/FlangOmpReport + - `3` + - `3` + - `0` + - :good:`100%` + * - flang/examples/PrintFlangFunctionNames + - `1` + - `1` - `0` - :good:`100%` * - flang/include/flang @@ -1620,8 +1795,8 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - flang/include/flang/Common - - `20` - - `20` + - `21` + - `21` - `0` - :good:`100%` * - flang/include/flang/Decimal @@ -1635,25 +1810,35 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - flang/include/flang/Frontend - - `9` - - `9` - - `0` - - :good:`100%` + - `11` + - `10` + - `1` + - :part:`90%` * - flang/include/flang/FrontendTool - `1` - `1` - `0` - :good:`100%` * - flang/include/flang/Lower - - `19` - - `19` - - `0` - - :good:`100%` + - `25` + - `24` + - `1` + - :part:`96%` * - flang/include/flang/Lower/Support - `2` - `2` - `0` - :good:`100%` + * - flang/include/flang/Optimizer/Builder + - `7` + - `7` + - `0` + - :good:`100%` + * - flang/include/flang/Optimizer/Builder/Runtime + - `10` + - `10` + - `0` + - :good:`100%` * - flang/include/flang/Optimizer/CodeGen - `1` - `1` @@ -1665,10 +1850,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - flang/include/flang/Optimizer/Support - - `5` - - `4` - - `1` - - :part:`80%` + - `8` + - `8` + - `0` + - :good:`100%` * - flang/include/flang/Optimizer/Transforms - `1` - `1` @@ -1679,6 +1864,11 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `16` - `1` - :part:`94%` + * - flang/include/flang/Runtime + - `28` + - `27` + - `1` + - :part:`96%` * - flang/include/flang/Semantics - `9` - `8` @@ -1695,43 +1885,53 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - flang/lib/Evaluate + - `33` - `31` - - `30` - - `1` - - :part:`96%` + - `2` + - :part:`93%` * - flang/lib/Frontend - `8` - - `8` - - `0` - - :good:`100%` + - `6` + - `2` + - :part:`75%` * - flang/lib/FrontendTool - `1` - `1` - `0` - :good:`100%` * - flang/lib/Lower - - `17` - - `17` + - `20` + - `20` + - `0` + - :good:`100%` + * - flang/lib/Optimizer/Builder + - `6` + - `6` + - `0` + - :good:`100%` + * - flang/lib/Optimizer/Builder/Runtime + - `9` + - `9` - `0` - :good:`100%` * - flang/lib/Optimizer/CodeGen - - `4` - - `3` - - `1` - - :part:`75%` + - `10` + - `10` + - `0` + - :good:`100%` * - flang/lib/Optimizer/Dialect - - `4` - - `2` - - `2` - - :part:`50%` + - `5` + - `5` + - `0` + - :good:`100%` * - flang/lib/Optimizer/Support - - `3` - - `3` + - `4` + - `4` - `0` - :good:`100%` * - flang/lib/Optimizer/Transforms - - `1` - - `1` + - `10` + - `10` - `0` - :good:`100%` * - flang/lib/Parser @@ -1741,22 +1941,27 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - flang/lib/Semantics - `78` - - `72` - - `6` - - :part:`92%` + - `69` + - `9` + - :part:`88%` * - flang/module - `1` - `1` - `0` - :good:`100%` * - flang/runtime - - `82` - - `82` + - `74` + - `72` + - `2` + - :part:`97%` + * - flang/tools/bbc + - `1` + - `1` - `0` - :good:`100%` * - flang/tools/f18 - - `2` - - `2` + - `1` + - `1` - `0` - :good:`100%` * - flang/tools/f18-parse-demo @@ -1779,6 +1984,11 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` + * - flang/unittests/Common + - `1` + - `1` + - `0` + - :good:`100%` * - flang/unittests/Decimal - `2` - `2` @@ -1795,20 +2005,25 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - flang/unittests/Optimizer + - `4` - `3` - - `2` - `1` - - :part:`66%` + - :part:`75%` + * - flang/unittests/Optimizer/Builder + - `4` + - `4` + - `0` + - :good:`100%` + * - flang/unittests/Optimizer/Builder/Runtime + - `10` + - `10` + - `0` + - :good:`100%` * - flang/unittests/Runtime - - `5` - - `5` + - `22` + - `22` - `0` - :good:`100%` - * - flang/unittests/RuntimeGTest - - `15` - - `14` - - `1` - - :part:`93%` * - libc/AOR_v20.02/math - `4` - `1` @@ -1840,11 +2055,26 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - :none:`0%` * - libc/benchmarks - - `12` - - `12` - - `0` - - :good:`100%` - * - libc/config/linux + - `15` + - `14` + - `1` + - :part:`93%` + * - libc/benchmarks/automemcpy/include/automemcpy + - `4` + - `4` + - `0` + - :good:`100%` + * - libc/benchmarks/automemcpy/lib + - `5` + - `5` + - `0` + - :good:`100%` + * - libc/benchmarks/automemcpy/unittests + - `2` + - `2` + - `0` + - :good:`100%` + * - libc/config/linux - `1` - `1` - `0` @@ -1854,14 +2084,39 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `6` - `0` - :good:`100%` + * - libc/fuzzing/stdlib + - `3` + - `3` + - `0` + - :good:`100%` * - libc/fuzzing/string - `3` - `2` - `1` - :part:`66%` * - libc/include - - `3` - - `3` + - `1` + - `1` + - `0` + - :good:`100%` + * - libc/include/llvm-libc-macros + - `2` + - `2` + - `0` + - :good:`100%` + * - libc/include/llvm-libc-macros/linux + - `1` + - `1` + - `0` + - :good:`100%` + * - libc/include/llvm-libc-types + - `28` + - `28` + - `0` + - :good:`100%` + * - libc/loader/linux/aarch64 + - `1` + - `1` - `0` - :good:`100%` * - libc/loader/linux/x86_64 @@ -1875,23 +2130,38 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `2` - :part:`33%` * - libc/src/ctype - - `33` - - `33` + - `32` + - `32` - `0` - :good:`100%` * - libc/src/errno + - `4` + - `4` + - `0` + - :good:`100%` + * - libc/src/fcntl + - `3` + - `3` + - `0` + - :good:`100%` + * - libc/src/fcntl/linux - `3` - `3` - `0` - :good:`100%` * - libc/src/fenv - - `22` - - `22` + - `28` + - `28` + - `0` + - :good:`100%` + * - libc/src/inttypes + - `6` + - `6` - `0` - :good:`100%` * - libc/src/math - - `86` - - `86` + - `91` + - `91` - `0` - :good:`100%` * - libc/src/math/aarch64 @@ -1900,8 +2170,8 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - libc/src/math/generic - - `85` - - `85` + - `94` + - `94` - `0` - :good:`100%` * - libc/src/math/x86_64 @@ -1925,98 +2195,133 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - libc/src/stdlib - - `9` - - `9` + - `46` + - `46` - `0` - :good:`100%` * - libc/src/stdlib/linux - - `1` - - `1` + - `2` + - `2` - `0` - :good:`100%` * - libc/src/string - - `43` - - `43` - - `0` - - :good:`100%` - * - libc/src/string/aarch64 - - `1` - - `1` + - `61` + - `61` - `0` - :good:`100%` * - libc/src/string/memory_utils - - `3` - - `3` + - `8` + - `7` + - `1` + - :part:`87%` + * - libc/src/sys/mman + - `2` + - `2` - `0` - :good:`100%` - * - libc/src/string/x86_64 + * - libc/src/sys/mman/linux + - `2` - `1` - `1` - - `0` - - :good:`100%` - * - libc/src/sys/mman + - :part:`50%` + * - libc/src/sys/stat - `2` - `2` - `0` - :good:`100%` - * - libc/src/sys/mman/linux + * - libc/src/sys/stat/linux - `2` - `2` - `0` - :good:`100%` * - libc/src/threads - - `6` - - `6` + - `16` + - `16` - `0` - :good:`100%` * - libc/src/threads/linux + - `11` - `7` - - `7` - - `0` - - :good:`100%` + - `4` + - :part:`63%` * - libc/src/time - `12` - `12` - `0` - :good:`100%` * - libc/src/unistd - - `1` - - `1` + - `7` + - `7` - `0` - :good:`100%` * - libc/src/unistd/linux + - `7` + - `7` + - `0` + - :good:`100%` + * - libc/src/__support + - `10` + - `10` + - `0` + - :good:`100%` + * - libc/src/__support/CPP + - `11` + - `10` - `1` + - :part:`90%` + * - libc/src/__support/File + - `2` + - `2` + - `0` + - :good:`100%` + * - libc/src/__support/FPUtil + - `15` + - `14` - `1` + - :part:`93%` + * - libc/src/__support/FPUtil/aarch64 + - `3` + - `3` - `0` - :good:`100%` - * - libc/src/__support - - `4` - - `4` + * - libc/src/__support/FPUtil/generic + - `3` + - `3` - `0` - :good:`100%` - * - libc/utils/CPP - - `6` + * - libc/src/__support/FPUtil/x86_64 - `6` + - `5` + - `1` + - :part:`83%` + * - libc/src/__support/OSUtil + - `3` + - `3` - `0` - :good:`100%` - * - libc/utils/FPUtil - - `20` - - `20` + * - libc/src/__support/OSUtil/linux + - `3` + - `2` + - `1` + - :part:`66%` + * - libc/src/__support/OSUtil/linux/aarch64 + - `1` + - `1` - `0` - :good:`100%` - * - libc/utils/FPUtil/aarch64 - - `2` - - `2` + * - libc/src/__support/OSUtil/linux/x86_64 + - `1` + - `1` - `0` - :good:`100%` - * - libc/utils/FPUtil/generic + * - libc/src/__support/threads - `1` - `1` - `0` - :good:`100%` - * - libc/utils/FPUtil/x86_64 - - `2` - - `2` + * - libc/src/__support/threads/linux + - `1` + - `1` - `0` - :good:`100%` * - libc/utils/HdrGen @@ -2036,9 +2341,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - libc/utils/MPFRWrapper - `3` - - `2` - - `1` - - :part:`66%` + - `3` + - `0` + - :good:`100%` * - libc/utils/testutils - `10` - `9` @@ -2050,10 +2355,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - libc/utils/UnitTest - - `4` - - `4` - - `0` - - :good:`100%` + - `12` + - `11` + - `1` + - :part:`91%` * - libclc/generic/include - `2` - `1` @@ -2195,114 +2500,189 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - :none:`0%` * - libcxx/benchmarks - - `22` - - `5` - - `17` - - :part:`22%` + - `28` + - `10` + - `18` + - :part:`35%` * - libcxx/include - `22` - - `5` - - `17` - - :part:`22%` - * - libcxx/include/__format + - `0` + - `22` + - :none:`0%` + * - libcxx/include/__algorithm + - `102` + - `15` + - `87` + - :part:`14%` + * - libcxx/include/__bit - `2` - `0` - `2` - :none:`0%` - * - libcxx/include/__iterator - - `11` + * - libcxx/include/__charconv - `3` - - `8` - - :part:`27%` - * - libcxx/include/__memory - - `14` - `0` - - `14` + - `3` - :none:`0%` - * - libcxx/include/__ranges + * - libcxx/include/__chrono - `8` - - `1` - - `7` - - :part:`12%` - * - libcxx/include/__support/android - - `1` - `0` - - `1` + - `8` - :none:`0%` - * - libcxx/include/__support/fuchsia - - `1` - - `1` - - `0` - - :good:`100%` - * - libcxx/include/__support/ibm - - `7` - - `2` - - `5` - - :part:`28%` - * - libcxx/include/__support/musl + * - libcxx/include/__compare + - `13` - `1` + - `12` + - :part:`7%` + * - libcxx/include/__concepts + - `22` - `0` - - `1` + - `22` - :none:`0%` - * - libcxx/include/__support/newlib - - `1` + * - libcxx/include/__coroutine + - `4` - `0` - - `1` + - `4` - :none:`0%` - * - libcxx/include/__support/nuttx - - `1` - - `1` - - `0` - - :good:`100%` - * - libcxx/include/__support/openbsd - - `1` - - `1` - - `0` - - :good:`100%` - * - libcxx/include/__support/solaris + * - libcxx/include/__filesystem + - `16` - `3` + - `13` + - :part:`18%` + * - libcxx/include/__format + - `17` - `2` - - `1` - - :part:`66%` - * - libcxx/include/__support/win32 - - `2` + - `15` + - :part:`11%` + * - libcxx/include/__functional + - `27` - `0` - - `2` + - `27` - :none:`0%` - * - libcxx/include/__support/xlocale - - `3` + * - libcxx/include/__ios + - `1` - `0` - - `3` + - `1` - :none:`0%` - * - libcxx/include/__utility + * - libcxx/include/__iterator + - `36` + - `0` + - `36` + - :none:`0%` + * - libcxx/include/__memory + - `19` + - `1` + - `18` + - :part:`5%` + * - libcxx/include/__numeric + - `13` + - `4` + - `9` + - :part:`30%` + * - libcxx/include/__random + - `37` + - `2` + - `35` + - :part:`5%` + * - libcxx/include/__ranges + - `29` + - `2` + - `27` + - :part:`6%` + * - libcxx/include/__support/android - `1` - `0` - `1` - :none:`0%` - * - libcxx/src - - `38` + * - libcxx/include/__support/fuchsia + - `1` + - `0` + - `1` + - :none:`0%` + * - libcxx/include/__support/ibm + - `6` + - `2` + - `4` + - :part:`33%` + * - libcxx/include/__support/musl + - `1` + - `0` + - `1` + - :none:`0%` + * - libcxx/include/__support/newlib + - `1` + - `0` + - `1` + - :none:`0%` + * - libcxx/include/__support/openbsd + - `1` + - `1` + - `0` + - :good:`100%` + * - libcxx/include/__support/solaris - `3` - - `35` - - :part:`7%` - * - libcxx/src/experimental + - `2` + - `1` + - :part:`66%` + * - libcxx/include/__support/win32 + - `2` + - `0` + - `2` + - :none:`0%` + * - libcxx/include/__support/xlocale + - `3` + - `0` + - `3` + - :none:`0%` + * - libcxx/include/__thread + - `2` + - `0` + - `2` + - :none:`0%` + * - libcxx/include/__utility + - `17` + - `5` + - `12` + - :part:`29%` + * - libcxx/include/__variant - `1` - `0` - `1` - :none:`0%` + * - libcxx/src + - `42` + - `6` + - `36` + - :part:`14%` + * - libcxx/src/experimental + - `2` + - `1` + - `1` + - :part:`50%` * - libcxx/src/filesystem - `5` - `0` - `5` - :none:`0%` * - libcxx/src/include + - `6` + - `1` - `5` - - `2` + - :part:`16%` + * - libcxx/src/include/ryu + - `9` + - `8` + - `1` + - :part:`88%` + * - libcxx/src/ryu - `3` - - :part:`40%` + - `3` + - `0` + - :good:`100%` * - libcxx/src/support/ibm - - `1` + - `3` - `0` - - `1` + - `3` - :none:`0%` * - libcxx/src/support/solaris - `1` @@ -2314,21 +2694,6 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - `3` - :none:`0%` - * - libcxx/utils/google-benchmark/cmake - - `5` - - `1` - - `4` - - :part:`20%` - * - libcxx/utils/google-benchmark/include/benchmark - - `1` - - `0` - - `1` - - :none:`0%` - * - libcxx/utils/google-benchmark/src - - `20` - - `16` - - `4` - - :part:`80%` * - libcxxabi/fuzz - `1` - `0` @@ -2341,23 +2706,18 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :none:`0%` * - libcxxabi/src - `25` - - `0` - - `25` - - :none:`0%` + - `1` + - `24` + - :part:`4%` * - libcxxabi/src/demangle - `4` - `2` - `2` - :part:`50%` - * - libcxxabi/src/include - - `1` - - `0` - - `1` - - :none:`0%` * - libunwind/include - - `3` + - `5` - `0` - - `3` + - `5` - :none:`0%` * - libunwind/include/mach-o - `1` @@ -2365,75 +2725,45 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - :none:`0%` * - libunwind/src + - `10` + - `1` - `9` - - `0` - - `9` - - :none:`0%` + - :part:`10%` * - lld/COFF - - `35` - - `11` + - `37` + - `13` - `24` - - :part:`31%` + - :part:`35%` * - lld/Common - - `10` - - `8` + - `11` + - `9` - `2` - - :part:`80%` + - :part:`81%` * - lld/ELF - `48` - - `24` - - `24` - - :part:`50%` + - `25` + - `23` + - :part:`52%` * - lld/ELF/Arch - `14` - - `5` - - `9` - - :part:`35%` + - `4` + - `10` + - :part:`28%` * - lld/include/lld/Common - - `13` + - `14` + - `8` - `6` - - `7` - - :part:`46%` + - :part:`57%` * - lld/include/lld/Core - `20` - `4` - `16` - :part:`20%` - * - lld/include/lld/ReaderWriter - - `2` - - `0` - - `2` - - :none:`0%` - * - lld/lib/Core - - `8` - - `2` - - `6` - - :part:`25%` - * - lld/lib/Driver - - `1` - - `0` - - `1` - - :none:`0%` - * - lld/lib/ReaderWriter - - `1` - - `0` - - `1` - - :none:`0%` - * - lld/lib/ReaderWriter/MachO - - `30` - - `1` - - `29` - - :part:`3%` - * - lld/lib/ReaderWriter/YAML - - `1` - - `0` - - `1` - - :none:`0%` * - lld/MachO - - `41` - - `38` - - `3` - - :part:`92%` + - `45` + - `43` + - `2` + - :part:`95%` * - lld/MachO/Arch - `6` - `6` @@ -2449,21 +2779,11 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` - * - lld/unittests/DriverTests - - `1` - - `0` - - `1` - - :none:`0%` - * - lld/unittests/MachOTests - - `4` - - `0` - - `4` - - :none:`0%` * - lld/wasm - `29` - - `17` - - `12` - - :part:`58%` + - `15` + - `14` + - :part:`51%` * - lldb/bindings/python - `1` - `1` @@ -2505,20 +2825,20 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `6` - :part:`50%` * - lldb/include/lldb/API - - `71` - - `59` - - `12` - - :part:`83%` + - `70` + - `60` + - `10` + - :part:`85%` * - lldb/include/lldb/Breakpoint - `25` - - `10` - - `15` - - :part:`40%` + - `9` + - `16` + - :part:`36%` * - lldb/include/lldb/Core - - `60` - - `32` - - `28` - - :part:`53%` + - `61` + - `31` + - `30` + - :part:`50%` * - lldb/include/lldb/DataFormatters - `18` - `10` @@ -2530,10 +2850,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `10` - :part:`41%` * - lldb/include/lldb/Host - - `40` - - `21` + - `39` + - `20` - `19` - - :part:`52%` + - :part:`51%` * - lldb/include/lldb/Host/android - `1` - `1` @@ -2585,50 +2905,50 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `2` - :part:`33%` * - lldb/include/lldb/Interpreter - - `48` + - `49` - `36` - - `12` - - :part:`75%` + - `13` + - :part:`73%` * - lldb/include/lldb/Symbol - `35` - - `16` - - `19` - - :part:`45%` + - `14` + - `21` + - :part:`40%` * - lldb/include/lldb/Target - - `72` - - `44` - - `28` - - :part:`61%` + - `78` + - `51` + - `27` + - :part:`65%` * - lldb/include/lldb/Utility - - `64` + - `63` - `41` - - `23` - - :part:`64%` - * - lldb/source + - `22` + - :part:`65%` + * - lldb/include/lldb/Version - `1` - `1` - `0` - :good:`100%` * - lldb/source/API - - `75` - - `6` - - `69` - - :part:`8%` + - `73` + - `36` + - `37` + - :part:`49%` * - lldb/source/Breakpoint - `24` - - `5` - - `19` - - :part:`20%` + - `6` + - `18` + - :part:`25%` * - lldb/source/Commands - - `68` - - `60` - - `8` - - :part:`88%` + - `70` + - `57` + - `13` + - :part:`81%` * - lldb/source/Core - - `48` - - `25` + - `49` + - `26` - `23` - - :part:`52%` + - :part:`53%` * - lldb/source/DataFormatters - `16` - `3` @@ -2636,19 +2956,19 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :part:`18%` * - lldb/source/Expression - `13` - - `4` - - `9` - - :part:`30%` + - `5` + - `8` + - :part:`38%` * - lldb/source/Host/android - `2` - `2` - `0` - :good:`100%` * - lldb/source/Host/common - - `32` - - `16` + - `31` - `16` - - :part:`50%` + - `15` + - :part:`51%` * - lldb/source/Host/freebsd - `2` - `2` @@ -2656,9 +2976,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - lldb/source/Host/linux - `5` - - `4` - - `1` - - :part:`80%` + - `5` + - `0` + - :good:`100%` * - lldb/source/Host/macosx/cfcpp - `14` - `12` @@ -2681,14 +3001,14 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :part:`50%` * - lldb/source/Host/posix - `9` - - `5` - - `4` - - :part:`55%` + - `6` + - `3` + - :part:`66%` * - lldb/source/Host/windows - `11` - - `5` - - `6` - - :part:`45%` + - `7` + - `4` + - :part:`63%` * - lldb/source/Initialization - `3` - `3` @@ -2696,14 +3016,14 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - lldb/source/Interpreter - `44` - - `22` - - `22` - - :part:`50%` + - `24` + - `20` + - :part:`54%` * - lldb/source/Plugins/ABI/AArch64 - `6` - - `2` - - `4` - - :part:`33%` + - `3` + - `3` + - :part:`50%` * - lldb/source/Plugins/ABI/ARC - `2` - `0` @@ -2735,10 +3055,15 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `2` - :none:`0%` * - lldb/source/Plugins/ABI/X86 - - `11` - - `3` - - `8` - - :part:`27%` + - `13` + - `4` + - `9` + - :part:`30%` + * - lldb/source/Plugins/Architecture/AArch64 + - `2` + - `2` + - `0` + - :good:`100%` * - lldb/source/Plugins/Architecture/Arm - `2` - `1` @@ -2796,9 +3121,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :part:`50%` * - lldb/source/Plugins/ExpressionParser/Clang - `51` - - `26` - `25` - - :part:`50%` + - `26` + - :part:`49%` * - lldb/source/Plugins/Instruction/ARM - `4` - `2` @@ -2855,15 +3180,15 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - lldb/source/Plugins/Language/CPlusPlus - - `29` - - `17` - - `12` - - :part:`58%` + - `30` + - `19` + - `11` + - :part:`63%` * - lldb/source/Plugins/Language/ObjC - - `20` + - `21` - `14` - - `6` - - :part:`70%` + - `7` + - :part:`66%` * - lldb/source/Plugins/Language/ObjCPlusPlus - `2` - `2` @@ -2886,9 +3211,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :none:`0%` * - lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime - `16` - - `6` - - `10` - - :part:`37%` + - `5` + - `11` + - :part:`31%` * - lldb/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime - `8` - `3` @@ -2929,6 +3254,11 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - `2` - :none:`0%` + * - lldb/source/Plugins/ObjectFile/Minidump + - `4` + - `4` + - `0` + - :good:`100%` * - lldb/source/Plugins/ObjectFile/PDB - `2` - `2` @@ -2994,11 +3324,16 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - `2` - :none:`0%` - * - lldb/source/Plugins/Platform/Windows + * - lldb/source/Plugins/Platform/QemuUser - `2` - `2` - `0` - :good:`100%` + * - lldb/source/Plugins/Platform/Windows + - `2` + - `1` + - `1` + - :part:`50%` * - lldb/source/Plugins/Process/elf-core - `20` - `18` @@ -3009,11 +3344,16 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `12` - `4` - :part:`75%` + * - lldb/source/Plugins/Process/FreeBSDKernel + - `10` + - `8` + - `2` + - :part:`80%` * - lldb/source/Plugins/Process/gdb-remote - `26` - - `16` - - `10` - - :part:`61%` + - `15` + - `11` + - :part:`57%` * - lldb/source/Plugins/Process/Linux - `21` - `11` @@ -3041,19 +3381,24 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :part:`50%` * - lldb/source/Plugins/Process/POSIX - `8` - - `5` - - `3` - - :part:`62%` + - `7` + - `1` + - :part:`87%` + * - lldb/source/Plugins/Process/scripted + - `4` + - `4` + - `0` + - :good:`100%` * - lldb/source/Plugins/Process/Utility - `132` - - `95` - - `37` - - :part:`71%` + - `97` + - `35` + - :part:`73%` * - lldb/source/Plugins/Process/Windows/Common - `34` - - `23` - - `11` - - :part:`67%` + - `22` + - `12` + - :part:`64%` * - lldb/source/Plugins/Process/Windows/Common/arm - `2` - `1` @@ -3074,21 +3419,26 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - `2` - :none:`0%` - * - lldb/source/Plugins/ScriptInterpreter/Lua - - `4` - - `3` + * - lldb/source/Plugins/REPL/Clang + - `2` - `1` - - :part:`75%` + - `1` + - :part:`50%` + * - lldb/source/Plugins/ScriptInterpreter/Lua + - `5` + - `5` + - `0` + - :good:`100%` * - lldb/source/Plugins/ScriptInterpreter/None - `2` - `2` - `0` - :good:`100%` * - lldb/source/Plugins/ScriptInterpreter/Python + - `16` - `12` - - `7` - - `5` - - :part:`58%` + - `4` + - :part:`75%` * - lldb/source/Plugins/StructuredData/DarwinLog - `2` - `0` @@ -3101,14 +3451,14 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :none:`0%` * - lldb/source/Plugins/SymbolFile/DWARF - `65` - - `37` - - `28` - - :part:`56%` + - `39` + - `26` + - :part:`60%` * - lldb/source/Plugins/SymbolFile/NativePDB - `20` - - `11` - - `9` - - :part:`55%` + - `10` + - `10` + - :part:`50%` * - lldb/source/Plugins/SymbolFile/PDB - `6` - `4` @@ -3139,11 +3489,26 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `9` - :part:`10%` + * - lldb/source/Plugins/Trace/common + - `8` + - `7` + - `1` + - :part:`87%` * - lldb/source/Plugins/Trace/intel-pt - - `11` - - `11` + - `18` + - `17` + - `1` + - :part:`94%` + * - lldb/source/Plugins/TraceExporter/common + - `2` + - `2` - `0` - :good:`100%` + * - lldb/source/Plugins/TraceExporter/ctf + - `4` + - `3` + - `1` + - :part:`75%` * - lldb/source/Plugins/TypeSystem/Clang - `2` - `0` @@ -3161,19 +3526,24 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :part:`50%` * - lldb/source/Symbol - `31` - - `17` - - `14` - - :part:`54%` + - `18` + - `13` + - :part:`58%` * - lldb/source/Target - - `65` - - `32` - - `33` + - `69` + - `34` + - `35` - :part:`49%` * - lldb/source/Utility - `58` - - `45` - - `13` - - :part:`77%` + - `46` + - `12` + - :part:`79%` + * - lldb/source/Version + - `1` + - `1` + - `0` + - :good:`100%` * - lldb/tools/argdumper - `1` - `1` @@ -3185,10 +3555,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - lldb/tools/debugserver/source - - `49` - - `40` - - `9` - - :part:`81%` + - `51` + - `40` + - `11` + - :part:`78%` * - lldb/tools/debugserver/source/MacOSX - `24` - `16` @@ -3204,11 +3574,6 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `1` - :part:`50%` - * - lldb/tools/debugserver/source/MacOSX/DarwinLog - - `20` - - `18` - - `2` - - :part:`90%` * - lldb/tools/debugserver/source/MacOSX/i386 - `3` - `0` @@ -3231,9 +3596,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - lldb/tools/intel-features/intel-mpx - `2` - - `2` - - `0` - - :good:`100%` + - `1` + - `1` + - :part:`50%` * - lldb/tools/lldb-instr - `1` - `1` @@ -3251,9 +3616,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :part:`40%` * - lldb/tools/lldb-vscode - `27` - - `26` - - `1` - - :part:`96%` + - `24` + - `3` + - :part:`88%` * - lldb/unittests - `1` - `1` @@ -3296,29 +3661,34 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - lldb/unittests/Expression - `5` - - `2` - `3` - - :part:`40%` + - `2` + - :part:`60%` * - lldb/unittests/Host - - `14` + - `16` - `11` - - `3` - - :part:`78%` + - `5` + - :part:`68%` * - lldb/unittests/Host/linux - `2` - `2` - `0` - :good:`100%` + * - lldb/unittests/Host/posix + - `1` + - `0` + - `1` + - :none:`0%` * - lldb/unittests/Instruction - `1` - `0` - `1` - :none:`0%` * - lldb/unittests/Interpreter + - `6` + - `2` - `4` - - `1` - - `3` - - :part:`25%` + - :part:`33%` * - lldb/unittests/Language/CLanguages - `1` - `1` @@ -3355,10 +3725,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - :none:`0%` * - lldb/unittests/Platform + - `3` - `2` - `1` - - `1` - - :part:`50%` + - :part:`66%` * - lldb/unittests/Platform/Android - `1` - `0` @@ -3370,10 +3740,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - lldb/unittests/Process/gdb-remote - - `7` + - `8` - `6` - - `1` - - :part:`85%` + - `2` + - :part:`75%` * - lldb/unittests/Process/Linux - `1` - `0` @@ -3395,35 +3765,35 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - lldb/unittests/Process/Utility - - `5` - - `3` + - `6` + - `4` - `2` - - :part:`60%` + - :part:`66%` * - lldb/unittests/ScriptInterpreter/Lua - `2` - - `1` - - `1` - - :part:`50%` + - `2` + - `0` + - :good:`100%` * - lldb/unittests/ScriptInterpreter/Python - `3` - - `1` - `2` - - :part:`33%` + - `1` + - :part:`66%` * - lldb/unittests/Signals - `1` - `1` - `0` - :good:`100%` * - lldb/unittests/Symbol + - `11` - `7` - `4` - - `3` - - :part:`57%` + - :part:`63%` * - lldb/unittests/SymbolFile/DWARF + - `6` - `4` - - `1` - - `3` - - :part:`25%` + - `2` + - :part:`66%` * - lldb/unittests/SymbolFile/DWARF/Inputs - `1` - `1` @@ -3445,10 +3815,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - lldb/unittests/Target - - `7` - - `3` + - `10` + - `6` - `4` - - :part:`42%` + - :part:`60%` * - lldb/unittests/TestingSupport - `5` - `4` @@ -3475,9 +3845,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `2` - :none:`0%` * - lldb/unittests/tools/lldb-server/tests - - `8` + - `7` - `0` - - `8` + - `7` - :none:`0%` * - lldb/unittests/UnwindAssembly/ARM64 - `1` @@ -3669,6 +4039,11 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` + * - llvm/examples/OrcV2Examples/LLJITWithExecutorProcessControl + - `1` + - `1` + - `0` + - :good:`100%` * - llvm/examples/OrcV2Examples/LLJITWithGDBRegistrationListener - `1` - `1` @@ -3701,14 +4076,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - llvm/examples/OrcV2Examples/LLJITWithRemoteDebugging - `3` - - `3` - - `0` - - :good:`100%` - * - llvm/examples/OrcV2Examples/LLJITWithTargetProcessControl - - `1` - `1` - - `0` - - :good:`100%` + - `2` + - :part:`33%` * - llvm/examples/OrcV2Examples/LLJITWithThinLTOSummaries - `1` - `0` @@ -3730,15 +4100,15 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `6` - :part:`25%` * - llvm/include/llvm/ADT - - `87` - - `22` - - `65` - - :part:`25%` + - `93` + - `25` + - `68` + - :part:`26%` * - llvm/include/llvm/Analysis - - `123` - - `41` - - `82` - - :part:`33%` + - `130` + - `52` + - `78` + - :part:`40%` * - llvm/include/llvm/Analysis/Utils - `3` - `1` @@ -3750,30 +4120,30 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `3` - :part:`40%` * - llvm/include/llvm/BinaryFormat - - `14` - - `9` - - `5` - - :part:`64%` + - `15` + - `8` + - `7` + - :part:`53%` * - llvm/include/llvm/Bitcode - `7` - - `3` - - `4` - - :part:`42%` + - `2` + - `5` + - :part:`28%` * - llvm/include/llvm/Bitstream - `3` - `0` - `3` - :none:`0%` * - llvm/include/llvm/CodeGen - - `149` - - `44` - - `105` - - :part:`29%` + - `158` + - `51` + - `107` + - :part:`32%` * - llvm/include/llvm/CodeGen/GlobalISel - `27` - - `9` - - `18` - - :part:`33%` + - `8` + - `19` + - :part:`29%` * - llvm/include/llvm/CodeGen/MIRParser - `2` - `1` @@ -3786,9 +4156,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :part:`20%` * - llvm/include/llvm/DebugInfo - `1` - - `0` - `1` - - :none:`0%` + - `0` + - :good:`100%` * - llvm/include/llvm/DebugInfo/CodeView - `57` - `40` @@ -3796,14 +4166,14 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :part:`70%` * - llvm/include/llvm/DebugInfo/DWARF - `32` - - `17` - - `15` - - :part:`53%` + - `14` + - `18` + - :part:`43%` * - llvm/include/llvm/DebugInfo/GSYM - `14` - - `3` - - `11` - - :part:`21%` + - `4` + - `10` + - :part:`28%` * - llvm/include/llvm/DebugInfo/MSF - `5` - `4` @@ -3811,9 +4181,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :part:`80%` * - llvm/include/llvm/DebugInfo/PDB - `50` - - `7` - - `43` - - :part:`14%` + - `30` + - `20` + - :part:`60%` * - llvm/include/llvm/DebugInfo/PDB/DIA - `20` - `9` @@ -3825,43 +4195,53 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `19` - :part:`64%` * - llvm/include/llvm/DebugInfo/Symbolize + - `5` - `3` - - `1` - `2` - - :part:`33%` + - :part:`60%` + * - llvm/include/llvm/Debuginfod + - `3` + - `3` + - `0` + - :good:`100%` * - llvm/include/llvm/Demangle - - `8` + - `7` - `3` - - `5` - - :part:`37%` + - `4` + - :part:`42%` * - llvm/include/llvm/DWARFLinker - `4` - `4` - `0` - :good:`100%` - * - llvm/include/llvm/ExecutionEngine - - `14` + * - llvm/include/llvm/DWP - `3` - - `11` - - :part:`21%` - * - llvm/include/llvm/ExecutionEngine/JITLink - - `10` - - `7` - `3` - - :part:`70%` + - `0` + - :good:`100%` + * - llvm/include/llvm/ExecutionEngine + - `12` + - `2` + - `10` + - :part:`16%` + * - llvm/include/llvm/ExecutionEngine/JITLink + - `16` + - `14` + - `2` + - :part:`87%` * - llvm/include/llvm/ExecutionEngine/Orc - - `32` - - `21` - - `11` - - :part:`65%` + - `38` + - `29` + - `9` + - :part:`76%` * - llvm/include/llvm/ExecutionEngine/Orc/Shared - - `6` - - `5` - - `1` - - :part:`83%` - * - llvm/include/llvm/ExecutionEngine/Orc/TargetProcess + - `8` - `4` - `4` + - :part:`50%` + * - llvm/include/llvm/ExecutionEngine/Orc/TargetProcess + - `7` + - `7` - `0` - :good:`100%` * - llvm/include/llvm/FileCheck @@ -3870,10 +4250,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - llvm/include/llvm/Frontend/OpenMP + - `5` - `4` - - `4` - - `0` - - :good:`100%` + - `1` + - :part:`80%` * - llvm/include/llvm/FuzzMutate - `6` - `0` @@ -3885,10 +4265,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - llvm/include/llvm/IR - - `92` - - `25` - - `67` - - :part:`27%` + - `93` + - `28` + - `65` + - :part:`30%` * - llvm/include/llvm/IRReader - `1` - `0` @@ -3905,20 +4285,20 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `2` - :none:`0%` * - llvm/include/llvm/LTO - - `5` - - `2` + - `4` + - `1` - `3` - - :part:`40%` + - :part:`25%` * - llvm/include/llvm/LTO/legacy - `4` - `0` - `4` - :none:`0%` * - llvm/include/llvm/MC - - `70` - - `19` - - `51` - - :part:`27%` + - `74` + - `24` + - `50` + - :part:`32%` * - llvm/include/llvm/MC/MCDisassembler - `4` - `1` @@ -3930,45 +4310,75 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `5` - :part:`37%` * - llvm/include/llvm/MCA + - `10` + - `10` + - `0` + - :good:`100%` + * - llvm/include/llvm/MCA/HardwareUnits + - `6` + - `4` + - `2` + - :part:`66%` + * - llvm/include/llvm/MCA/Stages - `8` - `8` - `0` - :good:`100%` - * - llvm/include/llvm/MCA/HardwareUnits - - `6` - - `4` + * - llvm/include/llvm/ObjCopy + - `4` + - `3` + - `1` + - :part:`75%` + * - llvm/include/llvm/ObjCopy/COFF + - `2` + - `2` + - `0` + - :good:`100%` + * - llvm/include/llvm/ObjCopy/ELF + - `2` + - `2` + - `0` + - :good:`100%` + * - llvm/include/llvm/ObjCopy/MachO - `2` - - :part:`66%` - * - llvm/include/llvm/MCA/Stages - - `8` - - `7` - - `1` - - :part:`87%` + - `2` + - `0` + - :good:`100%` + * - llvm/include/llvm/ObjCopy/wasm + - `2` + - `2` + - `0` + - :good:`100%` + * - llvm/include/llvm/ObjCopy/XCOFF + - `2` + - `2` + - `0` + - :good:`100%` * - llvm/include/llvm/Object - `31` - - `11` - - `20` - - :part:`35%` + - `12` + - `19` + - :part:`38%` * - llvm/include/llvm/ObjectYAML - `16` - - `13` - - `3` - - :part:`81%` + - `12` + - `4` + - :part:`75%` * - llvm/include/llvm/Option - `5` - `1` - `4` - :part:`20%` * - llvm/include/llvm/Passes - - `3` - - `1` + - `4` - `2` - - :part:`33%` + - `2` + - :part:`50%` * - llvm/include/llvm/ProfileData - - `8` - - `3` + - `11` - `5` - - :part:`37%` + - `6` + - :part:`45%` * - llvm/include/llvm/ProfileData/Coverage - `3` - `2` @@ -3980,10 +4390,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - :part:`91%` * - llvm/include/llvm/Support - - `176` - - `57` - - `119` - - :part:`32%` + - `186` + - `68` + - `118` + - :part:`36%` * - llvm/include/llvm/Support/FileSystem - `1` - `1` @@ -4000,10 +4410,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - :none:`0%` * - llvm/include/llvm/TableGen - - `8` - - `2` + - `9` + - `3` - `6` - - :part:`25%` + - :part:`33%` * - llvm/include/llvm/Target - `6` - `2` @@ -4045,35 +4455,40 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - llvm/include/llvm/Transforms/InstCombine - - `3` - - `1` - `2` - - :part:`33%` + - `1` + - `1` + - :part:`50%` * - llvm/include/llvm/Transforms/Instrumentation - `17` - - `11` - - `6` - - :part:`64%` + - `10` + - `7` + - :part:`58%` * - llvm/include/llvm/Transforms/IPO - - `37` - - `26` - - `11` - - :part:`70%` + - `38` + - `28` + - `10` + - :part:`73%` * - llvm/include/llvm/Transforms/Scalar - - `73` - - `45` + - `75` + - `47` - `28` - - :part:`61%` + - :part:`62%` * - llvm/include/llvm/Transforms/Utils - - `70` - - `41` - - `29` - - :part:`58%` + - `74` + - `44` + - `30` + - :part:`59%` * - llvm/include/llvm/Transforms/Vectorize - `5` - `1` - `4` - :part:`20%` + * - llvm/include/llvm/WindowsDriver + - `2` + - `1` + - `1` + - :part:`50%` * - llvm/include/llvm/WindowsManifest - `1` - `1` @@ -4090,30 +4505,30 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `4` - :part:`76%` * - llvm/include/llvm-c - - `26` + - `27` - `12` - - `14` - - :part:`46%` + - `15` + - :part:`44%` * - llvm/include/llvm-c/Transforms - `9` - `3` - `6` - :part:`33%` * - llvm/lib/Analysis - - `117` - - `38` + - `119` + - `40` - `79` - - :part:`32%` + - :part:`33%` * - llvm/lib/AsmParser - `3` - `1` - `2` - :part:`33%` * - llvm/lib/BinaryFormat - - `11` - - `8` + - `13` + - `10` - `3` - - :part:`72%` + - :part:`76%` * - llvm/lib/Bitcode/Reader - `7` - `2` @@ -4130,25 +4545,25 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - :none:`0%` * - llvm/lib/CodeGen - - `204` - - `46` - - `158` - - :part:`22%` + - `220` + - `60` + - `160` + - :part:`27%` * - llvm/lib/CodeGen/AsmPrinter - `45` - - `16` - - `29` - - :part:`35%` + - `18` + - `27` + - :part:`40%` * - llvm/lib/CodeGen/GlobalISel - - `25` - - `8` - - `17` - - :part:`32%` + - `24` + - `9` + - `15` + - :part:`37%` * - llvm/lib/CodeGen/LiveDebugValues + - `5` + - `1` - `4` - - `2` - - `2` - - :part:`50%` + - :part:`20%` * - llvm/lib/CodeGen/MIRParser - `4` - `1` @@ -4161,14 +4576,14 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :part:`6%` * - llvm/lib/DebugInfo/CodeView - `40` - - `24` - - `16` - - :part:`60%` + - `23` + - `17` + - :part:`57%` * - llvm/lib/DebugInfo/DWARF - `28` - - `8` - - `20` - - :part:`28%` + - `9` + - `19` + - :part:`32%` * - llvm/lib/DebugInfo/GSYM - `11` - `2` @@ -4181,9 +4596,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :part:`75%` * - llvm/lib/DebugInfo/PDB - `40` - - `34` - - `6` - - :part:`85%` + - `35` + - `5` + - :part:`87%` * - llvm/lib/DebugInfo/PDB/DIA - `18` - `15` @@ -4196,17 +4611,27 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :part:`74%` * - llvm/lib/DebugInfo/Symbolize - `4` + - `3` - `1` + - :part:`75%` + * - llvm/lib/Debuginfod - `3` - - :part:`25%` - * - llvm/lib/Demangle - - `5` - `3` + - `0` + - :good:`100%` + * - llvm/lib/Demangle + - `6` + - `4` - `2` - - :part:`60%` + - :part:`66%` * - llvm/lib/DWARFLinker - `4` - - `4` + - `3` + - `1` + - :part:`75%` + * - llvm/lib/DWP + - `2` + - `2` - `0` - :good:`100%` * - llvm/lib/ExecutionEngine @@ -4225,10 +4650,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `4` - :none:`0%` * - llvm/lib/ExecutionEngine/JITLink - - `16` - - `8` + - `23` + - `15` - `8` - - :part:`50%` + - :part:`65%` * - llvm/lib/ExecutionEngine/MCJIT - `2` - `0` @@ -4240,20 +4665,20 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `2` - :none:`0%` * - llvm/lib/ExecutionEngine/Orc - - `28` - - `17` - - `11` - - :part:`60%` + - `37` + - `22` + - `15` + - :part:`59%` * - llvm/lib/ExecutionEngine/Orc/Shared - - `3` - - `3` + - `4` + - `4` - `0` - :good:`100%` * - llvm/lib/ExecutionEngine/Orc/TargetProcess - - `3` - - `3` - - `0` - - :good:`100%` + - `8` + - `7` + - `1` + - :part:`87%` * - llvm/lib/ExecutionEngine/PerfJITEvents - `1` - `0` @@ -4286,9 +4711,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - llvm/lib/Frontend/OpenMP - `3` - - `2` - - `1` - - :part:`66%` + - `3` + - `0` + - :good:`100%` * - llvm/lib/FuzzMutate - `5` - `2` @@ -4300,10 +4725,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - llvm/lib/IR - - `68` - - `17` - - `51` - - :part:`25%` + - `69` + - `20` + - `49` + - :part:`28%` * - llvm/lib/IRReader - `1` - `0` @@ -4320,65 +4745,95 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `3` - :none:`0%` * - llvm/lib/LTO - - `8` - - `1` - `7` - - :part:`12%` + - `1` + - `6` + - :part:`14%` * - llvm/lib/MC - - `63` + - `65` - `21` - - `42` - - :part:`33%` + - `44` + - :part:`32%` * - llvm/lib/MC/MCDisassembler - `6` - `3` - `3` - :part:`50%` * - llvm/lib/MC/MCParser - - `12` - - `1` + - `14` + - `3` - `11` - - :part:`8%` + - :part:`21%` * - llvm/lib/MCA + - `9` + - `8` + - `1` + - :part:`88%` + * - llvm/lib/MCA/HardwareUnits + - `6` + - `4` + - `2` + - :part:`66%` + * - llvm/lib/MCA/Stages + - `8` + - `7` + - `1` + - :part:`87%` + * - llvm/lib/ObjCopy + - `4` + - `3` + - `1` + - :part:`75%` + * - llvm/lib/ObjCopy/COFF + - `7` + - `7` + - `0` + - :good:`100%` + * - llvm/lib/ObjCopy/ELF + - `3` + - `3` + - `0` + - :good:`100%` + * - llvm/lib/ObjCopy/MachO + - `9` + - `9` + - `0` + - :good:`100%` + * - llvm/lib/ObjCopy/wasm - `7` - - `6` - - `1` - - :part:`85%` - * - llvm/lib/MCA/HardwareUnits + - `7` + - `0` + - :good:`100%` + * - llvm/lib/ObjCopy/XCOFF - `6` - `3` - `3` - :part:`50%` - * - llvm/lib/MCA/Stages - - `8` - - `8` - - `0` - - :good:`100%` * - llvm/lib/Object - `31` - - `15` - `16` - - :part:`48%` + - `15` + - :part:`51%` * - llvm/lib/ObjectYAML - - `22` - - `10` - - `12` - - :part:`45%` + - `23` + - `9` + - `14` + - :part:`39%` * - llvm/lib/Option - `4` - `0` - `4` - :none:`0%` * - llvm/lib/Passes - - `4` - - `2` - - `2` + - `6` + - `3` + - `3` - :part:`50%` * - llvm/lib/ProfileData - - `8` - - `3` - - `5` - - :part:`37%` + - `11` + - `4` + - `7` + - :part:`36%` * - llvm/lib/ProfileData/Coverage - `3` - `0` @@ -4390,30 +4845,30 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `3` - :part:`76%` * - llvm/lib/Support - - `136` - - `52` - - `84` - - :part:`38%` + - `144` + - `61` + - `83` + - :part:`42%` * - llvm/lib/Support/Unix - `1` - `0` - `1` - :none:`0%` * - llvm/lib/TableGen - - `13` - - `1` + - `15` + - `3` - `12` - - :part:`7%` + - :part:`20%` * - llvm/lib/Target - `5` - - `0` - - `5` - - :none:`0%` + - `1` + - `4` + - :part:`20%` * - llvm/lib/Target/AArch64 - - `59` - - `5` - - `54` - - :part:`8%` + - `60` + - `7` + - `53` + - :part:`11%` * - llvm/lib/Target/AArch64/AsmParser - `1` - `0` @@ -4426,9 +4881,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :part:`25%` * - llvm/lib/Target/AArch64/GISel - `14` - - `4` - - `10` - - :part:`28%` + - `3` + - `11` + - :part:`21%` * - llvm/lib/Target/AArch64/MCTargetDesc - `21` - `6` @@ -4445,10 +4900,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `2` - :none:`0%` * - llvm/lib/Target/AMDGPU - - `149` - - `21` - - `128` - - :part:`14%` + - `169` + - `38` + - `131` + - :part:`22%` * - llvm/lib/Target/AMDGPU/AsmParser - `1` - `0` @@ -4459,11 +4914,16 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - `2` - :none:`0%` + * - llvm/lib/Target/AMDGPU/MCA + - `2` + - `2` + - `0` + - :good:`100%` * - llvm/lib/Target/AMDGPU/MCTargetDesc - - `18` - - `3` - - `15` - - :part:`16%` + - `21` + - `5` + - `16` + - :part:`23%` * - llvm/lib/Target/AMDGPU/TargetInfo - `2` - `1` @@ -4495,10 +4955,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - llvm/lib/Target/ARM - - `75` - - `8` - - `67` - - :part:`10%` + - `76` + - `10` + - `66` + - :part:`13%` * - llvm/lib/Target/ARM/AsmParser - `1` - `0` @@ -4525,35 +4985,35 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `2` - :none:`0%` * - llvm/lib/Target/AVR + - `24` - `23` - - `4` - - `19` - - :part:`17%` + - `1` + - :part:`95%` * - llvm/lib/Target/AVR/AsmParser - `1` - - `0` - `1` - - :none:`0%` + - `0` + - :good:`100%` * - llvm/lib/Target/AVR/Disassembler - `1` - - `0` - `1` - - :none:`0%` + - `0` + - :good:`100%` * - llvm/lib/Target/AVR/MCTargetDesc - `20` - - `6` - - `14` - - :part:`30%` + - `18` + - `2` + - :part:`90%` * - llvm/lib/Target/AVR/TargetInfo - `2` - - `1` - - `1` - - :part:`50%` + - `2` + - `0` + - :good:`100%` * - llvm/lib/Target/BPF - - `31` - - `8` + - `32` + - `9` - `23` - - :part:`25%` + - :part:`28%` * - llvm/lib/Target/BPF/AsmParser - `1` - `0` @@ -4575,8 +5035,8 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - :part:`50%` * - llvm/lib/Target/CSKY - - `2` - - `2` + - `23` + - `23` - `0` - :good:`100%` * - llvm/lib/Target/CSKY/AsmParser @@ -4584,11 +5044,16 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` - * - llvm/lib/Target/CSKY/MCTargetDesc - - `14` - - `14` + * - llvm/lib/Target/CSKY/Disassembler + - `1` + - `1` - `0` - :good:`100%` + * - llvm/lib/Target/CSKY/MCTargetDesc + - `15` + - `14` + - `1` + - :part:`93%` * - llvm/lib/Target/CSKY/TargetInfo - `2` - `2` @@ -4596,9 +5061,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - llvm/lib/Target/Hexagon - `80` - - `4` - - `76` - - :part:`5%` + - `6` + - `74` + - :part:`7%` * - llvm/lib/Target/Hexagon/AsmParser - `1` - `0` @@ -4621,9 +5086,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :part:`50%` * - llvm/lib/Target/Lanai - `28` - - `19` - - `9` - - :part:`67%` + - `20` + - `8` + - :part:`71%` * - llvm/lib/Target/Lanai/AsmParser - `1` - `0` @@ -4644,6 +5109,21 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `2` - `0` - :good:`100%` + * - llvm/lib/Target/LoongArch + - `19` + - `19` + - `0` + - :good:`100%` + * - llvm/lib/Target/LoongArch/MCTargetDesc + - `12` + - `12` + - `0` + - :good:`100%` + * - llvm/lib/Target/LoongArch/TargetInfo + - `2` + - `2` + - `0` + - :good:`100%` * - llvm/lib/Target/M68k - `26` - `25` @@ -4659,21 +5139,26 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` + * - llvm/lib/Target/M68k/GISel + - `7` + - `6` + - `1` + - :part:`85%` * - llvm/lib/Target/M68k/MCTargetDesc - `12` - - `12` - - `0` - - :good:`100%` + - `11` + - `1` + - :part:`91%` * - llvm/lib/Target/M68k/TargetInfo - `2` - `2` - `0` - :good:`100%` * - llvm/lib/Target/Mips - - `69` - - `11` + - `70` + - `12` - `58` - - :part:`15%` + - :part:`17%` * - llvm/lib/Target/Mips/AsmParser - `1` - `0` @@ -4721,24 +5206,24 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - llvm/lib/Target/NVPTX - `44` - - `9` - - `35` - - :part:`20%` + - `10` + - `34` + - :part:`22%` * - llvm/lib/Target/NVPTX/MCTargetDesc - `9` - - `5` - - `4` - - :part:`55%` + - `6` + - `3` + - :part:`66%` * - llvm/lib/Target/NVPTX/TargetInfo - `2` - `2` - `0` - :good:`100%` * - llvm/lib/Target/PowerPC - - `52` - - `3` + - `54` + - `5` - `49` - - :part:`5%` + - :part:`9%` * - llvm/lib/Target/PowerPC/AsmParser - `1` - `0` @@ -4765,10 +5250,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - llvm/lib/Target/RISCV - - `33` - - `18` - - `15` - - :part:`54%` + - `36` + - `17` + - `19` + - :part:`47%` * - llvm/lib/Target/RISCV/AsmParser - `1` - `0` @@ -4780,10 +5265,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - :none:`0%` * - llvm/lib/Target/RISCV/MCTargetDesc - - `21` - - `11` + - `23` + - `13` - `10` - - :part:`52%` + - :part:`56%` * - llvm/lib/Target/RISCV/TargetInfo - `2` - `2` @@ -4791,9 +5276,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - llvm/lib/Target/Sparc - `23` - - `2` - - `21` - - :part:`8%` + - `3` + - `20` + - :part:`13%` * - llvm/lib/Target/Sparc/AsmParser - `1` - `0` @@ -4815,10 +5300,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - llvm/lib/Target/SystemZ - - `40` - - `5` + - `41` + - `6` - `35` - - :part:`12%` + - :part:`14%` * - llvm/lib/Target/SystemZ/AsmParser - `1` - `0` @@ -4840,10 +5325,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - llvm/lib/Target/VE - - `21` - - `17` - - `4` - - :part:`80%` + - `24` + - `19` + - `5` + - :part:`79%` * - llvm/lib/Target/VE/AsmParser - `1` - `1` @@ -4856,23 +5341,23 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - llvm/lib/Target/VE/MCTargetDesc - `14` - - `13` - - `1` - - :part:`92%` + - `14` + - `0` + - :good:`100%` * - llvm/lib/Target/VE/TargetInfo - `2` - `1` - `1` - :part:`50%` * - llvm/lib/Target/WebAssembly - - `59` - - `43` - - `16` + - `61` + - `44` + - `17` - :part:`72%` * - llvm/lib/Target/WebAssembly/AsmParser - - `1` + - `3` - `0` - - `1` + - `3` - :none:`0%` * - llvm/lib/Target/WebAssembly/Disassembler - `1` @@ -4896,9 +5381,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - llvm/lib/Target/X86 - `82` - - `18` - - `64` - - :part:`21%` + - `19` + - `63` + - :part:`23%` * - llvm/lib/Target/X86/AsmParser - `3` - `0` @@ -4909,6 +5394,11 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - `2` - :none:`0%` + * - llvm/lib/Target/X86/MCA + - `2` + - `2` + - `0` + - :good:`100%` * - llvm/lib/Target/X86/MCTargetDesc - `25` - `5` @@ -4946,9 +5436,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - llvm/lib/TextAPI - `11` - - `11` - - `0` - - :good:`100%` + - `9` + - `2` + - :part:`81%` * - llvm/lib/ToolDrivers/llvm-dlltool - `1` - `0` @@ -4961,9 +5451,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :none:`0%` * - llvm/lib/Transforms/AggressiveInstCombine - `3` - - `0` - - `3` - - :none:`0%` + - `1` + - `2` + - :part:`33%` * - llvm/lib/Transforms/CFGuard - `1` - `1` @@ -4985,35 +5475,40 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `15` - :part:`6%` * - llvm/lib/Transforms/Instrumentation - - `22` - - `6` - - `16` - - :part:`27%` + - `21` + - `7` + - `14` + - :part:`33%` * - llvm/lib/Transforms/IPO - - `42` + - `44` - `9` - - `33` - - :part:`21%` + - `35` + - :part:`20%` * - llvm/lib/Transforms/ObjCARC - `15` - `4` - `11` - :part:`26%` * - llvm/lib/Transforms/Scalar - - `78` - - `13` - - `65` - - :part:`16%` + - `79` + - `16` + - `63` + - :part:`20%` * - llvm/lib/Transforms/Utils - - `75` - - `17` - - `58` - - :part:`22%` + - `78` + - `19` + - `59` + - :part:`24%` * - llvm/lib/Transforms/Vectorize - `22` - - `12` - - `10` - - :part:`54%` + - `13` + - `9` + - :part:`59%` + * - llvm/lib/WindowsDriver + - `1` + - `1` + - `0` + - :good:`100%` * - llvm/lib/WindowsManifest - `1` - `1` @@ -5036,9 +5531,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :none:`0%` * - llvm/tools/dsymutil - `18` - - `15` - - `3` - - :part:`83%` + - `16` + - `2` + - :part:`88%` * - llvm/tools/gold - `1` - `0` @@ -5051,9 +5546,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :none:`0%` * - llvm/tools/lli - `4` - - `2` - - `2` - - :part:`50%` + - `3` + - `1` + - :part:`75%` * - llvm/tools/lli/ChildTarget - `1` - `1` @@ -5071,9 +5566,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :none:`0%` * - llvm/tools/llvm-as-fuzzer - `1` - - `0` - `1` - - :none:`0%` + - `0` + - :good:`100%` * - llvm/tools/llvm-bcanalyzer - `1` - `1` @@ -5116,49 +5611,64 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :none:`0%` * - llvm/tools/llvm-cxxdump - `4` - - `2` - - `2` - - :part:`50%` + - `1` + - `3` + - :part:`25%` * - llvm/tools/llvm-cxxfilt - `1` - - `0` - `1` - - :none:`0%` + - `0` + - :good:`100%` * - llvm/tools/llvm-cxxmap - `1` - `0` - `1` - :none:`0%` + * - llvm/tools/llvm-debuginfod-find + - `1` + - `1` + - `0` + - :good:`100%` * - llvm/tools/llvm-diff - - `7` + - `1` - `0` - - `7` + - `1` + - :none:`0%` + * - llvm/tools/llvm-diff/lib + - `6` + - `0` + - `6` - :none:`0%` * - llvm/tools/llvm-dis - `1` - `0` - `1` - :none:`0%` - * - llvm/tools/llvm-dwarfdump - - `4` + * - llvm/tools/llvm-dis-fuzzer + - `1` + - `1` + - `0` + - :good:`100%` + * - llvm/tools/llvm-dlang-demangle-fuzzer - `2` - `2` - - :part:`50%` + - `0` + - :good:`100%` + * - llvm/tools/llvm-dwarfdump + - `4` + - `3` + - `1` + - :part:`75%` * - llvm/tools/llvm-dwarfdump/fuzzer - `1` - `0` - `1` - :none:`0%` * - llvm/tools/llvm-dwp - - `4` - `1` - - `3` - - :part:`25%` - * - llvm/tools/llvm-elfabi - - `3` - - `3` - `0` - - :good:`100%` + - `1` + - :none:`0%` * - llvm/tools/llvm-exegesis - `1` - `0` @@ -5166,9 +5676,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :none:`0%` * - llvm/tools/llvm-exegesis/lib - `44` - - `35` - - `9` - - :part:`79%` + - `33` + - `11` + - :part:`75%` * - llvm/tools/llvm-exegesis/lib/AArch64 - `1` - `1` @@ -5200,10 +5710,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - llvm/tools/llvm-ifs + - `3` + - `2` - `1` - - `1` - - `0` - - :good:`100%` + - :part:`66%` * - llvm/tools/llvm-isel-fuzzer - `2` - `1` @@ -5271,14 +5781,14 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :none:`0%` * - llvm/tools/llvm-mca - `7` - - `6` - - `1` - - :part:`85%` + - `7` + - `0` + - :good:`100%` * - llvm/tools/llvm-mca/Views - - `22` - - `13` - - `9` - - :part:`59%` + - `20` + - `19` + - `1` + - :part:`95%` * - llvm/tools/llvm-microsoft-demangle-fuzzer - `2` - `2` @@ -5305,30 +5815,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - :none:`0%` * - llvm/tools/llvm-objcopy - - `6` - - `4` - - `2` - - :part:`66%` - * - llvm/tools/llvm-objcopy/COFF - - `9` - - `9` - - `0` - - :good:`100%` - * - llvm/tools/llvm-objcopy/ELF - - `5` - `3` - `2` - - :part:`60%` - * - llvm/tools/llvm-objcopy/MachO - - `11` - - `11` - - `0` - - :good:`100%` - * - llvm/tools/llvm-objcopy/wasm - - `9` - - `9` - - `0` - - :good:`100%` + - `1` + - :part:`66%` * - llvm/tools/llvm-objdump - `15` - `10` @@ -5355,10 +5845,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - :none:`0%` * - llvm/tools/llvm-profgen - - `13` - - `12` - - `1` - - :part:`92%` + - `11` + - `6` + - `5` + - :part:`54%` * - llvm/tools/llvm-rc - `12` - `6` @@ -5366,19 +5856,24 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :part:`50%` * - llvm/tools/llvm-readobj - `19` - - `4` - - `15` - - :part:`21%` + - `3` + - `16` + - :part:`15%` * - llvm/tools/llvm-reduce - - `5` - - `4` + - `7` + - `6` - `1` - - :part:`80%` + - :part:`85%` * - llvm/tools/llvm-reduce/deltas - - `30` - - `28` - - `2` - - :part:`93%` + - `40` + - `39` + - `1` + - :part:`97%` + * - llvm/tools/llvm-remark-size-diff + - `1` + - `1` + - `0` + - :good:`100%` * - llvm/tools/llvm-rtdyld - `1` - `0` @@ -5394,6 +5889,11 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` + * - llvm/tools/llvm-sim + - `1` + - `0` + - `1` + - :none:`0%` * - llvm/tools/llvm-size - `1` - `0` @@ -5416,14 +5916,24 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :none:`0%` * - llvm/tools/llvm-strings - `1` - - `0` - `1` - - :none:`0%` + - `0` + - :good:`100%` * - llvm/tools/llvm-symbolizer - `1` + - `0` - `1` + - :none:`0%` + * - llvm/tools/llvm-tapi-diff + - `3` + - `3` - `0` - :good:`100%` + * - llvm/tools/llvm-tli-checker + - `1` + - `0` + - `1` + - :none:`0%` * - llvm/tools/llvm-undname - `1` - `1` @@ -5475,10 +5985,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - llvm/tools/split-file - - `1` - `1` - `0` - - :good:`100%` + - `1` + - :none:`0%` * - llvm/tools/verify-uselistorder - `1` - `0` @@ -5496,14 +6006,14 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - llvm/unittests/ADT - `77` - - `31` - - `46` - - :part:`40%` + - `29` + - `48` + - :part:`37%` * - llvm/unittests/Analysis - - `36` - - `10` - - `26` - - :part:`27%` + - `38` + - `13` + - `25` + - :part:`34%` * - llvm/unittests/AsmParser - `1` - `1` @@ -5525,25 +6035,25 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - :part:`50%` * - llvm/unittests/CodeGen - - `17` - - `8` - - `9` - - :part:`47%` + - `20` + - `10` + - `10` + - :part:`50%` * - llvm/unittests/CodeGen/GlobalISel - - `12` + - `13` - `2` - - `10` - - :part:`16%` + - `11` + - :part:`15%` * - llvm/unittests/DebugInfo/CodeView - - `3` - - `1` + - `4` - `2` - - :part:`33%` + - `2` + - :part:`50%` * - llvm/unittests/DebugInfo/DWARF - - `16` - - `10` - - `6` - - :part:`62%` + - `17` + - `13` + - `4` + - :part:`76%` * - llvm/unittests/DebugInfo/GSYM - `1` - `0` @@ -5564,11 +6074,16 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` + * - llvm/unittests/Debuginfod + - `2` + - `2` + - `0` + - :good:`100%` * - llvm/unittests/Demangle + - `7` - `5` - - `3` - `2` - - :part:`60%` + - :part:`71%` * - llvm/unittests/ExecutionEngine - `1` - `0` @@ -5585,10 +6100,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `7` - :none:`0%` * - llvm/unittests/ExecutionEngine/Orc - - `15` - - `6` - - `9` - - :part:`40%` + - `21` + - `14` + - `7` + - :part:`66%` * - llvm/unittests/FileCheck - `1` - `0` @@ -5625,10 +6140,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - :none:`0%` * - llvm/unittests/MC - - `6` - - `3` + - `7` + - `4` - `3` - - :part:`50%` + - :part:`57%` * - llvm/unittests/MC/AMDGPU - `1` - `1` @@ -5644,6 +6159,16 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - `1` - :none:`0%` + * - llvm/unittests/MIR + - `1` + - `0` + - `1` + - :none:`0%` + * - llvm/unittests/ObjCopy + - `1` + - `1` + - `0` + - :good:`100%` * - llvm/unittests/Object - `9` - `6` @@ -5660,50 +6185,55 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - :part:`50%` * - llvm/unittests/Passes - - `4` - - `4` + - `5` + - `5` - `0` - :good:`100%` * - llvm/unittests/ProfileData - - `4` - - `1` + - `5` + - `2` - `3` - - :part:`25%` + - :part:`40%` * - llvm/unittests/Remarks - `8` - `5` - `3` - :part:`62%` * - llvm/unittests/Support - - `95` - - `30` + - `100` + - `35` - `65` - - :part:`31%` + - :part:`35%` + * - llvm/unittests/Support/CommandLineInit + - `1` + - `1` + - `0` + - :good:`100%` * - llvm/unittests/Support/DynamicLibrary - `4` - `0` - `4` - :none:`0%` * - llvm/unittests/TableGen + - `3` + - `1` - `2` - - `0` - - `2` - - :none:`0%` + - :part:`33%` * - llvm/unittests/Target/AArch64 + - `3` + - `1` - `2` - - `0` - - `2` - - :none:`0%` + - :part:`33%` * - llvm/unittests/Target/AMDGPU - `2` - `2` - `0` - :good:`100%` * - llvm/unittests/Target/ARM + - `2` - `1` - - `0` - `1` - - :none:`0%` + - :part:`50%` * - llvm/unittests/Target/PowerPC - `1` - `1` @@ -5719,6 +6249,11 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - `1` - :none:`0%` + * - llvm/unittests/Testing/Support + - `1` + - `1` + - `0` + - :good:`100%` * - llvm/unittests/TextAPI - `5` - `3` @@ -5730,10 +6265,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - :part:`50%` * - llvm/unittests/tools/llvm-exegesis - - `5` - `4` + - `3` - `1` - - :part:`80%` + - :part:`75%` * - llvm/unittests/tools/llvm-exegesis/AArch64 - `1` - `1` @@ -5751,19 +6286,19 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - llvm/unittests/tools/llvm-exegesis/Mips - `5` - - `4` - - `1` - - :part:`80%` + - `3` + - `2` + - :part:`60%` * - llvm/unittests/tools/llvm-exegesis/PowerPC - `4` - - `2` - - `2` - - :part:`50%` + - `1` + - `3` + - :part:`25%` * - llvm/unittests/tools/llvm-exegesis/X86 - `9` - - `8` - - `1` - - :part:`88%` + - `6` + - `3` + - :part:`66%` * - llvm/unittests/tools/llvm-profgen - `1` - `0` @@ -5794,21 +6329,6 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `7` - `1` - :part:`87%` - * - llvm/utils/benchmark/cmake - - `5` - - `3` - - `2` - - :part:`60%` - * - llvm/utils/benchmark/include/benchmark - - `1` - - `0` - - `1` - - :none:`0%` - * - llvm/utils/benchmark/src - - `19` - - `0` - - `19` - - :none:`0%` * - llvm/utils/FileCheck - `1` - `0` @@ -5835,15 +6355,15 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - :none:`0%` * - llvm/utils/TableGen - - `76` - - `10` - - `66` - - :part:`13%` + - `78` + - `13` + - `65` + - :part:`16%` * - llvm/utils/TableGen/GlobalISel - `17` - - `8` - - `9` - - :part:`47%` + - `10` + - `7` + - :part:`58%` * - llvm/utils/unittest/googlemock/include/gmock - `12` - `0` @@ -5894,11 +6414,26 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `2` - `0` - :good:`100%` + * - mlir/examples/standalone/include/Standalone-c + - `1` + - `1` + - `0` + - :good:`100%` + * - mlir/examples/standalone/lib/CAPI + - `1` + - `1` + - `0` + - :good:`100%` * - mlir/examples/standalone/lib/Standalone - `2` - `2` - `0` - :good:`100%` + * - mlir/examples/standalone/python + - `1` + - `1` + - `0` + - :good:`100%` * - mlir/examples/standalone/standalone-opt - `1` - `1` @@ -6050,28 +6585,28 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - mlir/include/mlir/Analysis - - `14` - - `12` + - `7` + - `5` - `2` - - :part:`85%` + - :part:`71%` * - mlir/include/mlir/Analysis/AliasAnalysis - `1` - `1` - `0` - :good:`100%` * - mlir/include/mlir/Analysis/Presburger - - `3` - - `3` + - `9` + - `9` - `0` - :good:`100%` * - mlir/include/mlir/Bindings/Python - - `1` - `1` - `0` - - :good:`100%` + - `1` + - :none:`0%` * - mlir/include/mlir/CAPI - - `11` - - `11` + - `12` + - `12` - `0` - :good:`100%` * - mlir/include/mlir/Conversion @@ -6084,11 +6619,31 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` + * - mlir/include/mlir/Conversion/ArithmeticToLLVM + - `1` + - `1` + - `0` + - :good:`100%` + * - mlir/include/mlir/Conversion/ArithmeticToSPIRV + - `1` + - `1` + - `0` + - :good:`100%` + * - mlir/include/mlir/Conversion/ArmNeon2dToIntr + - `1` + - `1` + - `0` + - :good:`100%` * - mlir/include/mlir/Conversion/AsyncToLLVM - `1` - `1` - `0` - :good:`100%` + * - mlir/include/mlir/Conversion/BufferizationToMemRef + - `1` + - `1` + - `0` + - :good:`100%` * - mlir/include/mlir/Conversion/ComplexToLLVM - `1` - `1` @@ -6099,6 +6654,21 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` + * - mlir/include/mlir/Conversion/ControlFlowToLLVM + - `1` + - `1` + - `0` + - :good:`100%` + * - mlir/include/mlir/Conversion/ControlFlowToSPIRV + - `2` + - `2` + - `0` + - :good:`100%` + * - mlir/include/mlir/Conversion/FuncToSPIRV + - `2` + - `2` + - `0` + - :good:`100%` * - mlir/include/mlir/Conversion/GPUCommon - `1` - `1` @@ -6110,8 +6680,8 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - mlir/include/mlir/Conversion/GPUToROCDL - - `1` - - `1` + - `2` + - `2` - `0` - :good:`100%` * - mlir/include/mlir/Conversion/GPUToSPIRV @@ -6139,16 +6709,46 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` + * - mlir/include/mlir/Conversion/LLVMCommon + - `7` + - `7` + - `0` + - :good:`100%` * - mlir/include/mlir/Conversion/MathToLibm - `1` - `1` - `0` - :good:`100%` + * - mlir/include/mlir/Conversion/MathToLLVM + - `1` + - `1` + - `0` + - :good:`100%` + * - mlir/include/mlir/Conversion/MathToSPIRV + - `2` + - `2` + - `0` + - :good:`100%` + * - mlir/include/mlir/Conversion/MemRefToLLVM + - `2` + - `2` + - `0` + - :good:`100%` + * - mlir/include/mlir/Conversion/MemRefToSPIRV + - `2` + - `2` + - `0` + - :good:`100%` * - mlir/include/mlir/Conversion/OpenACCToLLVM - `1` - `1` - `0` - :good:`100%` + * - mlir/include/mlir/Conversion/OpenACCToSCF + - `1` + - `1` + - `0` + - :good:`100%` * - mlir/include/mlir/Conversion/OpenMPToLLVM - `1` - `1` @@ -6159,6 +6759,16 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` + * - mlir/include/mlir/Conversion/ReconcileUnrealizedCasts + - `1` + - `1` + - `0` + - :good:`100%` + * - mlir/include/mlir/Conversion/SCFToControlFlow + - `1` + - `1` + - `0` + - :good:`100%` * - mlir/include/mlir/Conversion/SCFToGPU - `2` - `2` @@ -6174,11 +6784,6 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `2` - `0` - :good:`100%` - * - mlir/include/mlir/Conversion/SCFToStandard - - `1` - - `1` - - `0` - - :good:`100%` * - mlir/include/mlir/Conversion/ShapeToStandard - `1` - `1` @@ -6194,7 +6799,7 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `2` - `0` - :good:`100%` - * - mlir/include/mlir/Conversion/StandardToSPIRV + * - mlir/include/mlir/Conversion/TensorToSPIRV - `2` - `2` - `0` @@ -6214,12 +6819,12 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` - * - mlir/include/mlir/Conversion/VectorToLLVM + * - mlir/include/mlir/Conversion/VectorToGPU - `1` - `1` - `0` - :good:`100%` - * - mlir/include/mlir/Conversion/VectorToROCDL + * - mlir/include/mlir/Conversion/VectorToLLVM - `1` - `1` - `0` @@ -6240,8 +6845,13 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - mlir/include/mlir/Dialect/Affine - - `2` - - `2` + - `4` + - `4` + - `0` + - :good:`100%` + * - mlir/include/mlir/Dialect/Affine/Analysis + - `5` + - `5` - `0` - :good:`100%` * - mlir/include/mlir/Dialect/Affine/IR @@ -6254,34 +6864,79 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `2` - `0` - :good:`100%` - * - mlir/include/mlir/Dialect/ArmNeon + * - mlir/include/mlir/Dialect/Arithmetic/IR + - `1` + - `1` + - `0` + - :good:`100%` + * - mlir/include/mlir/Dialect/Arithmetic/Transforms + - `2` + - `2` + - `0` + - :good:`100%` + * - mlir/include/mlir/Dialect/Arithmetic/Utils + - `1` + - `1` + - `0` + - :good:`100%` + * - mlir/include/mlir/Dialect/ArmNeon + - `1` + - `1` + - `0` + - :good:`100%` + * - mlir/include/mlir/Dialect/ArmSVE + - `2` + - `2` + - `0` + - :good:`100%` + * - mlir/include/mlir/Dialect/Async + - `2` + - `2` + - `0` + - :good:`100%` + * - mlir/include/mlir/Dialect/Async/IR + - `2` + - `2` + - `0` + - :good:`100%` + * - mlir/include/mlir/Dialect/Bufferization/IR + - `3` + - `3` + - `0` + - :good:`100%` + * - mlir/include/mlir/Dialect/Bufferization/Transforms + - `4` + - `4` + - `0` + - :good:`100%` + * - mlir/include/mlir/Dialect/Complex/IR - `1` - `1` - `0` - :good:`100%` - * - mlir/include/mlir/Dialect/ArmSVE + * - mlir/include/mlir/Dialect/ControlFlow/IR - `2` - `2` - `0` - :good:`100%` - * - mlir/include/mlir/Dialect/Async - - `1` - - `1` - - `0` - - :good:`100%` - * - mlir/include/mlir/Dialect/Async/IR + * - mlir/include/mlir/Dialect/DLTI - `2` - `2` - `0` - :good:`100%` - * - mlir/include/mlir/Dialect/Complex/IR + * - mlir/include/mlir/Dialect/EmitC/IR - `1` - `1` - `0` - :good:`100%` - * - mlir/include/mlir/Dialect/DLTI - - `2` - - `2` + * - mlir/include/mlir/Dialect/Func/IR + - `1` + - `1` + - `0` + - :good:`100%` + * - mlir/include/mlir/Dialect/Func/Transforms + - `3` + - `3` - `0` - :good:`100%` * - mlir/include/mlir/Dialect/GPU @@ -6299,14 +6954,19 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` + * - mlir/include/mlir/Dialect/Linalg/ComprehensiveBufferize + - `2` + - `2` + - `0` + - :good:`100%` * - mlir/include/mlir/Dialect/Linalg/IR - - `3` - - `3` + - `2` + - `2` - `0` - :good:`100%` * - mlir/include/mlir/Dialect/Linalg/Transforms - - `3` - - `3` + - `5` + - `5` - `0` - :good:`100%` * - mlir/include/mlir/Dialect/Linalg/Utils @@ -6330,8 +6990,8 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - mlir/include/mlir/Dialect/Math/Transforms - - `1` - - `1` + - `2` + - `2` - `0` - :good:`100%` * - mlir/include/mlir/Dialect/MemRef/IR @@ -6340,8 +7000,8 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - mlir/include/mlir/Dialect/MemRef/Transforms - - `1` - - `1` + - `2` + - `2` - `0` - :good:`100%` * - mlir/include/mlir/Dialect/MemRef/Utils @@ -6376,14 +7036,14 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - mlir/include/mlir/Dialect/SCF - `4` + - `4` + - `0` + - :good:`100%` + * - mlir/include/mlir/Dialect/SCF/Utils - `2` - `2` - - :part:`50%` - * - mlir/include/mlir/Dialect/SDBM - - `3` - - `2` - - `1` - - :part:`66%` + - `0` + - :good:`100%` * - mlir/include/mlir/Dialect/Shape/IR - `1` - `1` @@ -6399,11 +7059,21 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` + * - mlir/include/mlir/Dialect/SparseTensor/Pipelines + - `1` + - `1` + - `0` + - :good:`100%` * - mlir/include/mlir/Dialect/SparseTensor/Transforms - `1` - `1` - `0` - :good:`100%` + * - mlir/include/mlir/Dialect/SparseTensor/Utils + - `1` + - `1` + - `0` + - :good:`100%` * - mlir/include/mlir/Dialect/SPIRV/IR - `9` - `9` @@ -6424,27 +7094,17 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` - * - mlir/include/mlir/Dialect/StandardOps/IR - - `1` - - `1` - - `0` - - :good:`100%` - * - mlir/include/mlir/Dialect/StandardOps/Transforms - - `4` - - `4` - - `0` - - :good:`100%` - * - mlir/include/mlir/Dialect/StandardOps/Utils - - `1` - - `1` - - `0` - - :good:`100%` * - mlir/include/mlir/Dialect/Tensor/IR - - `1` - - `1` + - `3` + - `3` - `0` - :good:`100%` * - mlir/include/mlir/Dialect/Tensor/Transforms + - `3` + - `3` + - `0` + - :good:`100%` + * - mlir/include/mlir/Dialect/Tensor/Utils - `1` - `1` - `0` @@ -6460,18 +7120,28 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - mlir/include/mlir/Dialect/Tosa/Utils - - `1` - - `1` + - `3` + - `3` - `0` - :good:`100%` * - mlir/include/mlir/Dialect/Utils + - `4` + - `4` + - `0` + - :good:`100%` + * - mlir/include/mlir/Dialect/Vector/IR - `1` - `1` - `0` - :good:`100%` - * - mlir/include/mlir/Dialect/Vector - - `3` - - `3` + * - mlir/include/mlir/Dialect/Vector/Transforms + - `4` + - `4` + - `0` + - :good:`100%` + * - mlir/include/mlir/Dialect/Vector/Utils + - `1` + - `1` - `0` - :good:`100%` * - mlir/include/mlir/Dialect/X86Vector @@ -6480,20 +7150,20 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - mlir/include/mlir/ExecutionEngine + - `8` - `7` - - `5` - - `2` - - :part:`71%` + - `1` + - :part:`87%` * - mlir/include/mlir/Interfaces + - `14` - `13` - - `12` - `1` - :part:`92%` * - mlir/include/mlir/IR - - `47` - - `25` - - `22` - - :part:`53%` + - `49` + - `29` + - `20` + - :part:`59%` * - mlir/include/mlir/Parser - `1` - `1` @@ -6516,19 +7186,24 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - mlir/include/mlir/Support - `15` - - `8` - - `7` - - :part:`53%` + - `9` + - `6` + - :part:`60%` * - mlir/include/mlir/TableGen - `21` - - `20` + - `19` + - `2` + - :part:`90%` + * - mlir/include/mlir/Target/Cpp - `1` - - :part:`95%` - * - mlir/include/mlir/Target/LLVMIR - - `5` - - `4` - `1` - - :part:`80%` + - `0` + - :good:`100%` + * - mlir/include/mlir/Target/LLVMIR + - `6` + - `6` + - `0` + - :good:`100%` * - mlir/include/mlir/Target/LLVMIR/Dialect - `1` - `1` @@ -6594,14 +7269,34 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` + * - mlir/include/mlir/Tools/PDLL/AST + - `4` + - `2` + - `2` + - :part:`50%` + * - mlir/include/mlir/Tools/PDLL/CodeGen + - `2` + - `2` + - `0` + - :good:`100%` + * - mlir/include/mlir/Tools/PDLL/ODS + - `4` + - `4` + - `0` + - :good:`100%` + * - mlir/include/mlir/Tools/PDLL/Parser + - `1` + - `1` + - `0` + - :good:`100%` * - mlir/include/mlir/Transforms - - `14` - `9` - - `5` - - :part:`64%` + - `7` + - `2` + - :part:`77%` * - mlir/include/mlir-c - - `14` - - `14` + - `15` + - `15` - `0` - :good:`100%` * - mlir/include/mlir-c/Bindings/Python @@ -6610,28 +7305,28 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - mlir/include/mlir-c/Dialect - - `8` - - `8` + - `11` + - `11` - `0` - :good:`100%` * - mlir/lib/Analysis - - `14` - - `13` - - `1` - - :part:`92%` + - `7` + - `7` + - `0` + - :good:`100%` * - mlir/lib/Analysis/AliasAnalysis - `1` - `1` - `0` - :good:`100%` * - mlir/lib/Analysis/Presburger - - `2` - - `2` + - `8` + - `8` - `0` - :good:`100%` * - mlir/lib/Bindings/Python - - `22` - - `22` + - `23` + - `23` - `0` - :good:`100%` * - mlir/lib/Bindings/Python/Conversions @@ -6655,8 +7350,8 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - mlir/lib/CAPI/Dialect - - `12` - - `12` + - `15` + - `15` - `0` - :good:`100%` * - mlir/lib/CAPI/ExecutionEngine @@ -6664,6 +7359,11 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` + * - mlir/lib/CAPI/Interfaces + - `1` + - `1` + - `0` + - :good:`100%` * - mlir/lib/CAPI/IR - `10` - `10` @@ -6689,11 +7389,31 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` + * - mlir/lib/Conversion/ArithmeticToLLVM + - `1` + - `1` + - `0` + - :good:`100%` + * - mlir/lib/Conversion/ArithmeticToSPIRV + - `1` + - `1` + - `0` + - :good:`100%` + * - mlir/lib/Conversion/ArmNeon2dToIntr + - `1` + - `1` + - `0` + - :good:`100%` * - mlir/lib/Conversion/AsyncToLLVM - `1` - `1` - `0` - :good:`100%` + * - mlir/lib/Conversion/BufferizationToMemRef + - `1` + - `0` + - `1` + - :none:`0%` * - mlir/lib/Conversion/ComplexToLLVM - `1` - `1` @@ -6704,64 +7424,119 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` + * - mlir/lib/Conversion/ControlFlowToLLVM + - `1` + - `1` + - `0` + - :good:`100%` + * - mlir/lib/Conversion/ControlFlowToSPIRV + - `2` + - `2` + - `0` + - :good:`100%` + * - mlir/lib/Conversion/FuncToSPIRV + - `2` + - `2` + - `0` + - :good:`100%` * - mlir/lib/Conversion/GPUCommon - `5` - - `5` + - `4` + - `1` + - :part:`80%` + * - mlir/lib/Conversion/GPUToNVVM + - `2` + - `2` - `0` - :good:`100%` - * - mlir/lib/Conversion/GPUToNVVM + * - mlir/lib/Conversion/GPUToROCDL + - `1` + - `1` + - `0` + - :good:`100%` + * - mlir/lib/Conversion/GPUToSPIRV - `2` - `2` - `0` - :good:`100%` - * - mlir/lib/Conversion/GPUToROCDL + * - mlir/lib/Conversion/GPUToVulkan + - `2` + - `2` + - `0` + - :good:`100%` + * - mlir/lib/Conversion/LinalgToLLVM + - `1` + - `1` + - `0` + - :good:`100%` + * - mlir/lib/Conversion/LinalgToSPIRV + - `2` + - `1` + - `1` + - :part:`50%` + * - mlir/lib/Conversion/LinalgToStandard + - `1` + - `0` + - `1` + - :none:`0%` + * - mlir/lib/Conversion/LLVMCommon + - `8` + - `8` + - `0` + - :good:`100%` + * - mlir/lib/Conversion/MathToLibm - `1` - `1` - `0` - :good:`100%` - * - mlir/lib/Conversion/GPUToSPIRV - - `2` - - `2` + * - mlir/lib/Conversion/MathToLLVM + - `1` + - `1` - `0` - :good:`100%` - * - mlir/lib/Conversion/GPUToVulkan + * - mlir/lib/Conversion/MathToSPIRV - `2` - `2` - `0` - :good:`100%` - * - mlir/lib/Conversion/LinalgToLLVM - - `1` - - `1` + * - mlir/lib/Conversion/MemRefToLLVM + - `2` + - `2` - `0` - :good:`100%` - * - mlir/lib/Conversion/LinalgToSPIRV + * - mlir/lib/Conversion/MemRefToSPIRV - `2` - `2` - `0` - :good:`100%` - * - mlir/lib/Conversion/LinalgToStandard + * - mlir/lib/Conversion/OpenACCToLLVM - `1` - `1` - `0` - :good:`100%` - * - mlir/lib/Conversion/MathToLibm + * - mlir/lib/Conversion/OpenACCToSCF - `1` - `1` - `0` - :good:`100%` - * - mlir/lib/Conversion/OpenACCToLLVM + * - mlir/lib/Conversion/OpenMPToLLVM - `1` - `1` - `0` - :good:`100%` - * - mlir/lib/Conversion/OpenMPToLLVM + * - mlir/lib/Conversion/PDLToPDLInterp + - `7` + - `7` + - `0` + - :good:`100%` + * - mlir/lib/Conversion/ReconcileUnrealizedCasts - `1` - `1` - `0` - :good:`100%` - * - mlir/lib/Conversion/PDLToPDLInterp - - `5` - - `5` + * - mlir/lib/Conversion/SCFToControlFlow + - `1` + - `1` - `0` - :good:`100%` * - mlir/lib/Conversion/SCFToGPU @@ -6779,16 +7554,16 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `2` - `0` - :good:`100%` - * - mlir/lib/Conversion/SCFToStandard - - `1` - - `1` - - `0` - - :good:`100%` * - mlir/lib/Conversion/ShapeToStandard - `2` - `2` - `0` - :good:`100%` + * - mlir/lib/Conversion/SPIRVCommon + - `1` + - `1` + - `0` + - :good:`100%` * - mlir/lib/Conversion/SPIRVToLLVM - `3` - `3` @@ -6796,19 +7571,19 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - mlir/lib/Conversion/StandardToLLVM - `1` - - `0` - `1` - - :none:`0%` - * - mlir/lib/Conversion/StandardToSPIRV + - `0` + - :good:`100%` + * - mlir/lib/Conversion/TensorToSPIRV - `2` - `2` - `0` - :good:`100%` * - mlir/lib/Conversion/TosaToLinalg - - `2` + - `4` + - `4` - `0` - - `2` - - :none:`0%` + - :good:`100%` * - mlir/lib/Conversion/TosaToSCF - `2` - `2` @@ -6819,16 +7594,16 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `2` - `0` - :good:`100%` + * - mlir/lib/Conversion/VectorToGPU + - `1` + - `0` + - `1` + - :none:`0%` * - mlir/lib/Conversion/VectorToLLVM - `2` - `2` - `0` - :good:`100%` - * - mlir/lib/Conversion/VectorToROCDL - - `1` - - `1` - - `0` - - :good:`100%` * - mlir/lib/Conversion/VectorToSCF - `1` - `1` @@ -6844,19 +7619,24 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` - * - mlir/lib/Dialect/Affine/IR - - `3` - - `3` + * - mlir/lib/Dialect/Affine/Analysis + - `5` + - `5` - `0` - :good:`100%` + * - mlir/lib/Dialect/Affine/IR + - `3` + - `2` + - `1` + - :part:`66%` * - mlir/lib/Dialect/Affine/Transforms - - `10` - - `10` + - `14` + - `14` - `0` - :good:`100%` * - mlir/lib/Dialect/Affine/Utils - - `1` - - `1` + - `3` + - `3` - `0` - :good:`100%` * - mlir/lib/Dialect/AMX/IR @@ -6869,6 +7649,21 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` + * - mlir/lib/Dialect/Arithmetic/IR + - `2` + - `1` + - `1` + - :part:`50%` + * - mlir/lib/Dialect/Arithmetic/Transforms + - `4` + - `3` + - `1` + - :part:`75%` + * - mlir/lib/Dialect/Arithmetic/Utils + - `1` + - `1` + - `0` + - :good:`100%` * - mlir/lib/Dialect/ArmNeon/IR - `1` - `1` @@ -6890,8 +7685,18 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - mlir/lib/Dialect/Async/Transforms - - `5` - - `5` + - `6` + - `6` + - `0` + - :good:`100%` + * - mlir/lib/Dialect/Bufferization/IR + - `4` + - `4` + - `0` + - :good:`100%` + * - mlir/lib/Dialect/Bufferization/Transforms + - `7` + - `7` - `0` - :good:`100%` * - mlir/lib/Dialect/Complex/IR @@ -6899,11 +7704,31 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `2` - `0` - :good:`100%` + * - mlir/lib/Dialect/ControlFlow/IR + - `1` + - `1` + - `0` + - :good:`100%` * - mlir/lib/Dialect/DLTI - `2` - `2` - `0` - :good:`100%` + * - mlir/lib/Dialect/EmitC/IR + - `1` + - `1` + - `0` + - :good:`100%` + * - mlir/lib/Dialect/Func/IR + - `1` + - `1` + - `0` + - :good:`100%` + * - mlir/lib/Dialect/Func/Transforms + - `4` + - `4` + - `0` + - :good:`100%` * - mlir/lib/Dialect/GPU/IR - `1` - `1` @@ -6911,24 +7736,29 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - mlir/lib/Dialect/GPU/Transforms - `9` - - `9` - - `0` - - :good:`100%` + - `7` + - `2` + - :part:`77%` * - mlir/lib/Dialect/Linalg/Analysis - `1` - `1` - `0` - :good:`100%` + * - mlir/lib/Dialect/Linalg/ComprehensiveBufferize + - `2` + - `2` + - `0` + - :good:`100%` * - mlir/lib/Dialect/Linalg/IR - `3` - `3` - `0` - :good:`100%` * - mlir/lib/Dialect/Linalg/Transforms - - `19` - - `18` - - `1` - - :part:`94%` + - `25` + - `25` + - `0` + - :good:`100%` * - mlir/lib/Dialect/Linalg/Utils - `1` - `1` @@ -6936,9 +7766,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - mlir/lib/Dialect/LLVMIR/IR - `7` - - `7` - - `0` - - :good:`100%` + - `5` + - `2` + - :part:`71%` * - mlir/lib/Dialect/LLVMIR/Transforms - `2` - `2` @@ -6950,8 +7780,8 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - mlir/lib/Dialect/Math/Transforms - - `2` - - `2` + - `3` + - `3` - `0` - :good:`100%` * - mlir/lib/Dialect/MemRef/IR @@ -6960,10 +7790,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - mlir/lib/Dialect/MemRef/Transforms + - `7` + - `6` - `1` - - `1` - - `0` - - :good:`100%` + - :part:`85%` * - mlir/lib/Dialect/MemRef/Utils - `1` - `1` @@ -7010,13 +7840,13 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - mlir/lib/Dialect/SCF/Transforms - - `7` - - `7` - - `0` - - :good:`100%` - * - mlir/lib/Dialect/SDBM - - `4` - - `4` + - `12` + - `11` + - `1` + - :part:`91%` + * - mlir/lib/Dialect/SCF/Utils + - `2` + - `2` - `0` - :good:`100%` * - mlir/lib/Dialect/Shape/IR @@ -7034,9 +7864,19 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` + * - mlir/lib/Dialect/SparseTensor/Pipelines + - `1` + - `1` + - `0` + - :good:`100%` * - mlir/lib/Dialect/SparseTensor/Transforms - - `3` - - `3` + - `5` + - `4` + - `1` + - :part:`80%` + * - mlir/lib/Dialect/SparseTensor/Utils + - `1` + - `1` - `0` - :good:`100%` * - mlir/lib/Dialect/SPIRV/IR @@ -7050,100 +7890,100 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - mlir/lib/Dialect/SPIRV/Transforms + - `7` - `6` - - `5` - `1` - - :part:`83%` + - :part:`85%` * - mlir/lib/Dialect/SPIRV/Utils - `1` - `1` - `0` - :good:`100%` - * - mlir/lib/Dialect/StandardOps/IR - - `1` - - `1` + * - mlir/lib/Dialect/Tensor/IR + - `4` + - `4` - `0` - :good:`100%` - * - mlir/lib/Dialect/StandardOps/Transforms - - `8` - - `8` + * - mlir/lib/Dialect/Tensor/Transforms + - `4` + - `4` - `0` - :good:`100%` - * - mlir/lib/Dialect/StandardOps/Utils + * - mlir/lib/Dialect/Tensor/Utils - `1` - `1` - `0` - :good:`100%` - * - mlir/lib/Dialect/Tensor/IR - - `2` - - `2` - - `0` - - :good:`100%` - * - mlir/lib/Dialect/Tensor/Transforms - - `2` - - `2` - - `0` - - :good:`100%` * - mlir/lib/Dialect/Tosa/IR - `1` - `1` - `0` - :good:`100%` * - mlir/lib/Dialect/Tosa/Transforms - - `1` - - `1` + - `6` + - `6` - `0` - :good:`100%` * - mlir/lib/Dialect/Tosa/Utils - - `1` - - `1` + - `2` + - `2` - `0` - :good:`100%` * - mlir/lib/Dialect/Utils + - `4` + - `4` + - `0` + - :good:`100%` + * - mlir/lib/Dialect/Vector/IR - `1` + - `0` - `1` + - :none:`0%` + * - mlir/lib/Dialect/Vector/Transforms + - `11` + - `11` - `0` - :good:`100%` - * - mlir/lib/Dialect/Vector - - `4` - - `3` + * - mlir/lib/Dialect/Vector/Utils - `1` - - :part:`75%` + - `1` + - `0` + - :good:`100%` * - mlir/lib/Dialect/X86Vector/IR - `1` - `1` - `0` - :good:`100%` * - mlir/lib/Dialect/X86Vector/Transforms - - `1` - - `1` + - `2` + - `2` - `0` - :good:`100%` * - mlir/lib/ExecutionEngine - `9` - - `8` - - `1` - - :part:`88%` + - `9` + - `0` + - :good:`100%` * - mlir/lib/Interfaces - - `11` - - `11` + - `12` + - `12` - `0` - :good:`100%` * - mlir/lib/IR - - `35` - - `34` - - `1` - - :part:`97%` + - `38` + - `31` + - `7` + - :part:`81%` * - mlir/lib/Parser - - `13` - - `13` - - `0` - - :good:`100%` + - `14` + - `10` + - `4` + - :part:`71%` * - mlir/lib/Pass - `8` - - `7` - - `1` - - :part:`87%` + - `6` + - `2` + - :part:`75%` * - mlir/lib/Reducer - `4` - `4` @@ -7155,20 +7995,25 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - :part:`75%` * - mlir/lib/Support - - `7` - - `7` + - `8` + - `8` - `0` - :good:`100%` * - mlir/lib/TableGen - `18` - - `16` + - `18` + - `0` + - :good:`100%` + * - mlir/lib/Target/Cpp + - `2` - `2` - - :part:`88%` - * - mlir/lib/Target/LLVMIR - - `6` - - `6` - `0` - :good:`100%` + * - mlir/lib/Target/LLVMIR + - `7` + - `6` + - `1` + - :part:`85%` * - mlir/lib/Target/LLVMIR/Dialect/AMX - `1` - `1` @@ -7195,10 +8040,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - mlir/lib/Target/LLVMIR/Dialect/OpenACC - - `1` - `1` - `0` - - :good:`100%` + - `1` + - :none:`0%` * - mlir/lib/Target/LLVMIR/Dialect/OpenMP - `1` - `1` @@ -7231,9 +8076,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :part:`75%` * - mlir/lib/Tools/mlir-lsp-server - `5` - - `5` - - `0` - - :good:`100%` + - `4` + - `1` + - :part:`80%` * - mlir/lib/Tools/mlir-lsp-server/lsp - `6` - `4` @@ -7244,14 +8089,34 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` + * - mlir/lib/Tools/PDLL/AST + - `6` + - `5` + - `1` + - :part:`83%` + * - mlir/lib/Tools/PDLL/CodeGen + - `2` + - `1` + - `1` + - :part:`50%` + * - mlir/lib/Tools/PDLL/ODS + - `3` + - `3` + - `0` + - :good:`100%` + * - mlir/lib/Tools/PDLL/Parser + - `3` + - `1` + - `2` + - :part:`33%` * - mlir/lib/Transforms - - `23` - - `19` - - `4` - - :part:`82%` + - `13` + - `11` + - `2` + - :part:`84%` * - mlir/lib/Transforms/Utils - - `8` - - `8` + - `6` + - `6` - `0` - :good:`100%` * - mlir/lib/Translation @@ -7265,10 +8130,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - mlir/tools/mlir-linalg-ods-gen - - `2` - `1` - `1` - - :part:`50%` + - `0` + - :good:`100%` * - mlir/tools/mlir-lsp-server - `1` - `1` @@ -7279,6 +8144,11 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` + * - mlir/tools/mlir-pdll + - `1` + - `1` + - `0` + - :good:`100%` * - mlir/tools/mlir-reduce - `1` - `1` @@ -7295,10 +8165,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - mlir/tools/mlir-tblgen - - `22` - - `21` + - `29` + - `28` - `1` - - :part:`95%` + - :part:`96%` * - mlir/tools/mlir-translate - `1` - `1` @@ -7309,14 +8179,14 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `4` - `0` - :good:`100%` - * - mlir/unittests/Analysis - - `3` - - `3` + * - mlir/unittests/Analysis/Presburger + - `8` + - `8` - `0` - :good:`100%` - * - mlir/unittests/Analysis/Presburger - - `2` - - `2` + * - mlir/unittests/Conversion/PDLToPDLInterp + - `1` + - `1` - `0` - :good:`100%` * - mlir/unittests/Dialect @@ -7324,11 +8194,21 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` + * - mlir/unittests/Dialect/Affine/Analysis + - `3` + - `3` + - `0` + - :good:`100%` * - mlir/unittests/Dialect/Quant - `1` - `1` - `0` - :good:`100%` + * - mlir/unittests/Dialect/SparseTensor + - `1` + - `1` + - `0` + - :good:`100%` * - mlir/unittests/Dialect/SPIRV - `2` - `2` @@ -7345,18 +8225,18 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - mlir/unittests/Interfaces - - `1` - - `1` + - `3` + - `3` - `0` - :good:`100%` * - mlir/unittests/IR - - `5` - - `5` + - `7` + - `7` - `0` - :good:`100%` * - mlir/unittests/Pass - - `2` - - `2` + - `3` + - `3` - `0` - :good:`100%` * - mlir/unittests/Rewrite @@ -7364,69 +8244,59 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `1` - `0` - :good:`100%` - * - mlir/unittests/SDBM - - `1` - - `0` - - `1` - - :none:`0%` * - mlir/unittests/Support - `5` - `4` - `1` - :part:`80%` * - mlir/unittests/TableGen - - `4` + - `5` - `3` - - `1` - - :part:`75%` - * - openmp/libomptarget/deviceRTLs + - `2` + - :part:`60%` + * - mlir/unittests/Transforms - `2` - `2` - `0` - :good:`100%` - * - openmp/libomptarget/deviceRTLs/amdgcn/src - - `2` - - `2` + * - openmp/libompd/src + - `9` + - `9` - `0` - :good:`100%` - * - openmp/libomptarget/deviceRTLs/common + * - openmp/libomptarget/DeviceRTL/include - `8` - `8` - `0` - :good:`100%` - * - openmp/libomptarget/deviceRTLs/common/include/target - - `1` - - `1` - - `0` - - :good:`100%` - * - openmp/libomptarget/deviceRTLs/common/src - - `1` + * - openmp/libomptarget/DeviceRTL/src + - `12` + - `9` + - `3` + - :part:`75%` + * - openmp/libomptarget/include + - `9` + - `8` - `1` - - `0` - - :good:`100%` - * - openmp/libomptarget/deviceRTLs/nvptx/src - - `2` + - :part:`88%` + * - openmp/libomptarget/plugins/amdgpu/dynamic_hsa + - `3` - `2` - - `0` - - :good:`100%` - * - openmp/libomptarget/include - - `5` - - `5` - - `0` - - :good:`100%` + - `1` + - :part:`66%` * - openmp/libomptarget/plugins/amdgpu/impl - - `16` - - `16` - - `0` - - :good:`100%` + - `13` + - `10` + - `3` + - :part:`76%` * - openmp/libomptarget/plugins/amdgpu/src - `2` - - `2` - - `0` - - :good:`100%` - * - openmp/libomptarget/plugins/common/elf_common - `1` - `1` + - :part:`50%` + * - openmp/libomptarget/plugins/common/elf_common + - `2` + - `2` - `0` - :good:`100%` * - openmp/libomptarget/plugins/common/MemoryManager @@ -7440,10 +8310,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - openmp/libomptarget/plugins/cuda/src - - `1` - `1` - `0` - - :good:`100%` + - `1` + - :none:`0%` * - openmp/libomptarget/plugins/generic-elf-64bit/src - `1` - `1` @@ -7455,10 +8325,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - openmp/libomptarget/plugins/remote/lib - - `1` - `1` - `0` - - :good:`100%` + - `1` + - :none:`0%` * - openmp/libomptarget/plugins/remote/server - `3` - `3` @@ -7466,17 +8336,22 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - :good:`100%` * - openmp/libomptarget/plugins/remote/src - `3` - - `3` - - `0` - - :good:`100%` + - `2` + - `1` + - :part:`66%` * - openmp/libomptarget/plugins/ve/src - `1` - `1` - `0` - :good:`100%` * - openmp/libomptarget/src - - `8` - - `8` + - `7` + - `6` + - `1` + - :part:`85%` + * - openmp/libomptarget/tools/deviceinfo + - `1` + - `1` - `0` - :good:`100%` * - openmp/runtime/doc/doxygen @@ -7485,10 +8360,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - openmp/runtime/src - - `74` - - `69` - - `5` - - :part:`93%` + - `75` + - `65` + - `10` + - :part:`86%` * - openmp/runtime/src/thirdparty/ittnotify - `6` - `5` @@ -7529,21 +8404,6 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `2` - `0` - :good:`100%` - * - parallel-libs/acxxel - - `6` - - `4` - - `2` - - :part:`66%` - * - parallel-libs/acxxel/examples - - `1` - - `1` - - `0` - - :good:`100%` - * - parallel-libs/acxxel/tests - - `5` - - `4` - - `1` - - :part:`80%` * - polly/include/polly - `25` - `25` @@ -7555,8 +8415,8 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - polly/include/polly/Support - - `11` - - `11` + - `12` + - `12` - `0` - :good:`100%` * - polly/lib/Analysis @@ -7580,25 +8440,25 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `67` - :part:`1%` * - polly/lib/External/isl/imath - - `3` - - `0` - - `3` - - :none:`0%` + - `6` + - `1` + - `5` + - :part:`16%` * - polly/lib/External/isl/imath_wrap - `4` - `0` - `4` - :none:`0%` * - polly/lib/External/isl/include/isl - - `62` - - `8` - - `54` - - :part:`12%` + - `59` + - `9` + - `50` + - :part:`15%` * - polly/lib/External/isl/interface - - `5` + - `8` - `1` - - `4` - - :part:`20%` + - `7` + - :part:`12%` * - polly/lib/External/pet/include - `1` - `0` @@ -7615,8 +8475,8 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - polly/lib/Support - - `10` - - `10` + - `11` + - `11` - `0` - :good:`100%` * - polly/lib/Transform @@ -7660,12 +8520,42 @@ tree in terms of conformance to :doc:`ClangFormat` as of: June 04, 2021 13:01:37 - `0` - :good:`100%` * - pstl/include/pstl/internal - - `22` - - `12` - - `10` - - :part:`54%` + - `23` + - `16` + - `7` + - :part:`69%` + * - pstl/include/pstl/internal/omp + - `11` + - `8` + - `3` + - :part:`72%` + * - third-party/benchmark/cmake + - `5` + - `1` + - `4` + - :part:`20%` + * - third-party/benchmark/include/benchmark + - `1` + - `0` + - `1` + - :none:`0%` + * - third-party/benchmark/src + - `21` + - `21` + - `0` + - :good:`100%` + * - utils/bazel/llvm-project-overlay/clang/include/clang/Config + - `1` + - `1` + - `0` + - :good:`100%` + * - utils/bazel/llvm-project-overlay/llvm/include/llvm/Config + - `2` + - `1` + - `1` + - :part:`50%` * - Total - - :total:`14753` - - :total:`7515` - - :total:`7238` - - :total:`50%` + - :total:`16432` + - :total:`8857` + - :total:`7575` + - :total:`53%` diff --git a/gnu/llvm/clang/docs/ClangLinkerWrapper.rst b/gnu/llvm/clang/docs/ClangLinkerWrapper.rst new file mode 100644 index 00000000000..28c4086d6b5 --- /dev/null +++ b/gnu/llvm/clang/docs/ClangLinkerWrapper.rst @@ -0,0 +1,74 @@ +==================== +Clang Linker Wrapper +==================== + +.. contents:: + :local: + +.. _clang-linker-wrapper: + +Introduction +============ + +This tool works as a wrapper of the normal host linking job. This tool is used +to create linked device images for offloading and the necessary runtime calls to +register them. It works by first scanning the linker's input for embedded device +offloading data stored at the ``.llvm.offloading`` section. This section +contains binary data created by the :doc:`ClangOffloadPackager`. The extracted +device files will then be linked. The linked modules will then be wrapped into a +new object file containing the code necessary to register it with the offloading +runtime. + +Usage +===== + +This tool can be used with the following options. Any arguments not intended +only for the linker wrapper will be forwarded to the wrapped linker job. + +.. code-block:: console + + USAGE: clang-linker-wrapper [options] -- + + OPTIONS: + --bitcode-library=--= + Extra bitcode library to link + --cuda-path= Set the system CUDA path + --device-debug Use debugging + --device-linker= or = + Arguments to pass to the device linker invocation + --dry-run Print program arguments without running + --embed-bitcode Embed linked bitcode in the module + --help-hidden Display all available options + --help Display available options (--help-hidden for more) + --host-triple= Triple to use for the host compilation + --linker-path= The linker executable to invoke + -L Add to the library search path + -l Search for library + --opt-level= + Optimization level for LTO + -o Path to file to write output + --pass-remarks-analysis= + Pass remarks for LTO + --pass-remarks-missed= + Pass remarks for LTO + --pass-remarks= Pass remarks for LTO + --print-wrapped-module Print the wrapped module's IR for testing + --ptxas-arg= Argument to pass to the 'ptxas' invocation + --save-temps Save intermediate results + --sysroot Set the system root + --verbose Verbose output from tools + --v Display the version number and exit + -- The separator for the wrapped linker arguments + + +Example +======= + +This tool links object files with offloading images embedded within it using the +``-fembed-offload-object`` flag in Clang. Given an input file containing the +magic section we can pass it to this tool to extract the data contained at that +section and run a device linking job on it. + +.. code-block:: console + + clang-linker-wrapper --host-triple=x86_64 --linker-path=/usr/bin/ld -- diff --git a/gnu/llvm/clang/docs/ClangOffloadBundler.rst b/gnu/llvm/clang/docs/ClangOffloadBundler.rst index c92d8a94cfb..997948a8217 100644 --- a/gnu/llvm/clang/docs/ClangOffloadBundler.rst +++ b/gnu/llvm/clang/docs/ClangOffloadBundler.rst @@ -30,9 +30,62 @@ includes an ``init`` function that will use the runtime corresponding to the offload kind (see :ref:`clang-offload-kind-table`) to load the offload code objects appropriate to the devices present when the host program is executed. +Supported File Formats +====================== +Several text and binary file formats are supported for bundling/unbundling. See +:ref:`supported-file-formats-table` for a list of currently supported formats. + + .. table:: Supported File Formats + :name: supported-file-formats-table + + +--------------------+----------------+-------------+ + | File Format | File Extension | Text/Binary | + +====================+================+=============+ + | CPP output | i | Text | + +--------------------+----------------+-------------+ + | C++ CPP output | ii | Text | + +--------------------+----------------+-------------+ + | CUDA/HIP output | cui | Text | + +--------------------+----------------+-------------+ + | Dependency | d | Text | + +--------------------+----------------+-------------+ + | LLVM | ll | Text | + +--------------------+----------------+-------------+ + | LLVM Bitcode | bc | Binary | + +--------------------+----------------+-------------+ + | Assembler | s | Text | + +--------------------+----------------+-------------+ + | Object | o | Binary | + +--------------------+----------------+-------------+ + | Archive of objects | a | Binary | + +--------------------+----------------+-------------+ + | Precompiled header | gch | Binary | + +--------------------+----------------+-------------+ + | Clang AST file | ast | Binary | + +--------------------+----------------+-------------+ + +.. _clang-bundled-code-object-layout-text: + +Bundled Text File Layout +======================== + +The format of the bundled files is currently very simple: text formats are +concatenated with comments that have a magic string and bundle entry ID in +between. + +:: + + "Comment OFFLOAD_BUNDLER_MAGIC_STR__START__ 1st Bundle Entry ID" + Bundle 1 + "Comment OFFLOAD_BUNDLER_MAGIC_STR__END__ 1st Bundle Entry ID" + ... + "Comment OFFLOAD_BUNDLER_MAGIC_STR__START__ Nth Bundle Entry ID" + Bundle N + "Comment OFFLOAD_BUNDLER_MAGIC_STR__END__ 1st Bundle Entry ID" + .. _clang-bundled-code-object-layout: -Bundled Code Object Layout +Bundled Binary File Layout ========================== The layout of a bundled code object is defined by the following table: @@ -121,15 +174,7 @@ Where: ============= ============================================================== **target-triple** - The target triple of the code object: - -.. code:: - - --- - -It is required to have all four components present, if target-id is present. -Components are hyphen separated. If a component is not specified then the -empty string must be used in its place. + The target triple of the code object. **target-id** The canonical target ID of the code object. Present only if the target @@ -217,3 +262,37 @@ Target specific information is available for the following: supported. Most other targets do not support target IDs. + +Archive Unbundling +================== + +Unbundling of heterogeneous device archive is done to create device specific +archives. Heterogeneous Device Archive is in a format compatible with GNU ar +utility and contains a collection of bundled device binaries where each bundle +file will contain device binaries for a host and one or more targets. The +output device specific archive is in a format compatible with GNU ar utility +and contains a collection of device binaries for a specific target. + +.. code:: + + Heterogeneous Device Archive, HDA = {F1.X, F2.X, ..., FN.Y} + where, Fi = Bundle{Host-DeviceBinary, T1-DeviceBinary, T2-DeviceBinary, ..., + Tm-DeviceBinary}, + Ti = {Target i, qualified using Bundle Entry ID}, + X/Y = \*.bc for AMDGPU and \*.cubin for NVPTX + + Device Specific Archive, DSA(Tk) = {F1-Tk-DeviceBinary.X, F2-Tk-DeviceBinary.X, ... + FN-Tk-DeviceBinary.Y} + where, Fi-Tj-DeviceBinary.X represents device binary of i-th bundled device + binary file for target Tj. + +clang-offload-bundler extracts compatible device binaries for a given target +from the bundled device binaries in a heterogeneous device archive and creates +a target specific device archive without bundling. + +clang-offload-bundler determines whether a device binary is compatible with a +target by comparing bundle ID's. Two bundle ID's are considered compatible if: + + * Their offload kind are the same + * Their target triple are the same + * Their GPUArch are the same diff --git a/gnu/llvm/clang/docs/ClangOffloadPackager.rst b/gnu/llvm/clang/docs/ClangOffloadPackager.rst new file mode 100644 index 00000000000..295eb48ac0d --- /dev/null +++ b/gnu/llvm/clang/docs/ClangOffloadPackager.rst @@ -0,0 +1,191 @@ +====================== +Clang Offload Packager +====================== + +.. contents:: + :local: + +.. _clang-offload-packager: + +Introduction +============ + +This tool bundles device files into a single image containing necessary +metadata. We use a custom binary format for bundling all the device images +together. The image format is a small header wrapping around a string map. This +tool creates bundled binaries so that they can be embedded into the host to +create a fat-binary. + +Binary Format +============= + +The binary format is marked by the ``0x10FF10AD`` magic bytes, followed by a +version. Each created binary contains its own magic bytes. This allows us to +locate all the embedded offloading sections even after they may have been merged +by the linker, such as when using relocatable linking. Conceptually, this binary +format is a serialization of a string map and an image buffer. The binary header +is described in the following :ref:`table`. + +.. table:: Offloading Binary Header + :name: table-binary_header + + +----------+--------------+----------------------------------------------------+ + | Type | Identifier | Description | + +==========+==============+====================================================+ + | uint8_t | magic | The magic bytes for the binary format (0x10FF10AD) | + +----------+--------------+----------------------------------------------------+ + | uint32_t | version | Version of this format (currently version 1) | + +----------+--------------+----------------------------------------------------+ + | uint64_t | size | Size of this binary in bytes | + +----------+--------------+----------------------------------------------------+ + | uint64_t | entry offset | Absolute offset of the offload entries in bytes | + +----------+--------------+----------------------------------------------------+ + | uint64_t | entry size | Size of the offload entries in bytes | + +----------+--------------+----------------------------------------------------+ + +Once identified through the magic bytes, we use the size field to take a slice +of the binary blob containing the information for a single offloading image. We +can then use the offset field to find the actual offloading entries containing +the image and metadata. The offload entry contains information about the device +image. It contains the fields shown in the following +:ref:`table`. + +.. table:: Offloading Entry Table + :name: table-binary_entry + + +----------+---------------+----------------------------------------------------+ + | Type | Identifier | Description | + +==========+===============+====================================================+ + | uint16_t | image kind | The kind of the device image (e.g. bc, cubin) | + +----------+---------------+----------------------------------------------------+ + | uint16_t | offload kind | The producer of the image (e.g. openmp, cuda) | + +----------+---------------+----------------------------------------------------+ + | uint32_t | flags | Generic flags for the image | + +----------+---------------+----------------------------------------------------+ + | uint64_t | string offset | Absolute offset of the string metadata table | + +----------+---------------+----------------------------------------------------+ + | uint64_t | num strings | Number of string entries in the table | + +----------+---------------+----------------------------------------------------+ + | uint64_t | image offset | Absolute offset of the device image in bytes | + +----------+---------------+----------------------------------------------------+ + | uint64_t | image size | Size of the device image in bytes | + +----------+---------------+----------------------------------------------------+ + +This table contains the offsets of the string table and the device image itself +along with some other integer information. The image kind lets us easily +identify the type of image stored here without needing to inspect the binary. +The offloading kind is used to determine which registration code or linking +semantics are necessary for this image. These are stored as enumerations with +the following values for the :ref:`offload kind` and the +:ref:`image kind`. + +.. table:: Image Kind + :name: table-image_kind + + +---------------+-------+---------------------------------------+ + | Name | Value | Description | + +===============+=======+=======================================+ + | IMG_None | 0x00 | No image information provided | + +---------------+-------+---------------------------------------+ + | IMG_Object | 0x01 | The image is a generic object file | + +---------------+-------+---------------------------------------+ + | IMG_Bitcode | 0x02 | The image is an LLVM-IR bitcode file | + +---------------+-------+---------------------------------------+ + | IMG_Cubin | 0x03 | The image is a CUDA object file | + +---------------+-------+---------------------------------------+ + | IMG_Fatbinary | 0x04 | The image is a CUDA fatbinary file | + +---------------+-------+---------------------------------------+ + | IMG_PTX | 0x05 | The image is a CUDA PTX file | + +---------------+-------+---------------------------------------+ + +.. table:: Offload Kind + :name: table-offload_kind + + +------------+-------+---------------------------------------+ + | Name | Value | Description | + +============+=======+=======================================+ + | OFK_None | 0x00 | No offloading information provided | + +------------+-------+---------------------------------------+ + | OFK_OpenMP | 0x01 | The producer was OpenMP offloading | + +------------+-------+---------------------------------------+ + | OFK_CUDA | 0x02 | The producer was CUDA | + +------------+-------+---------------------------------------+ + | OFK_HIP | 0x03 | The producer was HIP | + +------------+-------+---------------------------------------+ + +The flags are used to signify certain conditions, such as the presence of +debugging information or whether or not LTO was used. The string entry table is +used to generically contain any arbitrary key-value pair. This is stored as an +array of the :ref:`string entry` format. + +.. table:: Offloading String Entry + :name: table-binary_string + + +----------+--------------+-------------------------------------------------------+ + | Type | Identifier | Description | + +==========+==============+=======================================================+ + | uint64_t | key offset | Absolute byte offset of the key in th string table | + +----------+--------------+-------------------------------------------------------+ + | uint64_t | value offset | Absolute byte offset of the value in the string table | + +----------+--------------+-------------------------------------------------------+ + +The string entries simply provide offsets to a key and value pair in the +binary images string table. The string table is simply a collection of null +terminated strings with defined offsets in the image. The string entry allows us +to create a key-value pair from this string table. This is used for passing +arbitrary arguments to the image, such as the triple and architecture. + +All of these structures are combined to form a single binary blob, the order +does not matter because of the use of absolute offsets. This makes it easier to +extend in the future. As mentioned previously, multiple offloading images are +bundled together by simply concatenating them in this format. Because we have +the magic bytes and size of each image, we can extract them as-needed. + +Usage +===== + +This tool can be used with the following arguments. Generally information is +passed as a key-value pair to the ``image=`` argument. The ``file`` and ``triple``, +arguments are considered mandatory to make a valid image. The ``arch`` argument +is suggested. + +.. code-block:: console + + OVERVIEW: A utility for bundling several object files into a single binary. + The output binary can then be embedded into the host section table + to create a fatbinary containing offloading code. + + USAGE: clang-offload-packager [options] + + OPTIONS: + + Generic Options: + + --help - Display available options (--help-hidden for more) + --help-list - Display list of available options (--help-list-hidden for more) + --version - Display the version of this program + + clang-offload-packager options: + + --image=<=,...> - List of key and value arguments. Required + keywords are 'file' and 'triple'. + -o - Write output to . + +Example +======= + +This tool simply takes many input files from the ``image`` option and creates a +single output file with all the images combined. + +.. code-block:: console + + clang-offload-packager -o out.bin --image=file=input.o,triple=nvptx64,arch=sm_70 + +The inverse operation can be performed instead by passing the packaged binary as +input. In this mode the matching images will either be placed in the output +specified by the ``file`` option. If no ``file`` argument is provided a name +will be generated for each matching image. + +.. code-block:: console + + clang-offload-packager in.bin --image=file=output.o,triple=nvptx64,arch=sm_70 diff --git a/gnu/llvm/clang/docs/ClangPlugins.rst b/gnu/llvm/clang/docs/ClangPlugins.rst index 3183eec1823..001e66e434e 100644 --- a/gnu/llvm/clang/docs/ClangPlugins.rst +++ b/gnu/llvm/clang/docs/ClangPlugins.rst @@ -125,6 +125,28 @@ Running the plugin ================== +Using the compiler driver +-------------------------- + +The Clang driver accepts the `-fplugin` option to load a plugin. +Clang plugins can receive arguments from the compiler driver command +line via the `fplugin-arg--` option. Using this +method, the plugin name cannot contain dashes itself, but the argument +passed to the plugin can. + + +.. code-block:: console + + $ export BD=/path/to/build/directory + $ make -C $BD CallSuperAttr + $ clang++ -fplugin=$BD/lib/CallSuperAttr.so \ + -fplugin-arg-call_super_plugin-help \ + test.cpp + +If your plugin name contains dashes, either rename the plugin or used the +cc1 command line options listed below. + + Using the cc1 command line -------------------------- @@ -178,3 +200,17 @@ action (i.e. the same as using `-add-plugin`): PluginASTAction::ActionType getActionType() override { return AddAfterMainAction; } + +Interaction with ``-clear-ast-before-backend`` +---------------------------------------------- + +To reduce peak memory usage of the compiler, plugins are recommended to run +*before* the main action, which is usually code generation. This is because +having any plugins that run after the codegen action automatically turns off +``-clear-ast-before-backend``. ``-clear-ast-before-backend`` reduces peak +memory by clearing the Clang AST after generating IR and before running IR +optimizations. Use ``CmdlineBeforeMainAction`` or ``AddBeforeMainAction`` as +``getActionType`` to run plugins while still benefitting from +``-clear-ast-before-backend``. Plugins must make sure not to modify the AST, +otherwise they should run after the main action. + diff --git a/gnu/llvm/clang/docs/ClangRepl.rst b/gnu/llvm/clang/docs/ClangRepl.rst new file mode 100644 index 00000000000..e4892bb9ff7 --- /dev/null +++ b/gnu/llvm/clang/docs/ClangRepl.rst @@ -0,0 +1,82 @@ +=========== +Clang-Repl +=========== + +**Clang-Repl** is an interactive C++ interpreter that allows for incremental +compilation. It supports interactive programming for C++ in a +read-evaluate-print-loop (REPL) style. It uses Clang as a library to compile the +high level programming language into LLVM IR. Then the LLVM IR is executed by +the LLVM just-in-time (JIT) infrastructure. + +Clang-Repl is suitable for exploratory programming and in places where time +to insight is important. Clang-Repl is a project inspired by the work in +`Cling `_, a LLVM-based C/C++ interpreter +developed by the field of high energy physics and used by the scientific data +analysis framework `ROOT `_. Clang-Repl allows to move parts +of Cling upstream, making them useful and available to a broader audience. + + + +Clang-Repl Usage +================ + + +.. code-block:: text + + clang-repl> #include + clang-repl> int f() { std::cout << "Hello Interpreted World!\n"; return 0; } + clang-repl> auto r = f(); + // Prints Hello Interpreted World! + +Note that the implementation is not complete and highly experimental. We do +not yet support statements on the global scope, for example. + + +Clang-Repl Basic Data Flow +========================== + +.. image:: ClangRepl_design.png + :align: center + :alt: ClangRepl design + +Clang-Repl data flow can be divided into roughly 8 phases: + +1. Clang-Repl controls the input infrastructure by an interactive prompt or by + an interface allowing the incremental processing of input. + +2. Then it sends the input to the underlying incremental facilities in Clang + infrastructure. + +3. Clang compiles the input into an AST representation. + +4. When required the AST can be further transformed in order to attach specific + behavior. + +5. The AST representation is then lowered to LLVM IR. + +6. The LLVM IR is the input format for LLVM’s JIT compilation infrastructure. + The tool will instruct the JIT to run specified functions, translating them + into machine code targeting the underlying device architecture (eg. Intel + x86 or NVPTX). + +7. The LLVM JIT lowers the LLVM IR to machine code. + +8. The machine code is then executed. + + +Just like Clang, Clang-Repl can be integrated in existing applications as a +library (via using the clangInterpreter library). This turning your C++ compiler +into a service which incrementally can consume and execute code. The +**Compiler as A Service** (**CaaS**) concept helps supporting move advanced use +cases such as template instantiations on demand and automatic language +interoperability. It also helps static languages such as C/C++ become apt for +data science. + + +Related Reading +=============== +`Cling Transitions to LLVM's Clang-Repl `_ + +`Moving (parts of) the Cling REPL in Clang `_ + +`GPU Accelerated Automatic Differentiation With Clad `_ diff --git a/gnu/llvm/clang/docs/ClangRepl_design.png b/gnu/llvm/clang/docs/ClangRepl_design.png new file mode 100644 index 0000000000000000000000000000000000000000..9de851e7d7d2d3b28175e75dab86671f521d86b4 GIT binary patch literal 72582 zcmcG$Wmr^gy8sG^bc1xvz|bAiodZ&W5>nFL4N}tG-3`($E!`m?jdV$Ogwvs;>yWl>tM>t&d0~c%ErOU!NCma!R+X6{Yz(0_jZ?$gQKHrD^QVa9Ie{~yDkPyP=3 z1J~c>1fi4hYpNJK+FCh7wGwMghIo|2Z84Q^~wJo zDPe16>!50MHz-hbB7{O>xiIk^74&cB}gGg6QhO7DNs|1Wd>X@zi? zFp41Se>hbbC4FO?2nI$JMpjbnog3_-4x;b7A3uaSTkG0kT1TclS>?hNXDDVmxoH@UMc1E<9n*(G5Lm2B2j+!1<0LPduC=nb)IxIj~Kd`xcUWVt_Tr~ zcRU=oUU}LcKm2UI$zse?#8!sKgOw8f|NXMI23+HFlQNeL^QD{wV~2>fOFV?31iVLB z>amQF*u`)aCqB0Q>any4zm}_^uBzQ%a}?HqEFKkmj*5;ct9DS@m!wgLakbty7*N~k zTo&D8Mh=-N2Z;_2Iw2ZXh-A*ZQ(RpCAro?C6}RLtYeK|aLz|a^y6Q6`v?a8k zJl5oRVd}D(brEHCGSYm9Us?@pj3K}pKpi6$Qz|ARYs?TZS1Oi{Kp()?{^Mh}r*bB< zCz{+?P=a_#WL?y=am;(H+3YJp{3$pUgc|!)%%`)M<{0Z3WUM$Vk=}m8v}^z)&}r0> zDZrQ&Bdh{f@nFm95hKJ4WQ1x&W8_nxz&#;0Sj-dPtc6mue)>iAU%1bC#sUoGw4%ph z0{0z8m@-`bC(-@qErk?9B))*l!5!tN%ltbNc0rmV6Fug4geFz&EE7F_64gT^JA9bC zjk>u5M_*moalgf~JtHAUZVGqe&2d_U)V-MVM$I+!E(6H_CJczWstT{u0Krq$Y41p! zCzGPp5wa4+vyHBz}u*up3U6zlhbp>!15x}i9){rUIxM> zX_#<_cr)}+q_0W)KEb`VYZ5=k&`k;4L<4IL-o<>6Nd`~>XC~Rb`Fbsmz@jAzb-Sm; z19tp4#6>mZN3`bp{Qbsl$`#sse0c%Rpl+u(fbv#MaX2Tz0;;XwfNb$u(Q|;)C2KGn z%SaI$`sHKJZhxAMOoViYeU1>|9(U@61T=TTC4SR_rM=w|aMJRHGZuHv zheVutO+V%}){fW>&DLDM`je6;Ji8Bn<8RqbT=PJx1963;QY;*~4KdRT=W)v4)aKMC z)_`5nMRAQ}93--{>La7Jd|*DX*AxSkKpG`Qc&6lM70`xx2P@u$(=9kFnnHVGX*t-8 zl_c^)yjBpqn^*7zmFVUAq{zv3AeM!^yGXHkN^~EBuJganO$K(gvLC*S0dLS>}XSw-#9o2sq6l!HEgEaJB0BHzc#}kYZ zuwNN8xljv!CVZxRvEC7U`UuSWw%|6tkmVzbzaMg8fi$gIbCnj&CV=*wa?lca!y2&g z=^3X@H!8oc1O6Eo=!8EVoT=(hW#8a__La_UJQ}7&M3nHE%*b-mc2h6hk^jMp*YsZf zzd|jI87}E|8515%*b!8Zk|)NDmr2bso;nC{15cLhQ(_CCb=Q*~3t@=63iRUO>^Pd9 zW|)InQg<#s5{?wK!gg~B0B5q^z5rWO^~_4#i&F9>vA^j4nk~i>s14hU!$Ht}8VxwZ z!U5uF1-;!IYU4qO2DQp7$%v;S>bD^RUI6m}P2x=7+t9sRPJj{WB)LXHp|sHy5-BDK zM!Z|{A=FE~0rpHZGjbR~Xo2%BdT=7hY-a|-1fqL3e)FH)pS4djZc=PG0_IG`G>#Xr z#@UVM<&iSmecC24#id0}LgI+GcNFTDS3VpA|vs>ns0pU{DBY0yTVH@tTbKtB$)ielkVh$mC)DSUXQ8Z2^?uRfI4qMZvGme~A zzx*vlaLlD0Z@N*nKtNh!J|HQji?K?g(%(p&P*IR6^>Y)0lEq7(fSCC>@K~@Qy1u6d zk5*$}{83}noK@B}|BwNHfc16^$7bCl1;9yOB0@H2e||?G!uH01u5q7s&={-nC?#j@ zV^H-;|JnPH3e*eQex~%TjGM?SeN9H-I%z0x)%3!H)YNdxAAn6Fe2+BJ*x?tQAd1@# z0x=vi5weWTARiV+bdtm#f;dy^9pUp!v;e9aKywS>IZQynrrKb73>5%mskZsj_O7))mQjtOAhnzJir;@6;K!<_wvVm zHyGq6S>yju+n3`bQ4(pSvtn&Ps>RawKHLI4-^~}!Q&qP-i-n_Spd`a_;?f&vNtOZFNKwF(yKVMh~?9cz^WL{b(hcIHEJkKECyN8i$&0^3L zWv&bau#$U~_jG@36961Y0u%&F08xPAnsG~-OO zv#*N^8GDF6vtk12wkkL#rA8Rp@vgGnF{gwg6BuU4P2$bB&fsig?A1i9{sjb0lFN7yMo`SWHz^vGy%(am zAklA4B(fg2XC$SykWE3P9=brRp9J@&Vtda>>vv9B@MI?h={APX1*+6$07&~Hg14as9~Sq^prMgUGA7E(AGS*jX$bO-7Hi3;-%-c6c(hHT|uUe2_B;f9YsVsWv zmc<}#7b-W#fhTJLV}Mb}u{)R~gbc%kkZc+x0WQ}lmH}E#iz8)@#d~i^4|oW@u-_fv zXRoAAZ#+igI1A-D7`fL**hjj9;~;Vn4zRuv1HT&(uk<6u(4TLO2?mIW?TrU$zvM&c z_T`NOdQPOY#x0%_q>B1Myhtoa-0j4@bKh-3FL<5{O$+^w)rbIu#{&;N z$p5jsbMD1aEjpPrsf0mdh*S22$)F=caPdbmALO9ewHo1EXB2761jNQdZgt!p=dNzA z-&UHSg5En=BxGBJ08obhjp*Jl6&~86=lB1b6aWv4gB4};75SxXWcoatq8Z^d+p^af z*+5Y1MT5Tln>k_*L~#R&NaEMwmlwP!;=7f>xU~tc4MP*&kmd8 zTkcoEck`#e=rgdw8~VEYcfa#5vGm&y)Xfp?^k<(P@ommu;_n(_Ck2;>FgHXtW8IgQ zTD{DzGk2?J(O$St`(tvY0>5F1W&SbQzX!pDzJW1mi8l(DKUeF==%+_g{wM`tzk5Z` zwEX!1qZWtN?lbtz1O(O$79PK_VNvi7Q!m7|0N?VGu+9h%b>{zlms7*F{L$|-BItrF8Ki(yFWaA`zxM4o$^Qy1skwc{t zDqLdX4{4gp0oN`}9ih$<$r&)kV|$ti8zC5%!MQ@RJ`YzA}QkN`rQY zorWu%=G|)qC1~+1@@*Dk&V#M9T)FN6S?VJIaZ&62<+&B_be*qko@3;eVLg^k4Ihsr zyI0fBYhx|KRHqxj`#lBhHyt<=@;V3B7d!0o-tUtwThv~aVvwgt3vq-l=>;<_zx|Ts z>`HFaDd14jiE$==QN>?nsq0Kf#l?7Y=e?rjD(!sLdT?+pBd3?lE3Y-@)|j!l5v+?T z)O2^aX&?R2#_E2ekj7?THjLSh@6i!`WEo=g-kLuoP@RzzuXFNZvZcAI^@&>-vPtG; zb}sKd_pe;X)plnRJr)8@cY*z7%x#r()@|)V(qEKx&h3kxA9@N_Hd9NekI9FKl3A8p zf9x1WD~|s1v24{9l8OW#H_pp0aFLo08b>H$m}j#TTMdk+Y7iHMtnua+g+)q-;1aj7 znu}i`xq9cEqpK$cy(WXdYz}?)Tu3>7Yxu=-FVl9^8PhsEi-!qr>`BvN{HTgDAsZoE z%qKA6(6^zX8_w#*4mfYE*Vx7J_*V5DBg=Y}*6cEN^Awd7jQ_ol>(sX6DvmI?HC|3~w^P89?j2GsR5db5; zDUs*>i>z77_U()UwBp`cVqs#a&_nkZH42XaVUD_L1Dtj50ESYl@lHbPR!XebNOZXoX))!?YBP`AQGFyJY44A4Mnn0toTI{CwvOASn432s22f&O&=U zh^;h$A-!&*=I+^}dFotf8KsLV8+;wdYnuwg&-?sVe1Vh#(YlTjiy3LYlK#W5{3}TK z!p|hsms(M$0cL3-sh19FImcN~fvGNJx00L%Bogaze(@ub&n?qCE_6b0j0 zq@yLtev^G>*?2R0lX;Om_T8l_Z4i3h+0`H9h~i3#A{*nj*DNwY7%jxtH#2$vre}w` zMbz_ojEC|~5^t!1K?YSrWWu?_?s9*F=0(Pwd%gM21c7Fw)x;;OPk(uDQWAR-ctYc0 z*q{mBh`8?u$v0@Lo=RI~RgxPYZG!dZbZFy}Y0oDmC^!2U+K7?x9`GFm3 z^IsXe|AVN{5H7R&%=13I077mcl7={+^Or%!s*q*-;E;)3G{-7Us;T1WLHmJFr#*nf zC_CkhZhxLzFr}-nEVC7Ev$6$t-1+Pbn1rG ze_*0PaywX5ydFRf{b@n50E+M6J#0nI@7+rL`#j_W{J5a%Rv&@X{S85Gqy1w23aV3B znB?$q#+N0&c*or^G%|+srq0l|-yMU83**Yo)*n4uzz4JAsR|>8=B2pO3dQ_?Bug4B zT!RIjETLgF*@w6KexJ^Un27i-B0x0MhOIimLieA@HCya*Z@dL) zTIWI3A{QLIRrXA4(;#hj$m3=F;FtH51iEzRd-;?i52+GNN2grTtuB0X*==PeW)mg<@)5Qh^n7Qvy_(oXN%m9nY?cLh|-i(;FJBh7rtm29#Q zt}QJ*Txg1RGid8BjU!ij`S{2i9lM;_DxZ=nGX(!m_gurD^Mb`*ry=#VZ$UD26W&;B zpGe~*F|-_|xOaK*3Bo7eO|G~K7)OvXI{b8}B)#8ZyT02EU$*lfY~Br%PgyHp%o5hw z>c!2x9d+Ct{}m8>!ITWUXb*uK41%Yjfr0VE>=?&p``otPiTr?pbaX<3-MS*P6%JNR zj>@#AA9nuYpy@kcQ6g0S^#}Wsd34-c475$OIFG|+jIcO@DH=jvAcV9%R5}VVj%aE) zZbniDlkJ$X$V6Z@-hmus8Iq6&Xp&)>h#dvyL< zNpC+xb}TD5D9p{r{9aM`hLSV*{Al-?s`Kj^w`|{>%S+nyeE$eBT8}YnpQOrmkMz64 zbv3`>#zZQ~yXptE588A@6-#oy!~TzNfCb=_M#B1K4xbX|2 zd~rm20GHhlQD1a$doLz)-#N^~k%c+B_@)hGgo_V&4_pfgE?OSj2_R1O*X_F*eRBQU zj?Y4&Tc#Au!N5+8XC>>kQ||sJ`dB@OBne6w4SfQsI}&UgZa4C%-IMW4%DovDV_67I z`>psJ)rE*;ms4Ub)?)3l3f4@BF_!jT9~oTEI-9{cx@oT#e2_5=MzZ)yIT?U0YP#7M z0)BgdhFq=<%IbJRYreF*%@ZcOXWm=}P3j<2Em@+uX4m27Z#t(3%~h;wqdnUfqq?q; zxmG=u6QF3+h@)_5q0;e^qQ3j9-Fkq^RJrv(!oqKc$B(qO7wg88@;+O~WrP7wd{@yt zn??uY9y7=s76X$<7CPJHhjXpbr~?m!`PxJ7-mMkFmPu4oWFUQ)lcCxV$MY#?PXDI|v*s`3KeFN))sO#bmh?;(ET6b4dS);nL*YmoVvp{>dF+p*wE?vr>Mljdn;`MrMg zXv#Tu&;%p9kuK%RJz7GPPHQRiNHy3ZhjOwW8&Db%sBn5UKu&9{Hx@gZyqchK9Ex7M zRkPTI@Y&b-A}Lu`UM%ZY>!Y4+TyIYI`N#LAIK~D5nMe1#TE^T!t2DQ?{7ewHO|54& zL&5f+i2s^+j+(gaIar(sGjby*wns;njP-Ri&-1qaLajb?C1&FJ$ZRBu@ppC9u~S!aB-65TjHzalb7L7Vn2uj%?{!~5#1Nnb>znN= z$?4$E+u)JeZv74BzG|r#H!sPZe7!%x7guRglTo;9B&|47a1{&d^M>w-IqxYkvcE5( zeEl=Vb{zp1u@wWcq3c5mRH);_TTmx70=Gh``}~CNT`U+?r@c5n4t{jMDNNqp!&T&V zWM0Xb^8XP}Iy^pV!^pF2pPb5>8lr!^ko^g$=Y5~6?e)N{5(Ol=4h2;z!vUiGmt~iv zf4zmoHi_~5)|6I*-4_#6a8!vXmhFpxmVKDoOnVsh;8*6T4+-?hDxuK^@-JKy5)hkP z^OC04dK?nvxwqnTjTs>(E`;v5az(k^Q`eb?hV4jn^w%SCfqHMyLh^}FXw%EX`rbtu zvNaiRG1!Vk3}#R)D{LJ&B)R5A;uw$IJ(#*`>gn|9=_etKL&9j z0)jvROHEdZ6Gd&n-m4J>CmU8{b)vVzly$AqE5% zI+ERSp1tm;w>@Wg%TuJ8B541Zmlx7d25~FVx$L7J3}Kg%$RA`kcPd57Z{V$*>A1^! zD3q8x?pn7P2$2G5$dWUD#BDd6%i>rcMIB{xt+tFxknH)Z&NSfXSM5Xkc{Bccl%m-4 zFZ@0r7wRO$rzB7gbbaH)cM(XJ1CaDEo|Q&jai<`Lu4jYOWYuFwqciFa=UAqiJqc2f z9nS5g-d6opM8PnTm7WpUI#FISI#>1L5HKKoLI>9X2{j5}cqJ!$8a;h!IG;X$HP6pJ zQ2uy4l^^W%>nF(teKT=e3%XqTPcJS>Jc>K*fc(FnZ;6broNOF;Jhy;d=YN9xo&e>G zTPL&`el z*FSpR9rn=o+pq`E{P-hiu_};a-Vo!8X-k=@?MhlIH0b`_FdEd*A%ojv=ccMkcWQgQ zYF6Ja*;MMQ<{5R*NnWXTDa_z6NH%J)rrK2G*9_DDFgWt$*29Z4AZNy2I<{PE{^I)F zTQ4e&7uzo*GW05rKLQWoHM$B!r<#d=!*HJ-Y77jWyT*{vpff;A~5 zWo?e~d$9wVD4SdM)hS}QqKQ*wK1%L;flXT@=F|R5G;tI`>Ue6v1t*^g}y!}$udv0@<{(ch{jpY69z9}zCNw0Dodp~w_ zt%npe_uz*h=9|xWcsprJpKBE(kP`@TEJYKjln-K>G!xPNw}=)N9JcInjrzBEwznL8 zF#LD=q<`$)&<=0ByeL#{vgsdm*B2AMeo~D4dg~@ZYF;%(aFVESz&*Tq^QegvkHc;| zMN7i|uEV{DpMI1v(4|(T(fTLluAY4&8ktu>LU$7N(3ihvDKV+vns$cVeC}m$^@x-7 z$J+%`Z>FLy%ko!$(!XmtRLYFG1qkf3yMEZ`*5|{jzvC3jl1ElLI~c5_PFjvtaGy`# zoD8wkW*RkG6g0*WkI&RQrCx@=;Z?;c>)G61s@fUasM;OeC&*&<_MtA2Uv$}{tREJ` zDf`Q!W@6ti!F$PIKyz?YY7;JV;6s$H5 z#kRMZC<)*|$wI663^`SYe!e=}6(;`IzEVmM!7hr;23_usdi*uFz5Ur#z7Iucp9yvs z+29wz)|`OIV)F}(&3Mr%+fd-EC^SX}l$1b0@-Ff<>OPeZAK>!$s%cAhQAtpJV>RU;&oweNoyb&vD*Mw|Cj((5qJWSB4w$&Fj;0-WTf3=IKlJ@B)xd%? zQTr7fYpz@oKSF`(;f}hXoBMvXs1z9@ifl9d(-^y1epC&vQ$ZmOWk#bJTdV{&f z5K^lwv4&wh6j?=b{vOL5BtrOKl5}Hs+*UH)uN~90-S59vPd@#s4Bna|vFSZ^z5-gN z|CHTJtW}Bi_79eufPFDK8_r(yF~RQfRQ<1!!Ua^`?{dnT;wV4wpCSK*G<}Ei<{O|ZAKj~1;6h$EKKYm?!wTKzbylA#0qC-K7S;d^!299}q3+c(m4&L;WYjqD%&h zdEa?18SRvQAN#KNuApAe$NX*uM^?L4T21%S(aG16V)eLdoAG}_O_uv#xR#k-IRfJY+KehdPJ=tTBht(HKvq>JiFUajA( zS_kdYvM!Um3a}dWwa-?>iGBcwn5OhUS#bTu=;RubFJpgB)grr5Nxk=$ZQNHgzxq_C zq%AU!l6SoW2Ex=9A-w+FOK*&>!j5#&BhTj`IrSvjk5@`1ZJa-?Hv@L`k}uMxW}TQ-ey&e_?OA>XyU*K^5VY>g5eMBM zUfVFz%i8zDlR6{+Wd}PdWm<8~^_!GFF7>Bl?&kZ(rAX=8U+;ah3gNOV_bX~gC%4|sArouSQ;h5bVoiwXueul$CUB#LYzz>zRl+8)jTJAg)yV~QcXTEw!Z+YGVLz8 znvd_i#Bi&jI6FaP#jZiyW!gG!rGr_`b->WAO%&jM-Jn}F7P_owjHi^UR+V&w_x+;uQH>D#@BIi8BtzMU60=wRHsyp`!?Lq z(>*B?Q7b$8iLNmi=w;~`9}`W!K2{E7C-|)1nDT8_cR1|n4}kg4M;Dq^@yDLtMLjII zpAVNWunEoJEROi5`u~tT{b51}r$7Q5#U%=Cw$Q1J*h{k!rZi9g&NOei$ZUIFQ70`p zYt0hp-BUZZENhsXKh&g60u4Go{0S3qfXCgs-p{2cONtwO5j^|pN!RmTp#_!m14{Y1 z$)}qbo=rC~Ilk?Z_tKWl+Z~-F?&`W!2Wk~T>=&P8KgV8R=#VEyt#}yPE0rfCFCG!C zG?(c?Oqje^u)Fzhw+O#p~N~{g!hMKa)7t zKo1Yp_hp3$|3oxaZJ3Jswsw+b!>1g~cc85vD{Ek)zgkH5>; zmsHe zE8Zltyf#mX(w9%q&Sp*Lu}#uxbxCCly6`ALCBP>R-UV4ZM`~$nGf7EFt=IAa^li?y zZC}EltcShk<0$Y#g)l_rQB@PanKTrJ60DN95<^K}I~!M?7e5Sr)&4k5Nu^c!yh3*V zY&kLVd&N~m&4Ys3P)ShJ1Dy~)(v*YW+=5O&%74c{#>95Gqyoc32SR=fCOEE(1_Oyo zw7nPu6iVYIOkvHdhirDkpti^Jk(~_5A~e+7D1l>MzRd_u5DUwAjKK9P3ZKUsCe2z& z@81ur>F17)j@v`D*$KuYNvVASX!7#%2_r16^7l6g zhcdmV;Y&-V5gm-B9!CbrNP0l;bk@3mNv?ravJGyA7sCp816)mR^k76a3 zm^Mcm?l>%rnuK=xPpox`p?sT$2yv%|pZxq-lQl}%5YWg#PY9TC){}&vICoLYZ@uL@ zGB27R&v}|g)_S79{ajn2rYBlrGXVE}5322{c<_bAz%0%)aoDrhOcqFBh3JXe2abZ#+E%`gV6zyeUEw(_qu_;Zy(4+Evbb2e#tI4lW=Agr#XB6Lu)E61~ zN>&{kMQ5tY*5rGQikk{z69?tfW`Hc!E4rfuPDUz3IyF2nNdcQmLJ9~NB5;iDS^yub z8zhH6Dc3w)*yl>~OMaeCNtc8K+2TfXMX8(Ew;yoo&8KN3Xb6}z0RD)Wl@^~&Oo~W7 z_Hy6vUfPwkLb!UWLW>9Yd0gNmWmD*8S+y_|RNA%?#yE<_JCc)66I(RNOZq&kWjnO@ zJ%5a^suejWa$*yLUY46xpH5(c8ty)g$7u2yVIz8Lm_1!qZ}I@9@U7_mR%U#7x>-d<-ls3lFaWd2p3Ic0ZjW+KaGj-! zT+lN!Cqn44IOFrP&HemxS}FZpHVV^!MNdm+*7AhR{(Ml0#G%01qOHKdHG`u;r1^%; z0!1n(6{yU}>BO%Y)14>izO&vr(vq$AEvR7HefAaOlC0ypf;~3>#k|}8LMLXUWt(i4 zn=8uoSr$l7J{>6IYR#9&dPnCZwoA^c$Fz7;DI!JX6_+jD>Ip{N*Tj@wYf z?SnIDK3$Z0xv;P>RjNuWp^Jz{2mnnwt^YD*nORplRU4dYXr3z4NxOwfMlX|ah=khm zV|af2=5&1b+Q+Pk1kWd$qdtPz?cpE0AG5A07doYX^|~>0M{(0LvJnh~6MP2KHzeH- zByP$m5k@yB4h;7}(qEj#9jp+$_Jz>}zIH|83HS6;(U=-ExA|D<^C6pxs)cu!!VJmN zhhQ#N)LvsLPGCvynmI}NjJUy<({w!H_v5Yz4GJ@JNLH*>W1mP7@`?)ys3 zI_VPZLbVuGN8V4%9bTTmJJ5HnR+oxW#A)`Qm?Dn=;p_=BGOb1{^ZNX9+^SZx=_ZRG z!|*kgAP-kaj_mSqVLCwQcFq4BA|Qq#Lcn%d=xRoF`={s0>pOP1rK`RCXyOXc5XY`} zEt;01oLm_2OT-&UxE-6y=<)XKy)~vfZGT0Xp`#t6y)A0N?^Bz8?MY!D`k4mhNT}Nu zNe&4=Q46s9xEI#<>aGyzdX|=VX%~6>Kjbg+Hh@ z@mu{KlZZtELx7Z#J2RL1;^{m%Jn+R3Q?B%KpxKOLZ8?|&-xkky_{z^ zEKWXnr|;HtQ<A|KZHM$n_zQa@O5|1e@f~7eRxY zIo3|s%NX!xrW^_!bxQ_O+cts=$oDy^kH>X<=WEtHgO`cv-`S5l6e%WJZ}w?BdG)!X zUTmG#$n;1`-2w}RRDY#HO+$FN$FZqrBl07qq#spJLs9b`SE;61vBBgX;F6ahdxPH+ zDg*h{YTB^gKi;dS?r zrsSZpV||}~Q$dos%-xP#YclTcXQPP4>}3L^*O8QyRuDr*K9vmZVO~dod!#PG1Or*&~#+K=V6f6wlj1*3f`V4-$+k>Z2Qxw_5D+ik^$z4l^Jd3 zOMc0W%v_3HP3sTCLP{M>;k#qp@SLM2f@9YR<~^_c%p|^DBilU0!%75Qw-+6v?(wRh z#l2x+cSPZ{je!p{3j4s9hLqQ6bM@;-Ka26n&vpgk^dwXrn~pn^Q~}pY*&ZjnII;1j z0z>T`^UNQ6>=6Z{JAG6W)^`yTZF__^Pc(q7Xy!SD)(d08i^lzZ(}As=@ypI>tZLg{G>Qg!uXD*;`Qc4*y~m!Fd~F6D6lM4q;eL3%4I=Q`=^pq zT1G?dN`j{E!q|;cQr@Y`Hiif%$z-#VJAxK8`7>F5vKIN5pCT627vL57wIJc8>g&KP zPRv>_jhL#ga$b)MwiqgEWN;~Chv35-oO0?#-NgqxIfX>tAuUJKGaQBCL#Uf8bOvCGKifJ5q zNl8%>_cIY$j^lhLH5fx@dcW`0-EY@}$DA$fn`<9}NNm^~mH4vH2~)5P+#keQ_!9k6 zJ~h+mNmI-&64@_CKUgr7`apeWO{ia9F5ZPpRk36wTaJlpA;%kCOzKU+PvK2Xl4X8< z-gstBA^CY|g_AH_JKp=|1BqkQ;N!WXJVr-`6^#e9qOU{(rcIu0ig}6q6}S_YOyP;J zv2z?pI1SF@dckx|P}YJ<*3Qf#_=CVTE>~TT6qA#@VRVG+`4DZodtAoBSHl5}{l$hd zZM&|QJA-aEaeeRSK$aOz<`-;PY(5&~=)rS%6SIK`^GDi>C&9S>jdN7=B5sY~F;k1glo!Cpf? zw2(-vs_P?Lq~I-sfI&vz*|u*oAAUJ9jVVG$yN=o-v)Tbj?@G+t^Z)vbQ@D#t$HOU} z)$|jC3^@<1BdcMCzO9Q&mYidhw`zy4!mzi05K;FBmA2nyQY0tL-_sc3zK6re$}l~A z{*1GL{18ueGyQC2_D1%0el-Rh3wpa8Rpj?IrwC$A(#$Jl?3sSRkqTR4UnWbQ<1HBF zOK;#SavVS%8z^epo_+?AjTH3%uvUs+=ZaES z9x4?b7C#NyDbxl;67x5)+00eylr?G^>4;}iJ0CkWVxmTlT-doEDhXmX_F%I-WSy$MNk zh;mBhxS&&e;6Z|%YQL+cb$x#Er9N-U_1u_{^t8-?!XgAM%H;>zifUEL2f2t5u--5L z*eQzJxB%7y^~t6pY5skJ!9$MG&k|7rN2XH@Wv}t?t&%ZUKPjlO+-7>PcIX~&yUNwXn|BV8I^cH+jw$u%+Q^7UYV zFNSoZ(Ik*Jfb7@unMBoDTjRm{Q~;`>a7JuB$~7%w#2yXXhTmvU-wYch-lGiv1*!nI z5E*0*-|EMb3ft6!X!=HW(6w?T0aKmo$+c;$LwHbN-koy0Y+DR&J6U zc@Ixa2F-U}z;&6)myN2`x*e+w`E{*c;+yZmv{ws-N^!0EWP4o#<$u?6ORO$8wcZo( z1vTcDj`p_Ys@6Ef7x|mDP8~#c{jy8x{x(vgeG_Kwgc+^&)g37Mb8!7wdp`Rxz;-Yz zGh^kW!JU}Bb-n+sYP3Cdj^ z@%C(Ac3*kLu|LH~E#jK~snaZ%DN97@`C%=4`$?)y3}=Y7$MqJJ3NiNFiMsdw^qqQX zVPBWdyi=y~NvOY9AcM{C>;9Z^rR88W)*^WKn0}QqH?V4ZVaHX9>yNp1K818WLClUe z!$C`ZyXDV1H*%_LJywEu;@X3|B8~P%O$Xb|1RAs>6U@-BR2^>z$Ei+lbuHP(!l&Fe zpU(Ff9S)feS=J@Xd2$*>Vw4~l433w6@po`5NOfEoWt-b!fQ!U|eRgSf0WtIGN>hB7 zHL-SRl~HZ{{G8An^0v+B4WJg_nCIf|WI_9jWzcWRjX(Z2?+ z$7FoReZr75fNz^DAl=|vi}dU)oF{Q$F;e|@WqXm0oGNh1^7xa)^a3%5ptj(Ww^oos zr>S=O8{}g$UiE1eO=5Z^=BCF?&U!*j0Uot{`oYl&u4LJ#D*Ryw;dS0>Bn=hK zsC~w&9Qrt|l`fnm{vPv!MD7C)=5sICTeJju>6;TJ%VH!+Mz{t`x-)mhye6*^?xB?i zO$;J-l(KrMorx^q+~c}#^Yu+*TN?8nv&-PGcG2U6!^5~F2wV!9GXa%v{ z&VXVap65X0@Mw42kfb5&`9*Y5O0Lb~`q6xYz$jcIko3XX@#Og9z(FM{GF3VJkb0fT zP#0i(WetDqPemL?E6)(GxHdA(~cs6iu=DAc3${y9{^*j)mMQ$YDisz=p|6O zH3+AjhSsbpfNa<}d~R?y(y}I9q4X2ygQ}q%q!4lU+PZ(RnZSxo*)Q=YkXSBG7Q^0l zrA?DXz&zq{J(kvJeoq}u^|k$XJ;$YLqjJ*X??xDf|EuC25*R0io-sbL^hPSqx~0L2 zo5!~_mnT*qTz;G!2bt8SZylYF983sO$&flm03-X@K9I{HmDUuvaF`CL5qUkPI&>G* zQNI@YftIQ6we2sV)(w)id$ZK=%Iq(3YzQLQf?q%BrY|+bo<1yb=t+-9f2@N72I97WGqVKOUKXs z>kCp|*_iZ5=xyr40>{qn=61M}a9sSjFk;%oR1VO|Xz(S!Zgy{ff2+!uf4wvZRmO|h zAz-@F#E6%vj|PjhwRXo=va)adlcr9r8iFj@J2V0c&y(t}wl#H5>OJH1GB^Ze4~~#iT!ex3t-sd?Q6CWyPd7nvbu%ZAHLI|_hQgF`QaE)hb@?A_f&KJ(Z zQ26R~bw>8XzCaUV|0TE|oj8Cp*N6;#=wcd8`L(cln&_BeYt({6A9H6S(TP%Q{J0PW zW1IihcRTULtjobK+ah5++|rPIIp_^Rr5%T(y)+KkLQHk)16Xb8Iz#dA+YSHWrkq#+ zw6M&2%_fZHc^96_cZtcM;KS6E)<=Op!t$-kZ>O&hU!>+*v23ktzlmvD0sJlvmr{_{5gYo)J>DiwDIw{s}oX!_Emeh2Q7W6We-|d^k3$MltPsx zD)$?(qjPtb9*e?z*|Vn*(4Rl$1@iW<3y#m1*GtTDeKs+Q=Lk=HzL2Ja|+-ZmX*g zI%bdd+3_UCSMntc`VtSSX;vtx9Dk0775N-d_dzLZT1kQK=>7kCcN%h<1)=4DprCrO zyDrP$@rX9v^LjIeur`JQyi;KF@^|8B{JL8JW%Y|=)%Flq z?tj7j3k$;YvWJh8_)#KPOne*j$bc~RNhSnMigeg+BHV-cBqHVrpr!h{Z~cmLO}l;J4>IRPASY{cbI0rDThDD%K4D9@tPMnW~gf19yj zAukJH`+ooUzb9`2Dj(!!v>4~t{4+Nt@LMG1D2oA$B~g8*Sg><+%jtJN@!wD_P9+T~ ziKpst|KJRnBg6(C&d(PZZf{R+1;1`36%LSKtWghGV90C3+gW&26l^HLUb#_)XgWH$ zSZrl+A|jIZKgs`Z!c?LhMA>WGMFtSJga1x{Uwq-K4OwFeGv|k)%cT9O22;KLpH12I zW{E*|Hh5h}md;DnUI;q4&@K2w-!$N~Y&3=1AigNxJ7;W!-3VL06CFgsC|koENNMmrhl_e;$UO6=5GovVI;H(#Nk1X%H8!5t@!4$xn)u^) zD&C%}5^*u4tc87)QZHYPqhx&f!K=7fu*Jpq)a_W{neFYcd!;^@{d`AZo*E0>Hcs65 zzJ4MEJIe`0{0Dd^ZE6eKNHuu~w-e*S`H2>OmuLBH6FQp7r%>5>!4i7aCm@M~e%9an zksX6z*A4slbb5JHa(Lgy8NHd~kPnch@^vYwvUKJx}ul{|t2ZSJhut&A0pd3UHmM zWT}|K=KZTO`s?SbijeBxV&%r2PE2~-tuKCKz%_hjxO_BqB7q3#bvet4RK5x8Y?F|S zKpgER`rvBeZf94vv#&Y0(Gw~c+tI#TI$ji*i4ax@7{n3yYlaa0MyV35@}Z4c+-B0i zz5HLWg&g8P&_~C>(441d4ptyfwHSOoTqx&|F)Qrt&54v0TuLwN>dv&!XdHHpeHBmk z;Xp-nx}%CRjMaLvpfHOOk=^sVOG`}rf){UVhsdSPQ2%dvABBk4^CccUjO^EyR+i~0 z5y<}?3;{G@{;e!^ekAmBU9reU)#lYm{B}{~as8=$rWbgG+dsO$`#f&kYMBomR}O9T zND-75jSh5Ka%NJb*)Nf6h&I^kve*j%`hPnj0TX`wJGaOp(7_%ewtDFY)o2^xm|7tV zES}G$f1y@H7o-@3Aj*(*fTGJZi%T@p>jO)`#t+)031%-e$K?<%c8`aTCikEp4*fhQ z81uSyGARrWEmB+CrhTy*{K7XKyG;&^FtCd@)cYp=-USAsDDjOP(){9J;d&pRA$20$ z&YdmTFioKX{Ogx1y{3+fc)3OZ0Db3;oYVgW7tx52W3e}n5)D}4JI1+p{6ylRxga<* z(;N-Pn_+HXRBz5ZBf~9k5c|Rk1fDe%7+D5Wb%j0Z_Wt=I7pkJ!hb}8&8N4Q;lcG+; zga@}h<>z`Aae$X+IDC9&CRqtR9(=d(+E|qbn*KnLma*JZ zdA-mJW8DA=Q&A%R!FjJTl1<-3LMMs5VaTBoF+V|H}Xqa?QPI|J~MlIdB=E+V;UbNr6F8 zeG!S2032X40fV-{@)-mYWn)dMcAX~hJW4hKjgGg6Y-S}d)M|ECWOUW$D*kOiUx_Yp zMGINcEsXe`3-$3tu>pldVnUwujv5%!4MU&s#=|A?r&#_E=^*Z{zK^KeJ)$bJpR;@! zbrb%P0#A^AJR!|BPs)wHG37J;u!o$s8}>WPE{?F|A7$$|a#1x|vps6bg<%0ayo6yc~4y zG31)-K#GF@AdYlIDE(jJB{0>D;<$&5mkn7|UUM66{i^>87|s5Qyg`qmY*E-lpC;cm zOdXdNcuz<+#e*h}qw%rJTmJ!Ax8V@sl-J9Fyr06$l*71K{uZt_3bp^{){9e|~7<;V+eHpOASn(dQx53xBma zV&^c)e4gaLrmp5G{|d#|(`3uWOg@X&CvzRZyQFTYW_NXA;?4eFN%w!AA5Hp~yQE9m zqGPJ7Q8VSoE^5u8_Uw`@WJLuhhMw*C|FFYQaT>0QDM+9Ru@rn|kyUaGUL|8rb~*7S z4EG5cm4N<-cK;9L%|i(o48qW$hTlPRdmHn4yvoA0nEN^|U&?)I{z9!KU-`qV%Efuy zGY-HjpvF*=%gFTUL+&@Je(xSX&AYXY|x1|XFs^H9ut38ACEFwYrOAneGt*DDo21b> zoFsg}umS7oYepcx!G(?e|H84hbR}6gCShI!MYmUX>kdCefHeyIw})mp&W*>D>NFy6 zsE0zPoMFblzjXEM+KbP(8E%G#)HG@1_&jvf9WN3-ucGv34q?Pi;$4hFG&tYL-jnC| z;o@377O#>2GjIO;yZ}0BGWJ{;w;N-0r9Tx!pd&Uk?}@v(ycdLpf*ZMg$euzncZQ17 zc#jitJ^U_ndB&-dv@f5Z=^%CLAHL%ItiUW*`J|N@-Y|_I_oZh6tbfw6aT&Cbu&Y(I z5qZujspS*tmH+&|#Ra|||I1IO8rF;qY0^&lO?mm}kOIWh!uoh*F}nO#tA$B96F1_u zHx*m7r}K!ce#C0^E3`;_8gE0BU|$=_zIlF4jfBsOXp>QZhO}m|@g2l>Y@D6=cMtd9 zDi%%rS0$=dloc=pG#cn^KZf@ZT}e=|LGXC zzZx|V_WTT1e;^qOo_D&B&@EGme*-((FIHEQSiy6G$Iau#Ef$782Y$);*^vMo?WB1 z$F?2&b;eG=J&Uxv74^a5m4${A@7~F)Q0I1&_yaFlIeGD>vD~PoVkw4yklKG+8!>=j z^urIv_zP^@os3NfTP6nM$u>Hcb@Bw>Mw8&?W|WL?7KXd9n77|^l5tXce(uV1E-yta6pLD&{ zO3Vo6ozd4!)JkpR8+bE-E@EzYFB)gJ3=R)thIBT^|v1>^qD5ung7C3czW2|0P z2!D~^zaQeC7x2+eF_v5Qn`2MBsL>%*J(S*M&0MbZP9udlmgB~rMk_?$Ia}@8V}o@vb4Ka- z-?doa-;+fG?udmc;Ev5WB(J2JF>sO0mNFV9r!{C@yu@US68G$3_!HP%M%f8Gc6|i& zn_Dwt78X>YG4!?$Lf7)h94nm`)S=C2fXoAh&~&T7?HNST)xo^by4jje+CQe#w3#|l z_a9&7wdh~xh%iU9WXQu7rZJ`32wSd35#Q66-~=5zqoE+HfGoc!XMFiQ= z!T3q5%wWD0l);gF)?yh=CVfVG?>lKLVrQxj&lPO@Lh$1x(4h|YC)zzPRrLc(1lZUX zu#xI}ej?Q)4@syJ)_wY?k%_cnY-tl8h}N4tdRioV#w>}gHs0Q3;cTncz*8;cUFCaPjxccJ;c`=g`q=RL{plkf6)9Tyi4*&nyGQ=V;y zI6dGe15`9Lt;f@oZd=gsah+^wrdd57=8a*&O|j$ z;cZhI^dUEs<7;!Kz;7++x!*Qeqw7%h?L>!LwM0*lJ?oLAL0PzWx1J6JGBylg|8M{} z83LcvZmmV#9W4AX`d#1OhISdUiJ0ieQWxtpdC{kHTO(oAg^QtxAJJ6eiZ7Zr8Yg1A!xvjPC!T<`NV?SHTB2PhcE5^lY%EX@U1A~>Y5rjz`S5T3O$ey z8;oT(%+)N3m`JOpY3CQ#3XF6UjWVA_qyXXih$(g0>D*E(d@uK3)kzF!pe`yh{prdA zI$JVO(<>sJHiAT3X!l&C%#hmEUPVB={UP2moTuSxF~oDc+orl&pf}G*zq=*ozq+v0 zyPr=^oK3AsP7c5P(9L}rLaO=4eC7V3-EKe{J^PXuWVenzuESzCnh~86Aw492f5!K9 z@Xls2Ley0fTr(@kVQ?Z>cx~3A1eX-9oJ?b}8Rqf2ctJz+q>4Wbd!#lB)8J2orzdrl z22p}S#$Q>5AA9DFWYxTA3}tix(n(tUSt^VDXk^ z`%~QwkzWuJi95TDB|=ff%&SGL4m)0WRU!9x$}@(f?!%I5m!%)=1=dUK_*`wFHsVBK z?q;?Kll|MqoQuf8f+D)VUiYLY-D@p}zN4=Hz_DMFUq16KFo^A#h#1(SERg}&t&kxK zdn!+HEDxE`W`_r75MTZXvEoA@`6+bvNJ1<2MSLAT*ZFg$bPK)$F2Ou8&JikDe}Ejl zk7AXcK6dOfnmp`sU`Oy|kN3Kn8GRgs%N%9X6TDpI+fv@(%PXdvR0yEvTJJIl&VV%TlYIJzy;nk&7)WqXcDRXVQUZ#)kD}lO-Yc?OECL z`b`8Rf?M9BW#zSyf`^==-tlPuyY6sFkN@@@0hyYghXZMl+}V~rSBE}4Mk&7`G|=dA zqeFv5`uU<6h+Dtw%v!PRRbBSd zrH+mcB-2Y|jpZQ^yZH)zNECHp;YQj(1V_PrN{Vs1OvOu`$4|z$8*%(^C$bOz>Hbdo zQY1fQ3P-ckM*NO}H2@F~`%94QRIWQvRza4HKyr>AqDV#e3!R?kJDuyAx1`#I3C~#` zgYiBWerIVqP@O8_GTduv>oO4%)eVw3l0_SKJ13qOzvHW&c}IB}n#VCZCgvaX$}h<0@mTntSBq1>74-xM z=nzE-%L4n7lM+Ek=N(DohOd=Tyw34Ryx`_@r+C*qYHax7(u0~aDcJmDDQDA7+`kk3 z?#t0pgs4U(MvO}Lm$+B}`TU0T>qGtia158cLdU!imqtjG$XXkj5%2;f?Qw7;ta7nUFy!otjxZSFRA!UF~B#rfj)M^K}4%3V1X6B7st7_UE}Q=_%Xl5|hfu3Wsgwy<8%EaCX=JHDaba4%RIu+E4^T5DYgusvT7~d#apIzN~}y1@=aSW>g7DC zuB^djhA+hwJVSLK**+BMC4sHZ>_|Y#=1AeJPmz{N3Db^k2Jvco{!Jl3^lR#IlN9m9$+KlsAbET^2a{CU~cN?U8FR;8H)>4Vi^cc?;_fBD5?r)e}o@{#j zMT!WBd$||Z1r~o3%@EM$T2vfjNZOkmL29}K9nq5es^JYODf<WbxAO<`?_sSf3nO?r3Jte_Q^V1X;L(7f9K}-*0`5pa}|1zBQxBhh&5~U)=Q1k^P&gX89u7i8hi|G?7@jY(LMRfQ?Ti^WR1Sjt`ruV?7MIPbOrB`Iko|9C{JW!!t`8-01}T^w7&nDZ42g6)8c$bR1tZjHDh zU(^_TC=m~2&!i3eV>R4P)cQ&=u5lT8&KWA#bv)c89Wz~G%G;Fy-+n`@7*ea8Y6WTM zD_%llEFw@pmU~&$-dfc!xbAF4cC77j{A$afGfDpJwV0}~K5XKVA75p9nVC}d$!*xB zUacJtF(BC{JpQ3CCQw7a-sM-}+r{I6#ZI`@#v>7`qC4zQCM4iCGU z4uKULy6h?{<19|=?3FmALqK-_EtKe+8vL8}o={`&%E7?cF#|ok^PX9x+s^dp`fn0K z5tJ8yC4~#n3w6fM9qi-8o|*Y~9vy?Mzqetzer(q??qGAV$Y?e#&)YpQQhuS#fUwZT z@MEZ;&!tD2(=4ed#Cr&?7Jta{#VpPV7DaND(TY{2U;ufHUGu{@Fr`FUI3^`wy{+mg zR#?jL`S^Ty=J=fq#H45Hc)l^rYifz?9zZP3XZU*nc`#mf+lxnEvTi5vI|P>7l_8`b zYTKol^r*2`ZOV2)m|3LjU3e!%Fa{g~t)ky!_8 z?0X;A)s;{qXsIx=P<=hX+xp>Gb$Ac!jq*A(#O81Urt&*>jL$Itqq-Reba}Q;nSY9l zozqYlb(D|Jz0k|Yk$Qdd>*5Y3=}bUTT3`d5K(AvaqEm;@J`=v%(;^rSex3sYDL7y%6W|YMqb2co*FE9jQ^SBej@x=`0E*Q_tAM zBCa3wHs^8bBuUCL($#c1kxH((HdP7ree$WL{{OjhmY_|sA%fbAPWCv)Ox>`WTcb%6N%uc_l-c1 zs)%NoT$(uc>T1+hfL~QXTlY8i6V}HXK@|NpmOPJ^WycGQX8&35dCf#y0bEp?zl@S%S_f9o z9Ayr&*C9(MS7&+9&KGgJMLZ6u0Q5k?GAyIVTS05u^B%`ox8g&VhGjF(l=0U~DaI)4 zK$9034qdjVk?X?e4HGNW{w??|p_Kj@!{XTC#Z>Kg=_SN#coG-pW>gOF7 z1O}!m{g}!zn9U9>TV{2$jz>mxrF9wcb9r7j4|y=c4Dch_q{x2_+Ivu2}P#Wv-$ zEl5rpYt)OT8Px^-eB9h}*|Ls8L*}>|p$TK_5nvvP>-{vwxtX=2htsJejgNj;7Fd{T zBL7J!!i zGy!nN8JYOA5SpfB!Z6NP0#DDTeQ?`6;&&~1jdZ!{j~f|nI!FWz6bgy?KId0)6C{a# z9jDpH%S&>H2*C31g#20hmH*?yeMa+ulGe&M0(UfBHHKXC(2LhH`m0_?<^Vt;l5RNf zNWMN(DXyQT;dkc+q2jtGuvVyb2;3l)QOTh?yU|9(MtMXHc+OLcSG%p_!-uP9tPR&b zWU1N^4B4HRZ8t)8SR?S0ClhC+r(#`XwvntmkjlKIXWzd=E!KZcDfx<6R-+uO*cIYb z7E0Ts9mlv-gmLHc& z(|cz48#~IM^{B@l`&Kue6_AugtIRKc(~qsoxzN%5?6tl;X}3#=mOQ_xR(LuX4#VJZ z+nrgS?T77bebGb`AGra~6Y&KgGP8l^908oCX!7ppz9%8WX&I)~?`C|a405Czir?hkvN zlT|&c$VysIzAsX^MRbvT+`!+j&Fo|tpd;Vfnp{s%`H+V93=t1XGGdAIByA%n8uNQ5 zy-&M`y=z}Mjq}$XyBR?OEq5#mUXzSb^9_!@yx6DB0-5h3NU*^vgy0>gjp2jGWue)} z<2>)|5N-@{6BW4YXi3HV{qGDH`TH-@Z5t24;hUUFFYDWI`yn%Na)0zIuGzxhr94lT z5XEHXhsKz`8jGC!>G0lSH{ZW63ZO!?M*NP=wp&-^1{K+P)nu$;e*TE2d!PsdD<%oE z3oTa703}zQgViU8E?EVEgC>RsQ*e(VLwC4%vzD-Gr`YlCcs90oHtemZ=AMwYbK36y zlxg$M=ejp?P3>@DqcAEfxa51g8pzVM-1&CP^1RCew1JIhDo>1m-~!+M-%QD$X1b15 z3xdws=z7|_(NM(OJpze4o3eY)LtZdNLN37OyPWo?qf)>Cu{*EvUyIn%^Lghv1ohiO z(G|_l6ojlZsuS{1B2(xONKS?j#aROG4fN_o3)aqaTZbFuB*HqGYs!M>YwKrzpX1f& z-_LS;*g2oP+9H-fm3HEVoVezTneJ<7xV5EjCrcbqX7y>;zSNyL`3(s?=;0h=hUXcD zDnvrD%lPvt4Z8Ix4^`0*8Iekjltn4(o< zXXBnL@uJ8@B|nkX2{LA~X>@VRhlW?U`3k9aT1aU&;Dju_11$BHuP=l5-xLFWM|@(E zs^M}Mh0`Up$HZUb)FZctbfOt=zq2w`D#LB;RIq1UhLjOCH|SJh1vGJD*p$iGRo9@< zsF0}`SE}WJGc#%P)KTGAfk)rz5~@9+UbdX1IJuiZ2xIWjqBZa&0w|O_?nlPiotr51 zyujJy@$7QhUn^21eq~wj`Fgu^eDR&1RT%N41J>W)?(de@-{wd>HXx4|Yl~~aRbJ#s>4_BZZf1WbNG)%12&DAKsPH-@o-e zx;?HhV}UD50;in!;n{(x!V9a1F|fw*HxTVjeLb6Ry_m`iRVF6r){oa% zxb82mJGMyKzww-XKr5DJS?j=_n^!fR)9KYHRZ8fKHHv2@@Qr)jD7imf>|Dt$KMkac zGi!b&kTbAdeew)%vTm zc|BBk9M=Q~!ZU@u0mNFU7+AQt%Zfa!JEFMjP9Ogo5|{HNBkc|*asg|e`#P$sKcMaX zd6D#nV}+l7-JY+nzn#CojVCi3*aBaVjffjDmG;3-)-C_NOg`5Wu*JGgEbs&0`>|Wk zB-k8eBd{5SsV@i)MXc|O#1(ko!E`9uXY9CN^9H=X-Y>^f%YUh~Kba6mt*;#yUbc^Y zzwdmnZ(Q>lhTI+?@gC`qCbTO4>GfOaYLF5DHs|Pp9i#fG^G3kcv(|HAxMWoR12Td8 z71#2w^A#xOTexTlIessf1NMV)lmVLc*o&QoT0d+@q7xzU8cWD!-b;Y z$xQtX1d^Xma&bMGTz0661bP*_ov+WAyj<3VnyXfgny{dp-4JtAbejm{K(@q8f%#Kb zW4@$rnZh?7hhJNX?qUGkW3H-5te?tNkJD@Q!aZ&Sb*yy#yR!HOtv)5g44#&@H1Bv@ z^apFxMV)t1Yi>EkV|{$`v#QbN>8hkuNk+P^JCVZ?b{VLok1mCAjC)AOJU;s7*l!;Y zJP>|Omf)A1eoIE$bZAD&sy9|7>v-72r>hcCB{MbSR59gmU*0NG|N2R+tL59O-190A zi?eb^ngJn90s=^)C=22FqL9{&a=^~nkXMY^`1iE;ZXp*`Lb_O>GZsXgagkD%tI%|tZCi1KA_AwT)fd?Os;0DF+ z2sqWW7?nzC)j#r3i^JK3bzm0L)ho-bZJCAhFv;uzGgUW2~{>YEZ|5PZhTTioiZ+qlFE{}vA zOyP;>S6o08_Av4!-dzzqC>*Z|JJy_8Pae%UXQqcJ_~bQ!K7^(2H5o;JH-B6Sjv$?U zdwyO&`rY=vxB;JFYq5dV%n;}>scTeZe^~-G+JRINCrr56Osekh2imN9`97v}<{rM} z8nT1~$Kjmc?lxx{Un&@?n8-T<85)MDV-bjwc_6{~GS|??*U9J?Aw_(!W&phsYeN`8 zLN_r*H$j)9Fv6OEMO%wIx-&=A;yI0kN#5#28Oy7>OyEkDU090fCIg3`uHY=@(d`Ux zNeH{~sU|o}wG=lFGBta>rk^&Gzo8e>Wsnl8U-+&%cF}cQXrIC~<6$$D6aWCnMF8e> ztoWWwD_Vw#i}<#}C{J3~Un`Ol6M4P6@H2bB^-~%H9Tv57+PLoU4z7hvf#q$Yu5d!s zPpG^b5CVItW-D_7WatyTz&9T_PB;{z1AjJsNeI@Qy3JP1ega zFfqwB04!Q?dtR9j1Qf13c)vaF6L%Fd;u?D7ZYMj;B<0{OEjaMVK`~RpA+}&6*SImH zEDSxm_PI${$VcWa(X{#Px(K{&F}Ts*x!xU|@+@~czUC^4jjIsSX0z(suGn*2yCs>X z7`AgQ0ssP#s>H4nG#IFdeAd4b{_I#1;C3?5`qHjjc3eihJ~tenE_$EWAp!v@72ZUL zJD+qQYIb8thN)eJu|j{z6@#9?=EYp0M9U0hLy`I&px>Qw#DYX@BwQxZ7l_O$sl=OI zCQZZhZ@^RP&igPgDMtHLyXj)7WH33X&wKn``aXe_nHh`c>O{<`bD2Sas!E zbFFx6$f<(K!Om8Hq*B*7S7El#sxqU7&Kk~0p2G@7fZqNp8r7&%Yq=;b@}!Cj)#+a$ z?EAFP9gLVoOcqqNb}cTCU-b_yhO1=<5T3#U0Z#2!+8oc8WA{eGh2UN zyC>2v!BeV8fZL*acQRx1Nw||1zCv$&J!QP5H3ab1CGt4z zzn-4aKJLFA=Z`f{khE^&2)sWT(RU`AMbeCLb8l6d-3YJ`WfZ^9eH&o=CO7ORwB28y zfpv!q2>hbGj)S9D7f)3efqPs!&(Rq3A6YB z!kK7xt$=`04{ZM;@+}+6F-CwLG`|{%lUhc>*SuQe^nL~nWa@J+5rlE1iU#n)YWq8D zmyJ(sYI3?Hw%-l<0(xnM%kN6w%KUZ!T{H7+gQqxO|9~``NF!^gh1FX80);&1D^C*T zJIfo&`p}kFb4&U_L~GEncl@yFtJG=QcrbgN&zas{F$&w%&g7?kaBs#OhJM`+ykEcj z+WXKx-}RE*m5aA5Hlm(ZSOJj*`N?whPm$v$Jn-+LP*EW^_g=SfJDvOyCSbz?n4O)% z6-=5@xJ?8{AuPk;?0v@I^=LLdqV^fRc;0)3&-!ibvT3tJ?h!>{9;#Pgdr03VIxd1) z799Pq30uLy{giP1A*A-+d2`%Vubuc3gVsS%XyfM6^DR=N8H!Lg(RqBT=}bd;U{p{8^6?{BXL^@*8U zHt||sPob%ZkExG)<_4ke!HIeA5*z%>eMvroVWJ0PbEp>AkqI6G7k2`L?_)vto*Re2 z@Js6J?PpHEgywe^PxXDdZ!g7bx zSu_#=iB69*SLtbo8t_`{dO9#ZI`3$Bu zo;N`NuHs+Sp@AOzS?){K10=`aH_omDf|4Bq7e|^cte;_v z>bIN!K-mdvEhg=XluaOYNm{TtDk|yYuw1ZD@$Fyz$?-DL1EbJb;v2D_Rik0eP~|Zr zvzqqm+xk4jvWNt#X|Pex??}mgfSI6HmR%u&8cGrtnUbiu9&^;U&X3_=lp^(Q^S8oa z)yY63tJO75hL$pV=o4yL-6!{c8C!31DX_{}5LDk_6Yo?gWe(r)_C=aY;BJRY*28n8HPqVh6}B1rn*^ z?^u+o_0x3{QxOhO(Y0-S;Cx|Ms%alcPG5d1UGG(%MEtpL6#Sl- z*8!q22^&^FJ&O`1sgO1*zi7RBit9UJLzW!$!(er5?Dp~%cR&XAj@}6^&+mXC(tC$G zX%GTM1L!s9`wQ)%3z|)L5Io=yEG{o`rd?nHv;Rz>@)Rx6#(e0#=MvNS5`1u7>H?%g zosMraKwxtwRwrex?{49g=g?_Lg^=}56tdh<$y0=VVAq1MH%(_}hlD5PXy>J#M>f== zx{0mi56P|!=5m7l+18}lO2ZSw`%7f|?SuGIy6_79=kc%WsvS#%<5GI{9^s>DFD*1R zw$Hupeq>_>Te#ZMMu(|U-1c=EsBoB%GQ3ICM&4sTJDxR%Z8NM^pO7(9=vuTquZwQg z;)L~s-T7EiScfI}@eB;@~s+oz~!#M|b&DC2iuT_&_6|xaP+$z)0D{kLBGRLS#_L}JW?c)inz&V_V*76K?XPrgx zs=CyohER^MqT4UPN~TSCP5*KX@P1rKBgBK>o8#0&ceQfawxuob>=a9d2YA`vi$UYR7RLNOxFjP@cDKk#r9e8m9syr}`{$%uS z%SnM9%Rk5uI7bIHOkk?xHNeg@8WaS6sFa-@B;q0gX&ik!>T(X1yU5ma$%7Y=yl8hA zHO{8=fBjRIG-q~-@%%*FAErR?OC8rU^!kLBSQIM({>Y1UP=-DCsoa>R5WHpTDmmV~ zh}=KeOp%R{og*!PO#IV#^Tco&m`=(YO?2e>eA>7=$5mV`TL}(Fkjm^x=&7bcnS#rt zC67@ohNXdT-N9dZ2ET;$=h)LnOXRqbX@K_AERU$ z*LEphRP*_MmL>D<=V;nhdc%>XB&Kn>_q=es-3BD)>{_U;HxXJf(+-VNoE@Cy(VH<2 zpcF=7zx};|i6xEc)i;A!W^iz9s^p?0UX_q#ap#SBZLe1ung;o7VQffpuUsy3uyE@O zGx(lfbZX@VYBg+D*;dbMP&xSu6_>^n80=80S>7l}|LbhRkTzmQ8i#q=c$Rdmrj&)Z zi=Ez`(zm}6h+>et@E*;x#>xo`Q2~(*!HnXZtGEG1hdB}7eKQ7pQ^_x-?nWYAACK| z&$h45oW0lBENd=zNKV_h!WAMU+R z8d!X0Du9;BZquWbD-amw=6Nx)R>q>An3(~cy`TDsS-C7n@a}t7-PzaDzHNWF6$6t& zX9l>zHdtt+1akj`Y#w1HhvUsq6NrmYYaij}%aCjyX9t8gNSK$l@cm%k!R+;lfmr1f zl<10~CX>9FeYUd(`Sm20l6Fi8Ry~!Pv7f$QV{Xsm9owG)Q=8a(ydMZ5(i{pWB{)pC z0=U&gc%Qg5s(>5TQp?j1e+*T1iyH1dxJSFDVtww8)|a19&Q6;i)2}m4a{C<_{2RI7 zkowMhIGK>K)k1h(T-XakWbBP)jF5{|t*?IXZ2~A4WCt~YMRp*h2zYLXPqm?jsSX3t z$6v)mZzd#)PH$;awAdI-mbR6FPwH^LHb$QNU=RuGaJvkww#0BtNN+r$KBtvgD+?n% z!cbj6k8Hvj4}1?{y=>?=4F*LAr;0qxPUHpq_}$fJ*Jn6(EcW$%MtuE!!k9yY2t6S> zhF6YIaC|NQ-ftZG!e-lg@q9JR(wYUim4|dgO4<)=y+=B~2mW5FGuOB7*}HX~y@epi z;JIQWu{w^Kkq5w-z>OwxDG2+HxsK!&Vb(u?E=cG#h#10;-?3;6qkc3?zVAC6NGEe<LMZR2#2WyW~`)qf#p z6c+kJV_JbzxaCxiMt{r6nVwTGwIG^UUn)h#{%1Olr>{{jti9)4fLfkg=hDkOYR##< zNutp3B$ubbRqbg=Xz@}>PclLimTqH|J?26K#B%3jILr@(CVHoONR0(?b($PR=B6&# zpkX)}s?JnzY9pUolc5O4(42Yxq+>bzVO{W&jL@uM z#I4Xqk3(7~RXr%B^6S)z7ok3rp@Wo&Ow4Gah=Dv#=Gw+!!nV_{w}px39o3Y4!mT1a zbT*uF&{(owm!!e}_J+dC~!wqW~K>1-bF;T&*628J$bHEs8j8|n%Av`sJDxks`Hc_?t zjFckhbCr<&Ez)=Cml2V(GpzF@^Y#c_Hzw}s4C&BL7AHOFYe<##br;Edf&9ql~8oKWGiN>sq1 z45`-z<(M%56;=&et`Kfm(`;dK_^Y<_9qRy5F>E+X>;jIqfDLY&yIxhqzyoj?h zkCX)=ZWh}~o6Ipe>K-Ejd=p6WW`C9t=x8T~CKYjP^L6dO?0KjX1fL`468GkJqt%fE zaKyfT7&Zj=^Bb*OgA?W>+$kmHF6{jBk>#07gd!L{@jpu~g0~N8q=g#6X`J&70l%n? zt4DkH8O~!2URED9^;28e(QDtH9apwCUwFp*qm+jqOGh~X%pFT@&rRFPFRfMDLj{qR z6LP(^N~bQ29F$8>k@^{TxDa73zBHOcd$iDN+v~l1$M|O-h{$PJ8U{MAv(B3c)0!^B zLGbOroy6jlE%W}6`2Hdigoc0;HS#*79=NpHGLK9Lk#0}BlRj-v?+_|ct_z~~Jxpi6 z?KD)k8`1EiG_f7BO>UtwAN7V~BBxnh^_z#26H7=BqV9I}9?$8VbdfGO2Z+YYmM7W> zj?Hz`>A6I@xf$N8b-q4$DJ7fd>D8Q@Z~CZJG>19dc3_iLw+S2Wi^v8o2Up&1_fW%c zmHGGt#Xh@T{h8%L`F1}tT&IMwUWGhWI}5WdMrrti{QfkAe?JR$il_5Y(ftQB`>_)n zU(lch&H?&|m)yV4vgb0#xZw7;tGrM=G-%W&?A!lHUTq>cIH z%mGR!D0VK-cr`}_kuo0yJ`?4%sd)K{+&7Oma}QEuq6*!_C3tp%qi?g?gxOz=o|on` z{Y+NgZ!3X(&7M!=>u+~F?rgAK*jar}`)mg|mL{;NG(tCIl>Lw&X)3{SxbG`l(ZlRb zplE|%<34*F6`fN?5E+bT+IUdBxyN8sb^xG)D6qyh@y7v$|;|Jw#X>4RmyPM4LaD z;U4ZMof&YLyIWy!9B+s|9;T+G)sd+`)s3nbh*zRNBBNk44vL-6ykCrS%1Qvef(8N#sL%zW*Uj$v!)VKl zy$^yJ;)fucQ+TQ|`nISc-WVf$LN7=&2QFjm8s#OI*gcW1r=TZvA&gw;^l{!YTzHmS z^=PTV4C+Mm_GfKq3^ zkuYvl^D&)~F1LK93GR(=E~WTnaojiKz_;lDc7ODBf3+?={~!A!X&eTv#fp#;HavZO zeJEf4*jOzSDv`ei1|#KQUxbTHK}Qhey9i0$|ziAThK`)w=2r0GWFd2w9-=|p&< z65@Bkdlxinsz{Vv^F$a_bezS98z|0Zq`;fX_B-AAN;*BCwhe()1Mz?m$U=S%O^2UM z>9+x&c;(QTE&PfP{ zN66|?*8QfxqMcRUqF@m=?%wvr5766D2x!>bLuCC!He{OwiOxsSAgDe1{A7*cE3yB{ zh9?fi?|6ZHTuIoguH2w;a;R`Bv?XtJSe~^W%b!Fe$-Ye5#G6oMW)@^dF%L2+3R6MC zK*k)IM_tx&I^43)a(|L*6MAs$c3!2$#GQBbIx}2hS&pbfZX&)B@LQYM=M4(E%%nCa zY$r$ZG`*r=IwI|Pp2!uqpDK`bh&RuZyu)<&hg7D~tdN22qT%Qr<)+YAed)0YsQpgv zcLkaTw&K2qr;ILB`$p`{LM34nG`7lpc&Nkdx6Y)W{!?L}c_a0k+NSO~)589`OqGyO zq@mL7leMF1#qv@8ZXR%2PCo0QMGpHr0H%?-LvjSbz4BQ?$Qrs%dI=`v0m9UY3DPJP zQ;GMFGq>jeivP#r3T?9Z;P4bSS|(9!Wu#DA$QpmyClq5Ge>it^(Qsm~Ajq_}s#WBT zpunSTazVsTOTr>z)m&eW}R z<1Si&-9EI(4^>P3fw()fSjjEV#1xm$s5^H$saHLm&Evf5o673+6A(G(t)E(s@3Y=t zMw9(c`Hy)_f1Q!UC;{dUHWWe{YS??jQ?E|8TOh5hPwDN8BB&Dn4^3Yk7UlbVy?}rs z-Hk|hcda5IjWjGsNW;?INQp>yH;8mC9nvA)OLs2a`7Ynj@4fE-_uA)v=9!r@XU18zepz;B5YKj^oH(`IDbO;PVR+}dr=3zcfVaR{!6-xb)gaMO+5 zJWNiV9TE6B!^5@uW@SN#CL)Tx2YiaE@Qef=KFGN{ds zyT!1MPBGre1j~;(d9{cNq7I5h;tr!KdRc>&3kH8`JS<-i^9d#P*Zf6=2C;#LrVgG zmJ41_?YwpCj3fFr>Se4K;iD$-@H>uo$?ssn!J?CEa2l6J5|%Gtbfvka6#L;hqbSx+ zrftNsp17CiaJ9QCVHm;zTgvLbYLpBLygH1q8}jZV`6LO*CI83J{pLCf2^d7s zFbl4y5&c$Tr`6VKblj)Ad`hKEB|s>*e1Z{8BkDUabTE-IL@2&G!Lfa+JbxND#{eh~ zV))v@X4<_<KJO7mQ~`zjw;Lq0UwdE!=@ zWR%XO#Z*3(;&JaS>_^SWv`G17l9x+DX-M4m)nDtH`twJ@%mlGJrIc(`3V+xeO)YeM zV&R`V&OkepFD;%_Z8)w<`E;k_mPY41r+-}}%L|zBB8u#c(>HtEI&YeGE*o-ko}Y*o zNtaHJ?wTpN&Uz7gwZ-6yxtm=87decl|70G zzP=Ty+dj(vn<|YDz5Ihw-zUtZ5H|@Suku3W@Ea0Iz+gA>HNFUtcaiRR)U^7IpP>DF zGgFJch_OK?OHQC14JDa>$J&?&_zro0GjU(rP>}W0MYRjN(~PNq`d6(SxJiv&80h>3RPjtT-&Zx}(T`p2kW@Fw*2W1>AU zQvA-Ms5jI%FlTwgC&@J;r=nBwXR|{xD&PnCCVVFGo?wE)*#*;j9tDkz%x&a&*pa*V zk5DQYo@A2^vZoHuVKQxuIg&bq(qMytS?=BZsi!6Dlh0oY(njVVe~dzZcCYtF9khvC z3iwMsD|R1pjwh0&X@90RcpVBmtQmFPTTiOuqYQC>Fh;utLAl<(@3j)V@MTFB-v}Uy zSwlS;3=k09C%-XT>sA7wJf|-z@v`>&q+LIGudJrEjI(Z9@Q#GS?CSf53|9$I`w;`2{(#_wOiOrs1HQ`QnBS2lCH z-)H|^8C3DN3w-kl+-y_s`hCRVIe%}5@|x1kCivL*d(K8TDvCk8`_8A|S+cQZ+`?Gz zBHqLdpiEQS=-cCtAqkHj6-jY&!1VF=~@8jr5V8a#sVQ+ZcxI>vlU-a-WNbJdt?J>fBVOY7E|DK#&iA|M0 zXdy@5yE5kifIS#i>H1|n5=qX$Z*3kQ?U2|aM^VkspO2pU4hxSxgkP@poAz%9+=Mq_ zoIixdC@tG5Mek&jT!)I4=?Ns-Zji9Lr9AyV`z~iozrJK7rs{3JeNs#_V_9s*!vZJ1 z!8v)GoxS7`yLeBHdDo6w^P|gMfU4pdh1h=e-EyW!5xLR#i@I^{tY2%ta)=GGrbu8t zvlKA@9^AJigx$Z|{l$7^Rz_0rv`Sb9GCf}?Ar>^Z0*)KFAtEgau8M<>S1_ju5-TPdn|ESIT6T zFKU~n-$xGz67?ySq8z-p{=ngE3nczH5=OuL8$ra^5#gc3$S8O)=%*3E8@DJnTXdtx zC_7;cAZDUC9s^3`Ya~?v*tnunV+3E{twF#?1``0l1X1vD6;&o$mZTAH-7GuM>oa+` zGI2*f2T|a=MF|wZD4(g<_cAO1U3Mx0QY1Qx>7mWeJ6;U)nCi-iuojHM&qzqdh_4HY ztb>OjbbFn37a_8wUHfSX+`xo@H$YkMO|J2dEh%@3z$`;ucI0)J&uN#iMDqJ4)9>=x2f41XHzh(oz+w=kb=9-F6Wq_qh?B{yIxQu+7PydE;9o(rQs}+EoN2fC zAfViK%f(OE)c5EqkQwyNIJoO$R?aYwky0veaXG~u?@5*g?#89>##IYLYJcL)$wQ){z9S#y*2`X6p7qIN^ zd2@WSScm^P;OX}+TdcQC$+J`yc0&Ars_HsMBnHv5}u z%mefqj;C$gj435wDuH+Lf(CvU2x<2-C9VerSvBR4Kb?oul&s_$s*P)S=iLr$4Q_6i z5?O$%G<1q$G3Bgp$4Y0!WgYwlF6UOHa=t*y*(ZK;9W$c^iT;sM`^$LJ2w9) zawSfAOq9Lzc)FQ}S7iTbUWr~*!k;o^n%|@Qrs1{Z-Ba4dgNT1LSl+jkG%TFW704NK zBYM+49O@K#7notNhV&Jozy|zYtJf;aJBJ(5V<-guR-VvL(&+obauLwj>&Fh`c*Jpo z{vWsXAI)3{Rfg+C0;l4H^-=A88?vTZgIG^wj@CcDM2An7g_(e4C+CviVANGX%YLGw z8+yzeOY2W+w@Y8{dj}`+-6kS;#*=EQL_PdYE8G4>1Y;bDNC(9GS4Ygn@pYmtg`><3 zSG27)gfRAM4DZL+Z@O~V*esn*Umg0?LkkIRks*6@(p8(ZN#~* zh7}1F?Cy)4Va*{JBD|wr%#33ho4i>~WerO-+acoxA=@k<=0-oBp0dDk?(`gH4DNmF(su=cngU-mVqJjUyy#1JAP$`F0AfnrPZeW82raRW2D z3vje<^qIw>=STA>RyD6pQjHHn627GQHHi20Y(rX5v%?n%cqD^HBz-zM#{a?5WZ_jC*UewsKFJvGcm2iCd_mW#OJLT|Nq$-T zA)+zvtJ*{U;Ot0{B7u3OvQog^>-R^fl?>@gO#WJ9kb0z_hh|;KE498gtu$lq`j{>AZ%mC&x-T_iAuv!(tsA7qa z`A0-v--|pd7lt$(r7M(jItHky;d*zG7FlP0Zw|T1`xw-XRWy+OYwB;&1DniD5Ko7l zG4xY=MwF$*Wo)W7&h*1(pp`-avY3&n<~n(oMS`nCLG_YT92 zEY$NNloasOo?$*j29?3K|3_yrtvLD`?p}b{!n$u-#<3wH@;d$rjH+4vo6e%2I~M-y z|D7?N)ZQPJQlL@5-(NNv@0Zoh;tV`SY}*gtA5@g!jW#{VG<`fZ92y*nACc>sA~yf> zu1>n%wB>SflK-~2&t^Cl*>yxiKs$?C64u!MIDZD+S-6QCv3CnOWR zkhqh5d7x!7tLLPc@$YTA$mknZIQ7ZwzuG^XE;N+!WJZSRfw%ri35So_{_=sJ%NC$G z`j}^nqr%S2ygrQ})e!gE&PkYbgl5*7`Y=KQbHrVe)c)Q4Q3%UVKS<3Z4DDtEppY&Z zR*Lp<*&&7a;fBre3_TQI<&8V7Z(9sTkDlWIoeKluZ6Ue86$fi1KzKh1FrKd3O>y!o z5{UU0L0zcopfTB|pl|PkXMb>R61I-YzqW}HJtN(_EU46<)Wj>=#VjcKP)-lY)@Vv% za(y9gIQJ*e?^-7rH-pkbX`F}YJYegL%5h$1{Rs|ZrNN7iWDh81Mm8X?Ifu&8W^=9Y z*QjArS_z+7UyqStA8)#2D&q2C%e0Q$Qdlo;uu?yhNkw>Tz6hq3B{9(EI=XSyyAk!- zWsKh8Ljj6O2X^x*9_m6Fl})0AzBT>3l6i3r=d#{qBtjq_XvBsZsd_cj1qSVT^fpon z^A9-s&2;)lZk<`do@T^^oWH@<9&ZC>8tdz0AZnOB(yd3=Cp-y)gY#d{yj2n7E`1!f z_L9f6y*qCJL@Tj<5nx-plRkd2#cmV&ufAsh?6PoWk5}0A+sLFn6{zQ@v4m?I7yjGz zORi~Zib2u!qxD#EcO+(OQ?-^M;r+=e>|9uukruaN&09N_4udkLCyyje$3GXok}A8c zT>kys(GcM9-thh-k3+#5KfR2mrm}=@7%mHk(lNLy6PDcE&^hSV(Ba=KpHcquuclc| z`}Aa<{YLAwh_v&uzXX#~nmWThf!o!P3UCsRlB1T!%$(oxU9kS;sDRC8461C=*8N#M zpYWsp;)*l{eE46vLD_i`_i8X-f5&=l#(#;r#&@p6-5pq754~!a3(o!dcQ^f!WDoH|yT|P` zjnjl zqmK)pXK2?w!rS|5z7W;3#`VPfv-|e+8c&%c6NO!mronrfzGMvZ3#SMWK?A^R`XN4p zKrsy={TM(2a*uYN<_Hm1TJ8e5BV0LN!8r>{#Q2gV*4kOhmZ8Y@8?=Q=&*0XRYl+=Y zt_5k?6rTaBpQ%(_ZAH>fVrqKo{>{2|OO>#sdA?81(e-z9+M_>EnNxH7F0T>s#Hn*0 zu8t~2rAQ)ru)ZA5v1qFFRZLqxA;Ee4^<=XfNAZBi?-8;q*-&tjK|fTVR;O4D{Zyan;2ScQBr~g1e#yD!zR;s-5!w=YS9wtoyk8W`m19 z-(@|lPd;=@<^ZxM_Bsl+`1)&F)~{dqw`Ds*-uZ=q@OMmFBLkH?ER(Q>>ros0&(l2x z_KMefL{>##0pX<}3tf+SVfDfR)7w;4P_0QTfk`2#S;=Fj4Gcj_^v#(%e06QusO@g{ zo0E*is`OjZXGP)x)Jb%-ABMkV$hq^gTjAF3ObwQqLXFg9 zk+fAPxf{2o!h%$*0IP+G4q}|Lf{rDO$Jx|~;Ex08$eR(qRE-*5A+9$Xnz^XeYn*>w zW>w#Tz-4H4a?|!-$QZ;sz9;O*scC8doeRLkhe63P(pA}QN;i%Er9-p%?u z)g}C~5sB>;8yZ<)&~E-X(>UEWb@00GlrF?+HxI7MUK4TsW3h`PA-lq+OS2sj zs%^K{LEn8v&5vLgoT(>=C!cqAT0{-}2I5Y2SD;6?vgfAJAouk>S}(Wocly6SQZxx# zb*WKm*;Uyo)6mD}hUu48I<;A1tU|8idMFN4fdSB;^8Dhw)EBmAxDnqzWfoJUI6pEo zL*^c0HTXU5j6wA|ohU>ukkJfIC|Yyz(LI$j|m?Cc89xuMS$g-_# zJZ`gkZa$zVbDU#BOjh12KiP2Z1QE=2da(w|M=C+CIVSj2F2nZ*G_Si;dK;Vn9Yy-N zZ8h`ty#0;;ZPH;LgyCvY^~yHC>oCWAGL&RU8(W^Pn8$iHVg68P$mT4aV1|ofs23Af zPF9XqhfM!iIe7JOYYm$b*qKM5X@+*G5rMv}u+Qj|m;ABn?N0ns9x^aXdNybO<_f}6 z-#Yz@`v_(=_qfL+&X}M%Ugjpjmzw@D&p$Sq*j*>M=wO?Csq!~lR~f{23k`I#X5s}~ zyN5-DKEv6;%se*QQRe^@C19q6Mw6nv%^m9@FbyHVS*j>H`u|%Th})# zm^L9{j4t^x5b;vz;$9}@x>Z&B8%b^>RA)RlS-iz!jkGU95AtUUMlH%^v4m1a+s6$$Taq?&X1k}{YPqktW_gMN?SvN-&hcpIFolRGJ9F<|& z!oPj*|E!wO7Qr{i-Y4<9chZu%?i#I|LEL=5B)2*K74_OplBgWjyJi^zF9?@^RnQ#S z*81=ohY_2xQiKV6N7}5qCU?!IE5tEPzk0E7M6W!9uy~Dhq6^+|H3i)=7pkIgmHSh| zyKBkn#JvH9if=|!$0n864k)+T#nGcXE{0nnOmJczjzHf!prXA(t0hFsM~UZL;XQG* zyN;c&vDrV5nwPL^SWGzBSZSPZ^MG%RyRq}L#2dYdciErs$$+~4`iD<9I+&QMfTp$}XXdHE3)+aWsvAy`UV?1}j?u=SwB#{}O5oMC5%3n!02u8>9JZ zm#gJpJ(|@fftRpMyFO)dli(#ZS_zUcKJ|E>6RE{rK@}65p%JBeG=$GZ@3nj#oe|Ro z>kY&OsGa`GX9MAL$`H!eNr*Ue^te?xAwMO_k(82EV8$VoTJflrfumA zbadD+CHy6oM$iK2iBUl1V<1kiRLwKKb;t4=Q#u}(R8T1SAj={%)g>FxvirOy8zYWe zbzryvb?ONT{LZl%$7s>qeF`(lbaZu1Cws!uxxb}=XZD7XP+jXKG06=npgRqdaIxDE zGA%;119nO>aWe-ogFsmT8#E&9uyX|%@NynA5Sb9@b_{hA%uRllG1gc)gn^eCdm2pB z*aX@GJH8eA+OlP(hOl0_*cTP%PCPxPrRBR?Bny5;2tCMCr=0b(xS|I)okeEsqPi=TU0OlWExRhlZetfx`D{CaWI>g>y04oX2u zn2ZyxXBp0~8HODQDFk8_aUpdSayH41O0hDQm7mSLHwUnZ6#jR)@C!!bjwjDv<4-?& zM4eZxV6BZUKAx+&eufhXo)sBqTgUQIo1ZZXW5cJ6QcLyTl-sS%#J-BP>fVZXm)4Bb zKiM!4(#bb}ax7BvRIWt$))ywJLx~_0F{L8}E=W=pIC;gH0_^_Z{YL*p{QVtqmpUtA zui1LF z|9#P|z@Pm&2PlWR#gCh>Q*_i?5LI0tA#_IzdW@i&yO_UuB8dRR<~w z^)(S;K*%Yo!)A^bKAxkXz7voT#_(7~Hh{1q$Pj0N>LKAMW)c7Vzc_2#ekkYuHFf!h zxa~#Kw$HdqSbm4}?%zn{MPqp!;u%(f|HEVK^bDWG0w(dYnt+Hb3IL`d<>@$wN0x}u76j6pEh)y;UUDs10-7QcT`3)uxXY83!`JJ7< zaqUkbf;P@B=Ys5@)_@h?AyN%VfK82?GWwV5qeuE?ze&I9ea9z|Sxj6VgDdHQ`Lu78znX9+zDo1r-O|9kQ) z12jSOVu={UGYe7e_O?Z{VI3c8^%dhr?a8WRctiBoI=0D90Vv@}Fa7$-1Y?<~V3U=*;RW=3t6#A& zH+Ym6S;xytP%us0p#21rRY279N!-|EM@s&sCf0(Ac4&bAS^YNfaN~P$Nr8f1sEwv= zZA_EeeSBVsZhbk0Ft`Gy;g3n z(5pTL_!o9Ux>Wo0#1jQgS!r566LEGt1#NE1|? znQ!!>rO_a79?QY70*4U-o8g0XFd-0F^-?EZwvN8nryhEpRhtx}HRquPN zaKLAu++6Q9lxP)9%j&4Qr#Y4v1?en!?!s6cFn;a&zdwVBEE;{W*gsLtoJQB!FW}N| zCO=I`CRADC-vjo^MXCkx9cO6`jip;G%n{oi-Kk_%^62jtS1c7IMN zHW8Rxvh|1Oh@vtIrN^0;5Dq)}_WV(J^Jqt`Tz`(f+L_GV)%0^pI>y*^jWaN<0G!jX}Mr z`PwwXCm(v#&_iE-X0B{wUBp~V7QyJRK%Aobg=y|3iXK+rTL4t#EE{d(wNKW_@5lGP zmC26_E_LbC3-^Rf@PjfY&RoKm>(*p4jv#FtBbmQ_7xa>Npj24qi=V0@P)V3(kn**3=?uL(U_XTK_r>(%c2 zE-DZNpk?8=_8&_gi|zfcE6SAH)B9IUvNKxlKYt$n!bhhRs_~-l2TLIx-kF<+<@qyH zF}XU?{Gn19S1g8EVwCr*nQd(jDI*e3rTZ@nx>gmCeE#!Y_~$}ODm_7G=>iID>goIc zg6~kF|3Tkf*OhZ(LrgNCwR~M!>(p{a^I%hL0^(UtYpGop7_Gk~|2)y&%Lybxr(qo` zW~66t`#(#3F#xU?G{@ReFUO~1+w7W{B%xwh`4OZ(zkoUZ=^qlRaJ@}T+9qS;AFdIX zAeNY%FcXgf8#lk}n>cZ1vH0T!=$8CaLPVzZnh9f1qC%YUc@8QSY$8COBpFbZidGST zSQdoXW?=r#uS}AkfBDxFp(55`TvN#B3X`PeCGdLR2t@1oQp zqm9FJiQ76g6Yy*d$-u7n?T3(z;?b(zWuY!vUvu}u$(YoaG#+`QPw02F{}yzkaFH+-l@ z=|WREp?hhc`dIcLb^76=cQK)^QNk9%<z41%a$6)l|zQ(I20*ifr2Dyj8D_=mHDUoj*OL$1u-@-HMIWK&B zpz44~f&^5Lkp;d|)+upeYH!F!QYs;WY;IWGL$1o@F#4bu6>}%YUsTv|^6rC)*r1HU zOh^ik<*DnNR>A7T?uySS>cKA-@P2xJO|wc6#k2h2q!w zk9#6SbM;4FN}h~0bubE%tyU^rUVM+0d;rk6L@B&Lel(&MBy_v}+E7q%51GxR?0b!$#&ebAx z`;{>Rs&PRvEIVozX|fEL0sJ;cpWt#9T+t+<93j#08;GJ6~IuA+Ky$p1Nm9g#T0#=gnIA}}0L zu$9KIJKw9QsisjjL^%NmBxM&5uJ%M?>WL+2&SS+-IepS`uPOigVs+79WC^A*1Bj7Q z(q@SiUdwd+o)fYV_ig9B1U2_;CxM&zf}Z#u%197RqP6Zlmt zYRSsWd*T&*`pjCMs>{AM0hQZ2I@8l^+@;Fc7p64IP(Rt6s zb`W_Wf6m4I6*qUWhCv1w{H2>-jg%53CZ(9=g*eyeVNqFmfL;2P9@}0L;`ncVJK21u zLtfz>CYnmAWuUgs%%+{$^^e;N{WQu`H##=+9zs?`BvwRxO|No4zH`dy4#^xd-ZF4~ z*lDA^w0SJ8E|qqcZq@z25L_1elFa>FXXs`wiWW@OtK1n@@%S>bz&mt`!f>jPMya7k ziHFDx&%G^v`$a(qPNX8oP!^_F=r10T$gCIPVg+0!15$F4%XiBklJrEFo#AB;!J)5psE0j%aHYBL z_IuQi*C-l#ZSh=N)k+Arg%fftDQ%t0DOKvgS(}U1k0KY@0f{SLXEXMjbp@6_<3(?L zf+QYbUo(P>t?k^SFuwa=q1UC=4J9oYl;4NwyKhj;l>M$x0OR)Iz!Gj;j4s}{r>CRp z;g-*4Q(xVZ+0~1*JH+_h?UR*xJtH(Fu#($firl_6sEO1UIRGd{DD4)C*wO;tsfB9Q=9QHlq1F4y5uZjS_f%}=>9#YtclMCDDHe0Nwp(;{C!0roiJb7*smnOVifL-iq~33y-4Utk z&o-n0)?v>OQzLI-W})O8860w6q9pnL2D%VjIa8oBN@}C*EG5;APFnMzCaq>;r#cL(xoLL6 zEx^GT*DQir#aW+&F2zqJO1nw|bQ^iNC!~R^TuW99m<7)vb z96v~HmMh1XJmPl+cH1g=6F zdrUVsk5UWd53}mMSCpC$(@>`kL<( zBs{@m?oIGQp`SfIbvB2FcKFh_g5HUI_2r$uA$IU2T+UOq9`mg%!pw|| zjE4L-*3?1EUn(JuddW*XBC8q~R@Pd!{?01mb06td9tMF);p<%^GOY^8ciSbK zZ~)z^Q4(?V&!?_iNVZ+oqHePeZo0Y8Om!4`rllrEw)6SU@`rr~As6_n)|T+xUG9-3MS3uh_E z^B)*8ti(_V(W23Km!C!INSsxri}n;9lA&Ke7%8)<@@wDrPAd@*IF=2A1@66k>MjW9 z7Vj*}pSKhJ-1=4)A6`9|#UU;Lww%5oFk|12XKR)lz+Lk_4YEpLoyWP^!k@6O#DD)- z@h+mV=8~4kG3(Ei=^8l|wVP9U3yu;h`}NT)h<0KM-M^1vUUCQ_PDe;0_Z+ZT_{$Gw zu9v%HxMWLK5ix&7i$DZ^MH^;)9>UGSq+@0`s%xn+c-(CyR@z{vWu2B}G%e>ex&1?n z03ntWe8_l8;ah}RC&m_lB4$Z6eiv~5ggKR@v6~%1NSopTArZ@OC@F`aVVjxlK#g|% z=F7!>8}z-0d?5DQp{^74cJZ91g$aASV#cV;wJ~GXo=TbEMRl`1n6OAW_uB-pc+2R? zi<5qhZy|&~hr(!m&g)X9VQ#(7V$l8w=$(oe{7qLQ&-!&ynYR_LzY7|nQ8eHTR> zYleGrzt&^Bc+@5M!0*<*>hcK>_E7J3&E+%^XvZdX~Pu|>I|l+_%l+Cr8%qJ z2QemfU_pPUL|KnU$GY6mgOcG|bxG>rj{zU>L)rL5rm1-mc}dK-{KsV?jm>U-U<}4U zXFXV&D>^ARyZ`FaOo|43_nb;ufGg{1;g*h@q`?qCB&cbvRbJ(BPG~LPI_22xTpN%V zs*}X73S_^U|EGv3azL~CMuoaod8i2XUg0J%>r=Zp`PU62yvN=pysqx{)6i1~I;U{& zspo@7FAx>G?J+!j9TV0on}t5BU%5C8Aca~c+D#!a1oRXiOtD`$gFjAf0n|-($Ut8q zJw?EPmkbY>n^XwOgD4~2I&2Tz48{8fP!f0^EOFTpxv+QgRJEdp_!+! zoxY+7HObSpqeuGlP!am^sL@bAPl;1OQb(tl-ly)z-qM5C-p7;3u%bRUZZEr}-S*Xl7H;aZX6iL)zlrRQHeOh*iqcA`GV3`a_O4qnfZK8psqKI;Nct@D^F>#Ld@ z%QBrjlqqgM4b_Wr+pIX^v;2fph@^MX< zalkCqt|4fOYl5fx6{Ryqo}heF@Km)3q{f&cm(iep;^3YP|fxqt(xSN>i-R$%adr1~#`$1%1 zgqW{eQOaEsJ`V$#%Ta#o3{R9;8?Z;7l(c&J?II@IW#ww~YQea99R3s^?q+p(k7K!< zRp^2{c_djG$o_ZH;6y}X%Iq@O%c)61tRw=g*VggX>x5F|ULZ=_wV8j$>m=|hNnWYG zMq07fHCQa&yUc1n*!-ZSDR+X~>0H0HcaoZ8xf`}|yqr-~uk79X*!}2nZ}J4!u;XFP zMuWJY9h!UBE&IiEnjD_RGt{42yo`yDS0wP3@Y*+?)*bGydl&IGr^};N9ua;Cu z#o3-O9B$1ejW&Eq&)~mcOkVsze?CjzetHto+P5T2GfwNIY$nstd#KiU&)eGUM-LUa z^wPSYJV{!d%DRiae*=L#PDZJf9hi+s zi!NAGzmIgQe&uG`_)+f#{RSX5`y-}O2EKti%oBW|Qgzcr=@5LkB&^B{{1_`W)8=It z;BUdwER72Cq!Jtm@MpSSVOCOaQ+$}XW~)$}{V~+N$+7C6niEU(1oojPXTnS{;aJji zx60oU%o_~akxrCg8`nnwbLgB%W8WT3aRE>$?0Y-)IpGRA+ zVy2WBA-GX5i5` zqKmNgu~1Nhj(@*YoR)}47}D@CxdMaKRA>=unN+Ht6v zU{lP5OU1BW1pw%%bAwwTVbR`auf5q7g1Hi00oD6a8`%RxB@Lar@?rUU(%X_mxmT#X zv|cG}oQ)=f%~y&3yFqU&><#}S$z&h6YA^Am{Up;4xTJBopO21I?oox_7I|Z`prQ%j9OTCxMUolQG z2f4;3CbHSO63uV@jwoKL{HgLdVXLW-Wp=!H%_4HrV%Putl^OJz|G(-xDigL~yvXMU zY@3xr{|&)6teE1b8_?ikTGZtbZ+*YH_J$&ty=AF)JWBz6yUd?r zUoSw}3hKT@xwvz4sr_LvG3BW_KU@tjuN8Q)Fb|tqUM7D4ElAKlS z+Fc`km%lA~9x`NBEtc0>;?OiZz0OWR7i+y_4k0aK(zJ$Vl~F=jihvq-oHD3ro!WJg z&+WDQ_B7kaSO!X)|Eh($^vHNQ-M}m*G1L`}1lx1I-ok z5~c}A0YVhQf|Z;%K{c#Jl3olv1Js$d7rYF{Z#Y?(8s-yO^~}x*+3RfrhSz9m@YSCVru}rvZKLVHiRw9ni%zm1C!K`SFjo=x(wG+`X4ol^ezYohYuDJ1nBY znTsFG-%vhy)qZr#zN=-kG5Vai$?hfWA?J6)qI33_{eQNTO{ew_Fqo((LT$(P9nsbo z(3=1MX93)&sV%SbyY4P2zst@F+9HQwdjf!rX`O-Tm=#ls!s#a?g9z%oXnm$7;G9hw zqVffc9(@t$4N|CX==Vq^3YAr9$d7%nCVej3amcC(e#Qp7e1b}XE%PATt`$<0$P$V| zZiKpAdX8Lmd=mzP$U-sE$0J-nPH{`?|10^|N~663&XZcRZF)qhbtqpfrmE4fC!{^< zvkT_q`Iwm$3h4)>eF2J_HxA>-sH!?@PF18~Q1Q$;=KGVk^QqEwg~2)^7B{9Fm*08q+>atTMge!7Ww8V+1*j-?EBos0aB0 zfp9o@RN%iM`i2(p+ECunI+F9d$fp|DOJUGE+f8Gp_s8SKtq~M_V`xpz6E0y&e5PXa z{q%vcOQ3XYFDIssL^mFm(Rz|3{B#(U%}#3Supu>VY1I$jueN{P%smM(a;v)i!c^MQi=1Ub|gfAGVvb z!OCHP){iW_rX=fQ+MR)x=Z?p?c-GorwKyJJ@wPrM03;5+x+Jd_jCZZnw6++aXzMY3;FY_48%7nOwDVNm(X4y8?Em)1IK@3-x;yl9N&-N zqxIe{SK0>JR_j=uCzVyP!wUSpKT8~_&*}UzoPfhsC~02ASD7F|h$|>bTtLNI zF`ayRBr0KD+7veRw2jnYO*0KtYVVG`yRvgO{4mr3=c}){ku7SHovUb7?$wH=#(pA~ z^hD^{qz#pnDvyr1Zg!8)Kzu+uqg2&lKoje9TRpDMEEL97!KoZ8vg|SO-Fzee8r7|d zea_1Qx5MO*1AhmN!+S$#rtnu4%;c~4E(*xNk(h*-RM62emjykXNT13O$rx80(pa!;G93M~!UKvuY8!Q=V~u#DWaB(^)4|pT2q(bt*-ke^;~uK6E66ENs3u zXNr(R+v+^A)RE;rKoz*$=%rQsJgz8YT#cF_AtHS+L;Uk9=5W7fMmsTjr%=tGM=b%@ zKq&uPp}yO)MFf(LW*#U~7ms-1{ihT<;O(4z4NQ$nbDlWBgsIR%BfDXbkI?%F1MLt8 zxYroBbs#WbD&uQy{_ImofJu>$7ism6i;V<*X6^;b7ritnb;?$hE*i7A1P&j@(m_55 z!`tmRDkZTp%1)P-MVVu zK3nI#(L}*cKU%3mgUyfAJR6Qg~Jec9JGEdT}|oKOOE}V``Wi`3<9daBlV7csz68UbtPV< zu+=;!e0%akP9%X~_4|CP6RlT6jFdc}1FnTL3KmIgX5az!rEl7#7$W1I3&;whU3hUq zae4_V-7JuSXJpi>^{P|~6CV&V;lAWh2~O40>V^C|{H(mXzja`<+#&_B8m2#3t_zHi zF#J(>JVmW~tL8>w42Ws2`Kl|qSPl!4ZQxU%wjH3+Sg|T;pEiTkO}!U%I^4M>@IXk|01<%1lL#-M2Cm7(`}wmBMLY^ zTXPJ^lh@^J+W!5&NdH^_-0+_W3p*qop~mxsFNlUEA3Sek?%EI}cXR6GePk4A2ddTM zq8mCsgJYT-HZL1ugiUCq8_PhgU*SGvE>`29)Tz&v-|>?l%PuqWCSvMSKEy5w;q%ct zn&sAbBinI?o?g8pZqVTid;SWIwgA}WuX>oC`Uh=6SD)^-&sCPjB9iXozsD%i9*5BM zCfU*NME)l4W!MVJ8(%1eq8HZ9|C73}dc2lA!mVSPgkK7{^bh23D_lvR^Q}zZ*R~AN z(SfFmIxVB{UYsgm!|^`AI*S9$X!u|58OIcjtI{b3&)91Uj@wLmvYwhLF3Sv#cz2>@ zedX(>Q1?EK43an%#5sm>H%*^4UDSRTe`I5m1Vy0F1t5)W{y(O!`LFK(edm_Bt=h@9 z?UqjNWZSmw7EiX_axE=x*>0K3Ha}gS`@WD-iGC>exR6^3XKYLM zy{|Xf7cq)JKhDfAPzp~XpdZ=fD2wE#$U%ESA+MC~cfR!7&{FB}7BvG6*G) zq}SudIiJ$vbqm_+VubN&aP$!xE)Un$K1xg-Cfb|&_+@b=%LB3kx%FO>9uN@x&GNU7 z;-9+4ZX-kk*Jd-11DYv(5i>Sq#ExCu3lTPu2zpul03@lKUAqx(|7jTK%D2$q-=0!V z-6+UODoEy=^S-yHj^|uLK(Am|53*!Twp zW6~%|K}Z*~rk}F|3lmx9qZ@fAEk(y-PoL!vblmi$CEat~PPoPMS%Jy6CjB|9P18cY z56tfSIq^C^@;7Q(MbcLtZq1i@9jip052pN^tF=1n{)oeNeCmOUln?<903tdGT^UEq zSp_v3AJY9-upLNd`LFRWlkP<5JO|$?xU*d*$di~rfLW!$yU%sI6G|+hX#aQx4cY{_ z*ZEH=%Cko896Hx;^ml!eT^93@A(a>)BIllHlDB#3_dMYZgj~;X!nc%T21fR;9Xq$Z zBwfpBQcUdh-9K*>W%LsGLyJ^+*mNpq;iVfHJASrwz$*X=9)GYne$6qobk(_?gdC>N zW+i(qs>nlsnKX?uKqC69wH>hp+;h&w$I1PA^V$hh?H~G?A&MkDF=+0l3PINL|Nr^s zAhctWlL|@Qy)yBSotiFKR+$V-ir7+1Cu%*_%oDdAd2Me63gZlxAohaeO8Zg!#dYL} z*p>`MLBpcS_9lgTFZtU~S&zFR3l*LsjO8(bf#3LEmK|u724lscdFlM-!qsavO;9Mm zv^kC=9Iv#6yaxDeKx;}lefOL5Id7;m8+EQ-8dw_O`aK7iH6?~dDnf(AC;$To0AD=GnwoI#LL=aWt)llcKa_IIPcxi_Hb_e`6Nu zog-eSKVNqWs`h&X4)Z^giQgwOo_8ZufRY$IuV4c~cp`&rr8a|?;)@R$0_b($9cNm; zkTCyIp;+f?He^C?pH-9f-WY~5Z6 zkJpBOiYxjW3o_P64J5j<2=_KKY^jaEzhDVmi#@cdS?E0@hFXgs)BoV{JzUi%Jb6g_M zm>k&5up*y*S&2l=bb|Qq*>wlaww8YJI{uFS*x>ujErozsO);4*RsYA~FWT^nEgws4a zIW288?6W>i1Uex$jLZ%y;!`Fp5i}*WEqX5L^d*?jsgy5u0tC(L%oBD*F$Se3yEm~m z6$FrAHS@_?qJ^fSzdHvX6^4NM{M&IIHW=iaQ^X69aakI`-eRJ&!ZdQm5pnDy1vw$G zS8=D&4mp7=BvaNFY9Hsp-RJpiB1D9r$l7=hvEwn~14YtbdLz(0TxMBgp~2A~_sf3p z1{NsBs#%5%pvj?I)(x-@5I34=wz`2AvSc-OAXI)v;AQ0};-862FBYP*lXjxV+)VnN zn)YpbpWt7>Nl7^|kWAclvi?&?Fd{sB1TsZN`Zq72%UcNIwPOZZJ=I{?3xm&Pn+{Xp z&tYTa@s2Ta%X^^Z~?`qwwM zVEIjNzbOuPb`Xbgu;GFv<=!I8yRPa4wAxK_PIOyl5UxK;OvR=jM`IAC z7WRQEDjkwnA8521t28CiW0R*a#}r50Rxv-wAknqyz8+Q8BKMlIySjZq&9IP`j*KCI zCq)J1+1S|R+#?|&i79ERsg(%j(}uaa$@TBKK+Z*H*uQhZ|Ixz@5iVln=`(Ta%vwir zTTS!x9Wfjybe^FCQE7f&_C9ecL zWP)Qj8X*3$LF%w5zOJYg2--P_x_$r??Bf!*7B5A&EO4JQZK&P~jAr78i~FRTT^{^Y zFpUn^Ihd84{ny41^x3>-oh&N>-WHrVgOrpMkhV76^71krU2iebB3?v*cAs#vvtK)qnK^8B;dVA=`v{RT3wpy{`-UOc7$T`#V?8yjKTD|yeffK0~wF+X)#t7 z%h*{fZzIq)+a>0(sd44PD6>kG@Ozruyd-83HWZw!+NBCaw2AdK2t#efepTBO-kDx~hbF%VMQF|Q5Zd|$qGN?1oa!l@67#kFuF7^m_307J;$!&Mo zmfM6D-SF@TNB*FyV=oI%bp*&kA}rXpF8Q122Owyl9Ok*USis8%{1+S5F#be4{X znc=Uh@kydXX`|Z)zL#M$1*W?8n+3(-Kn_~kVSJ5QBkdgh=ZvZ?5d-HQ_I%Y?!WMFJ zW3yc?4Y7D`>EQ&-*a@?`PM=W8#9{Fh6UC|+}v-NGUtc{{XA|$|y?tsWzZ3;_!TZwKP zrKD&B5zIM7l2@pBojSUyKgPcacNva@j`#;CZSs$ypTbQ&oC2?Lj3_L~n_>2$5^tMh zLE5^}I4v?Ibq(5uV!@`;GM%WCqXYZhEYhg7l%~Yk6}46&L}slqcsNWYAN36M7fiG? zHPgiwso&cO+m8MZMgmrN53J7&w9mA*9oLwv%lE2l6Tf&?v(Xg zVGh%KMA{JWt?Hs7K1Kg`$>2QfsN*s}tPMt`wb;-gaG*K zWdX+-$LV%pfjc-?`=bOB{j4x0ovhcAnnH13nC(@H@H8j=LFg`F!_V-5EWj7@xhv%a zv%t>IRJE>MR z>(4Nk!PT@we3>aC;PdL1c7>5|qh=cg#uYU+X+sx=z~9byAIv7XS_#GZ6qbz3wh&o` zr=+K_O93n2{?2f6PfV>&>UpeDLVOhymzFet^T+wXB|hJur=6VGHjm{bC6TwawJEG0 z$qTO5xj<~YhV`?h2V0AQKm4BEjqsqWoWfz(d!XY3!C@v5*1?62IIh%4F!9a@6+)V| z=&0Y+HU3mKK?ReSBHt%IjUYcBDR%c3FH%V8Xbf`)yar$sBn8)U%5YlcmP@pBKZcHV z{$<9-Btp0rWpa%hS@OK0MC1`^} z*%X&HX(Ds^GU^C>B1ItRMyrM4FskS;pdJ%)N@!KnZtzFX&V%a4U1|$T)bqPyQz$B` z4u8_FiyZs-a@(p^r%^^VQN%RQH-lp2Im04Gid$m5LBIFI~N++H%TK^M7Dy9)ul~>Bfy_Iw7Aq z{n{2LO525Bl+m4_IWQIL#s8U!Fg=*_{xuzyAhyK5N~Obew>jSXvDXG=X$^j-_1ofz zN2mXqI_j7x$gfr1-F}1oG3+BYWR}B=oQ?7m!jKhZV2GQEAcYwqfw0IqU{A}Z$&I@e^qFG}e6(6krtcAK#Hm&B&u7@BGJQ6uWQr8nUbr4FAg7W8IeekKvsA;3WF*b`-6`8@jROV^v`|^``wl` ziq~!i&1;|VnBG+aTAPt%ZK0o21DJG#y|t+P-akq62ciS=MMx!F`?+W`tG)JEvjdZ0 zl^#*7Or+cfoaT_*99hf<8CP4O`O=o5@)E=gP3Q+fN_ptAC$CodCY-$KMrvkLJYB>F zb6y)QzK`DH?)c%o?JX_(kmy6n%Bb8&9*oOO6FYZ4)69D#Wp1R1MOCoQ*oKhglggNS zn)mi~fBn&C$@;cmJgP6SZ6SGxtsYuTtjNB8?sFs((o7mB^J^`f1c-3&SxHOO)1ZhL zw+;(jXv`o?B>6Fr(az0q>*r!UBVr%bQQ5J(%m)fRYO^vK*g1@wUl1qgA2I_iy<1%9 z=1$xB)Odm8$?XB&KFe;8CnR8c3fmokMJ0Vzaa}&#%n%zdDy@OGTrx$;fUK)62iH80 z2*tLOO8H)^SYd_xR?sl#Q4=Z1){et&!|8`nX6iQ$iS8l|Fn0q-q14sZ-o%B zoDAjR$=k#bkv)yxy+qK4L5oUPcZGaSrhuIFmpF#3h~j}2$9!491x>-O^yI|Mj1tDq zzEgs4OjGKlEn(tJVxS>v)7Jga%-~sA&^6oYAQ2j!=(i``lR#k6APtF@4myr_rIfL1 zJ}j#NL*DaKg!ZKVo9sHr-2CXgtr7l1mD-igsOi&E z0SE_|VFg`X21n_00UBZr^o~*roULcnw{PKd^9GzNxiw#?kzx8rz9O2<@=uOd+zY`s zYJW;ER^9kaY$=d45;rtwrIOC0Q>PUHdcXX08XqA7qAhd3iGD0f|*+0KmrIXHGOhdSbqNK;;|d$NqEeXc2*e7$X_ z_alm7M}Z1hdQh@^zf>JCs!jPDD)AYb%nu58XPb{M14n+V1%S( zx-0#af;qzk|2yw?pW!ZJhMNwK>P zNB2ke@GBzPhsX8;wKqq}xNH`>W(-+2&qn{9o$pslqTf)zUaM(V{mr^$WnanEn2Ki2 zecB=qea%M#H#HO@OOt&ose51TLxm^+Bh%y#PeUGID&xv`L)}KY;x>#bsOfh1#~Po@ z0ouKwZxv&o%k^Wto926bS@F@7{V|kEOH~&Rd;Z3Y~M$C9J%62#77owW;$7L+$QCM8jWRM?Rxfmlnf4 zB}iZk8v}~J9cYa3!Dtiz(U&#(IhXpWa5Ai55)Sw_Vuqd6rbDHBWioihh5j+Hn2n55 zk4&WjGOhJ#DS&Y8UUq{<$PPTy40Tf(Uq@uLeTikZQR>1Sj8)hA9H(T3SB~w@@ua2v zw5=iAIOO85e&Bs4p%piR6E=+uu*G--=w9ZP%_o1}VK@yYKK z(~~&j#vxgIA5>^$VwY3xzpvkRbNX7xiO-O=;jIiB$boD8D#Ui<!k=H(E5?zI!Mi z-&?N1zNofoc|W;ACFQWK7Qlo;z4IxM#KW+V`sgON}@OG-~w((PJi%N6!j_mlrwuXFl>OK z=lho-&;1jLO~AsNH@-?0HcRfu`-4kR+2J?(m1O7g;I7ke&OF!Rq;XJ*9OoeooRzcI zBgIhsjVPn&Uo|kx<|%#;&jHCP1n59P^2m%lCw!ENo{D!Kdt?2pc<6ZOH*|=6@X6{@ zg5D&84au6uE_4FK_;Y65SjZs?35@W-|@)cM6QYA7Mj_GlC@pC zgoF3g^wN(n1O!l)FFAaUs5@*_qLlGVMMd%=&oiZ0H^IcX-RFdVHn2#r!O~pA-sOU7 zo2$0RO_>DQ>NtTewI*hK3ROtoP*tc#P$N&C7cFEAd8Y9Hy?73mCC0sgaRp`!z<;S% zCBQIbP9s_7rA`1TRz7)#@R-v2&bES{**Rewb5=N8%|yz}>vAmkO_@|hrgj^Okp@s= zZcJam>>67U(z!MM*YxSOn*_nl_vbR%mil)l9tl;c@QgBdbfty|2rMwNKc2OBx8k57 zS&sAx2~(q1pHWfZGIZ6kAB_#-Lz)svl2od*?*DAZF#4$+VTycas!NA-LnwZc?+&;>fxGJwHCT zeKuc2#<^8ptXXyAHda@i)%qX?2?BvANW&yYy^%NzpWaDZURATMxVWb}Wv7Y2S`ABN z#=f!yC=O+Hsf~3~MI4bIIFDRR2#TO36P_=4s#F?Gs#QxgJW(nCc+y(3Q{_CTD40du zALP&*GyzTNok&E&Hzwug`)s;Eltt}V9{z2B|1f$5ib==FxLj?fERXE(i&GS?gC1kq z`=k$;%go+~%*BF-MUyu$DjLUTH^HdEVz~?|dK@acr6yYF@EhZ-+g^m(+Lr*Z%Gqnk zlVKxf5z6e;?TGtn!W`1f}~jPkIz@WZb*SV4ifYw>N)hT?_Flh9=oN;&QWi_cRl5=4Jx?QYSGNld zKBfiDV}fYC^3(#eQnU|yhkWY3V_>kLO^fMx_IHF&XB1`7=C_WxA9sv+Sa^7PkW&1D zq!>WfD)kN>ztD)I_UvR~fK&Y?{c8rkH2sQNk$S6Nv$NbeBIbY^btYOWAUGVoEVGk7 zn>mE`xYQ}PKfS)+%gdFdc9k`*AO_(o*u(G7-S0`qwcYwT&SFJ#u3xzAlOg6j20_4Q zMDBCM(dCi$_0RwoQdG<+ca*z1RdrdUvHsJLoT1VuDoCtg!q1>(TX)xvg-IN-$6}48 zjJnZw4S9^MIuqrvNXueG@!-%NU3+aP;uzI@r@%+)KbQB^&_`H%rj(K|SoznPIoEBb zneP?&(yn(QgoFuGwIRqk`X8ap0AZ4dClAn3xnlx_!(dNgG7Hp`xYqQv!0L1n$F8A4t3_eGe2QG zAuXUU8)RNyrn=1>EDpCkC5jbHtj z>Rj=o`0mRJI~vkA(<9a^Dq4wu!Yq2HTb%C%N{ImL{=$lAwfGeI`VO{X3p>>m$K;Tr zrR;%p^uy7(c!obgCAM4=RMJtfIz$)8Wtj&_Dp)!KRCSC9e_D>x(Jr?Tda)kn}V2uHtwazh~LLUZCB~iU5VTOr_tZiBI!gFt1yRDplCDR8)$3wv%a9 zOy6D}8=UuKI8zVz>`VWG-3j9o0jLwSQFA2NB;tAMDsZ&BU1Vd3EXPC|qt=?UJX*j!mPhmx=NxZ2j>y^|m z&YUY3u3(|qZz&?Q;6pt4MR5=@k71!JIKe`Ah9qJ|v&Pd8-48tueWcPdyacZ?`t~tz zv|;c(rK!S&!s|vAY83Ah169p0;)n*Vg9Dzdc6qoey&hAup%{uBvTL zPs7dvd?Oi4Q1Zr+P^=2RcZJJHHtf2Yk#)YE*WiCeV$i78Bqf)OQ8JJCF!qGODr3j{YgebopcwwoP3>Xc$Brc@g3yv5MTiRMN^dN7;O;9~+U0ir0ftUcOXvG1 z%M%q@CvPb7KHHEcb`Bve$+2!YSrie1+@k2;U*jRI6tm`l z{V!|Lwk>KdgoWy+Xz)U4!tS#eMUoAX3%Qx^iqg#S8*z7fWAw4yL>d@ z;lk)I)43&HcA3JS*WVoKURn><=fLl32xPww^&@D0q+w=A z6O$nur862Mgp`+q!%aYPXfpD71OOGg6cOD*2JydtgNVq7kQ^ty$}{_C8wK+Kwn7>v z&;X44{YkZu?V94tUx#OS1YXIqqQ}b61WY5YYZhZ^+03KL5+e7@mk_Z!U${g{KuV5I zCPBRuiSBRZTnN0<6zae7B%MeWzbK#109w7u^_!wiCcp1yq8^SaAs!Z zNKsI0m%iJ)+DHopY}-vvT3T6gqJiISitR?19;3&s`yMQY00|Zr7INfKlfH^5t~j)5 zr)1^alZo74AFFbkWMk=83?hb9W7|3;4CG{rY;|@<>i)eZf&)xG^+Zi>hw41;%RkA# z9SvEW@=Zjdg2F8vpN)pw8%PWoOBmntvMA1j^M)RoYf@UXl{Y_9v1or+OIlB?-ZAW7 zE3d#YuZ)HN6>swCB|%yAb3oir?m0vgyxy|o+#GV+%(AoXz|?kE4pPlP5kG8Kjh5F; z^heQK^l^TVl*?b=;|$Z;W3LAk+SZczQtULl>?`4w`u#9PWLZ)P4^`WgxH3N(BVLE8 z4j=vj^88e_un7QpoE5f-9|A-YB4MlN7Mq8-=@(?p)f*_#fY6?zni_0Q<4vFQ+G4)v z{B*d`kGOob8K#tn%W?l>b);A}tKs8)y7*TkS@47G{ZaKpKN_fK)*5-F_`$JRoJXMw zKR1oi2#e=C!VbHdBrg{+K>h7{!Z)8429Mgdqe7YDM!gtRr#PLD~&AOh9 za4nW`=72}py}XnZ%730jyAUI;v~$06AG#Q;3i`X3>&eknMxEW7jx&&J`h-x_RYqC3 z?NXiSY4p#-(yX~CvN`_e`|fu}Qc_ZIZZ4BWj$0~&c9XOq`+IRQg&P-}$NbsK4@LXV zOUcJGkM85KET^YF_{|t2OAl%KKQx+-$zR?0Jx*YAjoZR2BGqkQt7_=ZKOOIk=2jHR zojCltB%IRv9MRpb={G|s=L7J#%&~&_YQ-hT`OMgtnRQdgZyWYJt=0Y*IuL|sGh0=X zM8M)6Ga>!ibNB>V0mGDPgSS)uq>VZ=txD{ewvJzb;b56!qUE0$x}YH=YSkPX0S^>d zpN>@K#U>z{K_@FXf&(B8*28q45%>}>^qbo881iiT{X=! zyMz=zT`wX>MttQT3&ok#o?*1OOumYUgGzUETQEz*d3Fj5rN;0VdPeoi(bQ5JE>A7Y z`gNFP*49%Z@koFwlL=92t0WoJxo7DQo$<=+`eX#!R6H(jzVUE=t0|R)uRNlr=H??` zF$9Yzi1x8_5DGgy&ea32_Ol#PpPsxQAueylZ=QUSrHv+o=*{>>5E9xMB1^EIk2&!oy+4?sH&!hq)2>dGib8V zrQfYmi4h7EWQ6I*lB8t_BEFj2vI;Ag3hSC0;_SjSQU$J{Q4Td2Xf%2%0G8Zb!h2;Yr4iLMn||NgOkvF?0IjI66_NV5{38bmj9 z(YQ^H`|fp)fu&)p8TqRZeXHH>5sZr;T&pl8mj0tXE-_4HNl!0Z=k;L*V>UlWS=$8x;BOi)4$;RUyT)|EWzj|PEk7i%Z4~quLCo? z-3gN&{&ZDqxV)oAE{kK%sN#Ej|DOuc&sG}UFX^`4uSmSt0dKThNQWegl?qo67YpoW zZzjY;Q(6{=N;Y{td=%C&Ie-r+C@yClZrgeoye4{UhNn)KfjKb3UY`K!Y=TQ_(~-fW%fEX ztg!l@YH2F*SDPJ3{dZYNoBAg7Y$v37t>&aTk;(-*w4V<6hD0a|Qafog9g%i=#GgIUQc@c3 zn7{45bk{~;-LNhx89LF~Yqn%R&wXxq=sl+N8xa^pzwrMh!AwKfo6j$`&K{$2I%gVh z5j+(^?5`>GxQhc%(;Rv+t0=4{HO?wD%f-P_zISF*`%}H^{q>xl)>u?D2+V|?KzC6T z)zRkcl?|5aAeVnTbhcuVEt*M=K6-#lhbzq4Gb&rdxo6zeuvf@Lm5&Py1qU83IXgLT zc+Glwuh1V0u$cg0?c^`guj}?)#NDL?H0Rpb1+hoV$qma`J{-Z!rL?FsuZl0gvn}TC zK@r%aJh@7jckjj$GVzi(l;93hoGtq(EjTRGTLD?YsflEXtcjX_V!9vDJk2@v4DNe# z&0-4dA#vuy?!R`buxvOl#715EaKa7D>(>=ZS!~E%(fqBc86PUV5sOOQCSRG`eza&` zU;H+NjYm&JsT?M0oJCP|abcf1u_6Q1=m0C1Ge;UP()`$y&0oEA{oP+c9>%vDHH+OM zZsup_ex^-msZ#6eYu@{dRCy9misgsRB2)8;oZje<4SyYI(Oi( zQ6zhFHgT5tGbCLOG!DAO)(Y1goD=M4c9)vPS6Lmm)^Ok{2q=LEXDFMggKV}Iy8s3+ZV~5_OtBjML}fn3Gd}*dTV<$Xjsot@Sv}T$f;7s z1@7bZR4icX-1=au!1=HwZRBXa%Is{lP3&-&&||frhpch-l19E*$kf@n!S^r!M&hEr zk9^Q@KFPtDd#@9ipJ*{<_|o%$NRgn$<8~1~-&x=WQJ0|8IXAtJt9T``jPK8eixi3M zVB_qp|IIyPS}%rTkRv z8lQx2qu4BS-^Y!$uCJ0n7xVmVTbUAI&K(8_*}~MDI33NPc+=y!4-UJP_7p2_{bYm>085jA-g^v}pY!6O`E(pjSKlFPU9d!sRq?&A+R*!t&aB$UEirwLkirNx#b2gSFaSE5>pKb>1!_golLR9~FIE88i?o^w#G5e9zkcCO3ioi;Hf_ z;-xn|ryehq2Ny5Xe+cS6cj$NU@wS&9CtBEaong(urdVpM=OGxc9{e6R`8yWC|s#=vfL;&Gc%J- zteo7AXq*!2b@i2wlJYk&x zY6rZ4=K3~gK;?JW@36xmxDXaT?`2zTlOs62c=-WW=YsP*A~to{DheFhojJnCn-HL+ z{{2rhEQ2p4B4{);8IB>tTzoF`MYz>Tn`nu z!`!Jb;lFF9_3&big#0a$yEd1Oc-;4#q8Pt6wXmoHic$7pxG~-q_vie%-XB*Hy*ZW^tGNCv{!|zk>Z4g4F3YG&ICncB3vj;l&%Cl?lIA{8I$Jy*{T9F+)@J zdxFPvJl1JzyPhgxN+BA-t09`1Vt&WXz!(58=VB^-!h zdMX6v(h=-}Si917L$m>M_N`k8UXU(*4&le5L4e+E3B+ts6nI5DUiRk$cZcBh7&{%~ z3itKHxPyODAhn=dhHB`}OF>BlbJv5|p+r(B!nPi11X+c@)WQ^|AN!jaIRoL+vP;=e z`6>g{K1i$6w50mgJSjOPnLf%-gk%8U_HpsNlHMzW=imK-jfW+oOrEH8PVR-8T@57m z1wX-u0%s18z-;!xG2I7Lv`ZH$oqngN!veR+yr*x%WCFO;m}!T)0FO`%;ZvWHG}(xn zIM@uC-wcyIo%)UpZ>*^ab{ zMo+{qn~317tg3BgscVOT=PbuX9uE(f3O!lNbpMqWy9x3$4nYfqee+Gnz}MAj{Uyl> zfonN@VgF8R7n_A@wh*FDA#KKScAxCXxeye>?GK zDSyJNFtf1b+JgMOXxJQBnQiHOesq>D9??Nw0A&_M5CKWVd%bCc_cl{NKWnD<6 zw7FZlllbYD3yDoj^37^6DwBV*k(9Dz_Qtif4V?r%zv_Ao=Yt>QgD51a+WNpb+Y+C5 zUdQ>q-Y#BkhG2|*ap)|Nlll2iUXzkiB0{u+y}|$u5Iwlq>i<}`i_LMGclA{w=t~Ua z89+FDduQh($sRP+KL*Cy<)*BNH9+R&0}b%+n#YD(Amju^w&y8rPc%42WyKvL@!U4X z$@T!7v0()7cqQFT1|b$t>RPxZzjkE{T^DZl})686iZ zs7JU+T}?F{e;4=2#NLbct;bK>)(KQ1q0mCR$_;i+>8JFrh^YT2s1A~|&R5~2e_oVyO(_vY4!3%PA|+7SSi%!LIIw%J1QyiG4t zlPLHK_(}0U{}Krtn)PUEjKIPJanGJ{=n*j7?|yJ@mX{f*pS^)F&-WVWnjvASnb$jE zaZukt!ZK*IRy$S-y5RjmtRS-9T?nt00+)T7yMSal5d9RH!XhvET%sGkFWLBf)}a_A zG-ImcY^Mkps!Kpk2qQ)W)8qaCogZ0D!KsT+L=10kHlw5{fO?vp|bV}j;KAG z!MG0vSi6CnEN3c-)S>A_5%%O3%8ap`&=a+*!&)*+4XgE>rrwV>0#_>fZH@WmW1{hjggL2BH{Sh4B;-cB4OKB| z`D!g9DBDhw4VxRn-qYyJR?^udc6T0x+*=a@Ccq)JO3)q{7({ksjGb$sUXLuW;@Knw z@HoT$NQr`)6kgImuhwNcU*k|5(Djece%(FB7Pf`-Lnygm*`q~{d1%|7u54lilz0m- z{^F$Dh$_?P6~)o8TDz2Aox0hPJHf=PTwaAn^qFmL{m_D2tw=|XZ1b1#)P5HElQ{B< zZ+f)f;!J8_gJ2gx2$X)w44@gQsMfdqEuh@$W?@=(n@v`hrR7m{oD&j&HmXQG$@>! z`B#HV7t6m$n~CU@^{czr4?FQyD&^%UPY_jDIpIEBhEE-9oLO=4fWpeKxH#1?Re*G|ytbN0yDZ0FL$}vDI9IUO959CZyH~`Us5liK5!vjzbPcr8 zt`cqpNj&ipeZGJVfo5b)Za#S_!SsKiX^{VLkoz8I+O`T(mO;{V2Kg?S+hcev??rp2 zbPU`RDP8h)S$8AaF*k6B{x;%Ufnpm`5iEAA(_HUX;0`e=t+*>fpk*UW9Ea`1xX^^~ zQZ@So1XcToILg}v7aRi4HcQD{H_e%YS&mr#VVyEC(j*dkMn`ZBa9|#53UkO>YUkBe+j`gsM)*hw8xwo%h^3U$j_?2Pl+NsvH>$4I^ldto8c7n;R{#cPBzSl+f46(Xyt`p4;8Pr zzcE*`piOxOe=Mo`dB~t7eeH-h%bJRafCzNA4*$q1%H{6?N#B(yI);H(9(+Xu(+-Vy8jM{)l_e@s0!T~?92+*qexj6%M zIK@%#tT%g7KyorvqwWsi=2}7eYhq7iC>*W@T@SC2Px0r-Jz7I$FWbQ7=G{E(w49=Y zmJlTyYEq7*b|qV!-~YZMiDTdnO#DO9DKJ?4Xc1e)$x18hZ^0Wg_cmq|7KPyJ&8)Qr zw;LU?&xwa-F1ni4hnLnZv)NL4>oONeonky)DxWof#qAO0g1Yly7DSA7#4$6M;JN^eRt}}O9BCVdr4hap;!A!gY^P&x(fW*<;^La#9adUqbUq&@~+Qy-D2>*;#rwHlK}MM-!ESPaEO2Vfuyz{(&ttG5X8xStjA zx6U{E)}3I-l;Fhy)NQ4VpC!<+A&Hdvx?U6t>a!_OTvRoO9f8OoU^8J$>7LT@;&*y)V+pll zF2i}}GZEL1P6WXrloTyON+g)gU179e+J>X43-GOTa)UzB!bGzp^l5&#GY&ZB%(+)>ZF}Nss?(LAM^>0 z8>Lq17FGmYRp*b{{3fvdT00txhih)T2P66DZ@xpeu+UJtp7O{35<5hMkm-B2w&Prb zAqV2O0Ay+F^}5bvI5zoOG_|3~Div4lMK%%^rH1elS#S4t)l}ltm!A>4*UXDRHYhV~ z^M+s417EF&bKW<<>=P|K9(YM5p3D;m50{2ZE_ZaRa&5Or&s_pRq^+Now_Mr$~%Jb@TR9#JF`Ugj`GbG{S8g_U z<`A*R)B`TbHO;^q3o5tyN)#z~cDYbRrZU?^U>irYaxMP;^b#Q2%Cn=TFC{k>9U4Lv zl5_ZIIQovLp@%TF?1UdrgJZ?}2n#~jek)%$$n_TktIVXsiWG+oqOZfjKbaJ?33f%# zp$Jbn5uI=F9bp}*)+=M<5L33f$%8!0rQQ2(rs$*@BYI2Cti2m3o5e3v=D}Y>C-UseAJgFx zKajE(#?Gy7PTfJ`kJZ)Bo5U0=C?4)Bi}(ik&*flb?_+9W&mObG384}G9f9K`j2^kE zcK1c}i`0;+c}q3CseO&CXbLti9Uv5c(W1&00WKH6diP5~djhL#WU(1q&|Cuu{e(WD zWONZ|>ltY(Vx5tY9Edab@}z1F)YXr?(g%O0PMerKrd_x})nm&U#e(4X- zo3i2YOp)gAdd?|@t)=kcgC-pte2zfu{hU#57)bK#&SiTh3Be@+Sn%#@J-+d$V>w2y$rZSoN zvH#a!+5DWYIDTd&Gb4vVk&rIwyG>>RqaABf_lZiZYP*e%`leoh#nGjBW6tDL?(OVW zXIW#!CB(jnJNf;v6R$L~wgNNNRRg!^8FTl2d-b!FY|ImVD>%rlyJ3t@xxF z`ei3AURZ?kQ)`C!knF>Dg#=Z2+0el+%Uh-=@6MS=m-Q*oXnDGHRCv(M)>568suD$q zJ2BWT>rUF-IvcfMj*Si`unnU)m4-b2)UuC9u}l?-XZ`qdq3_S<2x2wekCuUS(zwyq z4gu?W&MNJ1eUQNkP|$A@1KRa=ne`4Q`?6bn_d7Ss0!;)FIS;gyzn(5C6UkNnOgcg@ z9ogxxfk!cR0O_0xn!QFwpj)QRhWMt4bjkk7E*x!G1(-XK$*)?ivx_!ixOtE_frIjE zp`pvi4YB?HEuPl#wlw0D={hMMVP5r#6DgcaC)GupB#s?I9&S_5Y5u8AkSt?`OJ*v( z-%^ZfMIY!|RGRVqbzU+G4K0|-x`D#@1PvAX*Vh2s-iJ|Mso4YC{gvx{+}5(|<2!Gj zu9?eUXF`oyQYYK0QznT5$9V;E>uk$oj?UCJueks(s$ z^sdcUWpsc4gfX>GfaDpyFO+Vpz{u?fR6e?fy+ofU2{zX|50dYjWT*fso~eRu7emVq zWs{Hld&0ZGqWYY}J%@_t=rZb#vmzeISl~vcZXD-?W4;Oc!P|baw%94%$C+VV20snL zn$(bIl)X_0E*VoL5?96~l4iNSC_%^r?!;R}y7(?|@J$Sd5Mxr+>&c1nyh2pF1j2hl%Mj+Y&)D%w8v^C+2V`yO5FJGX*{QZP{G# z?1sV!D{N{}LHajH_Jrh53`ddpdbr3rNM{<4n%3#G1!gBh0gZyB8J*%DQvJZ;INoe* zAd=>o;4YH1e%2p6xOtp8L^Oq@RuC{A3f&c%1~TZ=7p~nI=!Ovf*x%~lDoJ(b7KpfR zEN*FYnOHevJpBH|F3rhJduVEVCk@Qw(-1SpW~{fga1}`4UjNs5{f8N)!FtCPtW)%o zxt*y1r1;ePqoqat3tlYdKOuz-mqTW(fighw<`fipGoV$zZ*J@x&;N?L@^C2IE>5OM zc4f;R*_Ti>!y8#=#!d!Vvx~AX*;SN%86z=KM6y&PYxaGN5JR>I!x(GUtofd)x9^>E zU2{Eu%r)2Z+~?fqIrsVf&N%}c2MXt4Of=Af!zQ+2quVbzh6g7J;TDrd7Se8qt$FVA zEh?K!8S+lcvG3H0a;jsmCVy>Q-2Az&hicm&7}ntK1hnxRUnYO^P}4|Wt?`&OO5Quy zR#-dZ5Yr>(TLhC%3Y8QG#stC}Q!A%EP?$klCmE!+ijQW3Z$g&Kr1!`kCj<8lYH)_( zL34Nk->;;>S49YkYjfWTS5ETykoF%J#8xdM{QR z$kfn%lcwg4L>arhMQ-A_PWEjwP)82>)p{uDC5siYdbXkZkG!{qj&31_VfNvvp%u<0 zk5pA8R8)-8On_u&LREU1u=go=uT4&C0vTM|W8?loCpw0u5V{+8uHeq}H5~>@u2rqQ zP)Y3T2(LHi?^!+8_XyjmT~1$l4|=@=6lP)^vU9f6sV_Y9h$*`QKH-nxyte)cLqccT z{lwh7`N|5!jy{NM@x!91(da&YyX@juGpg0z&6n~_`I$rr$n~*7VF)r`rgq5TC5>E^ znEiMQVo8Gbb#1wtXRq7*8n@Eg`J(;2=dDzzD8Id0szPxLkPwmmR~93wxXxF>rNV>- zgn83&LB+-8CdRnodU~T&SlNW)l`A7U(0i|*3!KKu_I64OEb+OzifqCKiQGsy7 zsx`1E^u0?~*4bjGn;$`E4#e$>KQp$_Rrm+gg)#VHv-wRSA&ukjN)UR)iGf9To69d| zR0Dm0#lmOpod(76^)CewpIn?cOc~Fcljb_+NZf7dl%&WDJ)jKUm{fp5_67G2bbh5F z?C?igoFOyxX3F#Nd_WoTU#W|t;>xQ8)=NlQ%xu=4zoDwoCXV4e?ztYMgMG_X%d+0k zos;*1;Ew-ijKivp8_h$sqhgUc6UAn-gx9z~i1u5D3;4ynK384Ni`gsX3=UR2xxWBj z9Z;PIFs7ICapjOPBR5EjIOdDVCI<_v)Ye+K>17+AbW?WXL(A;mBkVijYY=TIMTM{G zfkS#ltD?7AodGBEM+Po1j8Z;BS)OUzwl=$0S3oR)Yr560#9HGbWNu4*FnXDW&Jesx zPml4z3DgoEjb6gMf7lE(8Q}K&BC0l8z{SQ^IO}FNhQ|{?;gpn=eIZ(RxKU5-(l&Hr z`%_a>wIlItmL@H^Nz1W%T40rTy35IlEKx>x8L8!V=t;ba%EP`3;ZM-Soj#IfO>oidzy1F6cXAfMaL5P}> z7ugoe2nU&d8XOv$@0IUIZp?K_MD8u-C&R+R8cqf1Dux~SU0?k;gqPnEVhSUo0|_{p zCS+V3ZH9JeXuU2Pd~2aUS7v5rW^<#9uS5x`D5rhY+1c5%Pt28Zb8|B`Hy0(Rz9;>L z^jf{>{Q}pgqzqJckVi|1rc(otVb6gIPL=Mc0M0N*=bM8M{6lx($t`U2HpAW*@7{hC zL02l?otYtXWF{5A3=BZklq1mp->zi&j6A1Vrj6Xk@B`uk0&3}Hz(TH5yyoA76DpvwjsZW3j^ zteb+c3D&&kIW7cP3j043nV&eH;%1|w)Y#0OUrY9u4wCulYYVFHC}1v-Gw%ttZg7%aDn{3xWxM=#KonlgzVB}R)|>>j1`VejEzl|qp`EIcK{X%f(06l zPe`E4crn<8!N`fp$YjE}SvC)VvEIsJ`=u>Qx#L0kZ-A^@R3lIyL;*8PM5jnhvNlD; z*VpskrX7*#>dYCMS-y0L2)zuMKCH0XTXL>c=wm&%&CWf<>bR|rqkGIp1uogK z)%#;i3V%IUID?_!>}*YXwz1Z|n3qraqN@SyggHC-rsEjK$z7ff7}V=IhS9VMnmLXA z{P|XYLfanlPFf!TF_xkF&ce>}7BgZ)mdxB6y5GJPxA^FqI_dw_+PzEZHG13#!^z4z z2TDPP8pC>)nIgwjN7Do1%=`s?uW~OsGi-C^Io4i%Lua6q_JwF|kA6ZGVe2ufHZ8Xh zUAI5a_ zI2ypFDTowN+(bFc;tf3LiUymjImfIvS;lp#v3xQY3L_MRM{`Bem^~Kxg<$Dzvfw zd`hOp&nk2K@Q@g)1_n_J`hZhKg0#68-YeMZt8B&5-})Ort`R7Rve9bNkfFZ0gPmok z)$z(6(d+a{L*WHeDe7*5dZ&yc()2$^B(=JNLAjGT6~OGBv8IToags{lnpN#;)dbQp z{Y%r~w{`J6YzV#1jtcIkyoLfszgQ@-lsG?+1yYLTLYZ{c3l@d4z_A8cD3M5v%iB9| z$S0LQvduuPz(Meztnpszx9&so0wqgBoQ~AUZM>hW^J0!~pLeHk1Lu`HkA`rp^lLOt z0Dg_$2+D6RprYVow&Ml7br#hb!vJ}8`s;rmtEGjKeuZXyuZZW^pX0bj(lb+hDd?bw zOqOvj$|p^bmbSs=67(StLaco6D-E!6%SK{EYTRA_-V_}dgWs7+@Tv6YQ1q7{AR+$; zHjsS#9k6iBC#{mx=Y?yHM+n+P$!^W*%%ZKlMG5 z64}t=lpg!9A*ePHBlYw!(<2?Kngn#SSjpri$hL`-8|pujXh6w)ZQx1HI#T zs;yAb`YVG(o-((*j8>IAg)+~)1{agxY-#d2U~ZP;vc{}z!OqWWww+L(SRZco+J9h# zSXR>F(Q)W&W`u{NBC!0ouYU(2b0OVTm9X1)S-}P+9|tzoTxvHQV%ZqM@n88`Ati8^ zndz#efP>u-L>)r0C1p6q&$l>-A{(XmCOxvCx>mZ0{k}v^CaOqrp9DhsE<6bZ5(Ucp-v@#^vg~YK z-aIh7;Sp{&=kaq6EfT>~QsKp8V4E!b>qGnScGKrd#VyEGebQAR6V4Y{FP#vL{<0=n zU$Ty8GAtW>YaLsleZl4pQU5*barBwh&t z?NEry;jwqxvJa-5FwfPsQ;W;0)mV`ROFJe9nFjx`R+r5}U68o&p@ML%HHvhMY`ZeL zwlY8X#g99LV`$Ok@Yc|v+ja%S5}bhO{OY~Z|D2)CE2p}>ek!<&`RwlHvc63p_It4jM+BB83JV*A zpn=*=i*JKM;cG0MH~uv?@>#HrlAkTQyM2@b+Ew}4A5!vM<(rp!*U(Jp$j{xyaoeuy zSkfN2cV~?EYj}SUnErS}_eb<;9k*r!`DC`DSRl6h)*f}j7}wLdKa5!TP62$Nn)({$ IH|?VT2gj$>lmGw# literal 0 HcmV?d00001 diff --git a/gnu/llvm/clang/docs/ClangTransformerTutorial.rst b/gnu/llvm/clang/docs/ClangTransformerTutorial.rst new file mode 100644 index 00000000000..33931ad201a --- /dev/null +++ b/gnu/llvm/clang/docs/ClangTransformerTutorial.rst @@ -0,0 +1,400 @@ +========================== +Clang Transformer Tutorial +========================== + +A tutorial on how to write a source-to-source translation tool using Clang Transformer. + +.. contents:: + :local: + +What is Clang Transformer? +-------------------------- + +Clang Transformer is a framework for writing C++ diagnostics and program +transformations. It is built on the clang toolchain and the LibTooling library, +but aims to hide much of the complexity of clang's native, low-level libraries. + +The core abstraction of Transformer is the *rewrite rule*, which specifies how +to change a given program pattern into a new form. Here are some examples of +tasks you can achieve with Transformer: + +* warn against using the name ``MkX`` for a declared function, +* change ``MkX`` to ``MakeX``, where ``MkX`` is the name of a declared function, +* change ``s.size()`` to ``Size(s)``, where ``s`` is a ``string``, +* collapse ``e.child().m()`` to ``e.m()``, for any expression ``e`` and method named + ``m``. + +All of the examples have a common form: they identify a pattern that is the +target of the transformation, they specify an *edit* to the code identified by +the pattern, and their pattern and edit refer to common variables, like ``s``, +``e``, and ``m``, that range over code fragments. Our first and second examples also +specify constraints on the pattern that aren't apparent from the syntax alone, +like "``s`` is a ``string``." Even the first example ("warn ...") shares this form, +even though it doesn't change any of the code -- it's "edit" is simply a no-op. + +Transformer helps users succinctly specify rules of this sort and easily execute +them locally over a collection of files, apply them to selected portions of +a codebase, or even bundle them as a clang-tidy check for ongoing application. + +Who is Clang Transformer for? +----------------------------- + +Clang Transformer is for developers who want to write clang-tidy checks or write +tools to modify a large number of C++ files in (roughly) the same way. What +qualifies as "large" really depends on the nature of the change and your +patience for repetitive editing. In our experience, automated solutions become +worthwhile somewhere between 100 and 500 files. + +Getting Started +--------------- + +Patterns in Transformer are expressed with :doc:`clang's AST matchers `. +Matchers are a language of combinators for describing portions of a clang +Abstract Syntax Tree (AST). Since clang's AST includes complete type information +(within the limits of single `Translation Unit (TU)`_, +these patterns can even encode rich constraints on the type properties of AST +nodes. + +.. _`Translation Unit (TU)`: https://en.wikipedia.org/wiki/Translation_unit_\(programming\) + +We assume a familiarity with the clang AST and the corresponding AST matchers +for the purpose of this tutorial. Users who are unfamiliar with either are +encouraged to start with the recommended references in `Related Reading`_. + +Example: style-checking names +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Assume you have a style-guide rule which forbids functions from being named +"MkX" and you want to write a check that catches any violations of this rule. We +can express this a Transformer rewrite rule: + +.. code-block:: c++ + + makeRule(functionDecl(hasName("MkX").bind("fun"), + noopEdit(node("fun")), + cat("The name ``MkX`` is not allowed for functions; please rename")); + +``makeRule`` is our go-to function for generating rewrite rules. It takes three +arguments: the pattern, the edit, and (optionally) an explanatory note. In our +example, the pattern (``functionDecl(...)``) identifies the declaration of the +function ``MkX``. Since we're just diagnosing the problem, but not suggesting a +fix, our edit is an no-op. But, it contains an *anchor* for the diagnostic +message: ``node("fun")`` says to associate the message with the source range of +the AST node bound to "fun"; in this case, the ill-named function declaration. +Finally, we use ``cat`` to build a message that explains the change. Regarding the +name ``cat`` -- we'll discuss it in more detail below, but suffice it to say that +it can also take multiple arguments and concatenate their results. + +Note that the result of ``makeRule`` is a value of type +``clang::transformer::RewriteRule``, but most users don't need to care about the +details of this type. + +Example: renaming a function +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Now, let's extend this example to a *transformation*; specifically, the second +example above: + +.. code-block:: c++ + + makeRule(declRefExpr(to(functionDecl(hasName("MkX")))), + changeTo(cat("MakeX")), + cat("MkX has been renamed MakeX")); + +In this example, the pattern (``declRefExpr(...)``) identifies any *reference* to +the function ``MkX``, rather than the declaration itself, as in our previous +example. Our edit (``changeTo(...)``) says to *change* the code matched by the +pattern *to* the text "MakeX". Finally, we use ``cat`` again to build a message +that explains the change. + +Here are some example changes that this rule would make: + ++--------------------------+----------------------------+ +| Original | Result | ++==========================+============================+ +| ``X x = MkX(3);`` | ``X x = MakeX(3);`` | ++--------------------------+----------------------------+ +| ``CallFactory(MkX, 3);`` | ``CallFactory(MakeX, 3);`` | ++--------------------------+----------------------------+ +| ``auto f = MkX;`` | ``auto f = MakeX;`` | ++--------------------------+----------------------------+ + +Example: method to function +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Next, let's write a rule to replace a method call with a (free) function call, +applied to the original method call's target object. Specifically, "change +``s.size()`` to ``Size(s)``, where ``s`` is a ``string``." We start with a simpler +change that ignores the type of ``s``. That is, it will modify *any* method call +where the method is named "size": + +.. code-block:: c++ + + llvm::StringRef s = "str"; + makeRule( + cxxMemberCallExpr( + on(expr().bind(s)), + callee(cxxMethodDecl(hasName("size")))), + changeTo(cat("Size(", node(s), ")")), + cat("Method ``size`` is deprecated in favor of free function ``Size``")); + +We express the pattern with the given AST matcher, which binds the method call's +target to ``s`` [#f1]_. For the edit, we again use ``changeTo``, but this +time we construct the term from multiple parts, which we compose with ``cat``. The +second part of our term is ``node(s)``, which selects the source code +corresponding to the AST node ``s`` that was bound when a match was found in the +AST for our rule's pattern. ``node(s)`` constructs a ``RangeSelector``, which, when +used in ``cat``, indicates that the selected source should be inserted in the +output at that point. + +Now, we probably don't want to rewrite *all* invocations of "size" methods, just +those on ``std::string``\ s. We can achieve this change simply by refining our +matcher. The rest of the rule remains unchanged: + +.. code-block:: c++ + + llvm::StringRef s = "str"; + makeRule( + cxxMemberCallExpr( + on(expr(hasType(namedDecl(hasName("std::string")))) + .bind(s)), + callee(cxxMethodDecl(hasName("size")))), + changeTo(cat("Size(", node(s), ")")), + cat("Method ``size`` is deprecated in favor of free function ``Size``")); + +Example: rewriting method calls +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In this example, we delete an "intermediary" method call in a string of +invocations. This scenario can arise, for example, if you want to collapse a +substructure into its parent. + +.. code-block:: c++ + + llvm::StringRef e = "expr", m = "member"; + auto child_call = cxxMemberCallExpr(on(expr().bind(e)), + callee(cxxMethodDecl(hasName("child")))); + makeRule(cxxMemberCallExpr(on(child_call), callee(memberExpr().bind(m)), + changeTo(cat(e, ".", member(m), "()"))), + cat("``child`` accessor is being removed; call ", + member(m), " directly on parent")); + +This rule isn't quite what we want: it will rewrite ``my_object.child().foo()`` to +``my_object.foo()``, but it will also rewrite ``my_ptr->child().foo()`` to +``my_ptr.foo()``, which is not what we intend. We could fix this by restricting +the pattern with ``not(isArrow())`` in the definition of ``child_call``. Yet, we +*want* to rewrite calls through pointers. + +To capture this idiom, we provide the ``access`` combinator to intelligently +construct a field/method access. In our example, the member access is expressed +as: + +.. code-block:: c++ + + access(e, cat(member(m))) + +The first argument specifies the object being accessed and the second, a +description of the field/method name. In this case, we specify that the method +name should be copied from the source -- specifically, the source range of ``m``'s +member. To construct the method call, we would use this expression in ``cat``: + +.. code-block:: c++ + + cat(access(e, cat(member(m))), "()") + +Reference: ranges, stencils, edits, rules +----------------------------------------- + +The above examples demonstrate just the basics of rewrite rules. Every element +we touched on has more available constructors: range selectors, stencils, edits +and rules. In this section, we'll briefly review each in turn, with references +to the source headers for up-to-date information. First, though, we clarify what +rewrite rules are actually rewriting. + +Rewriting ASTs to... Text? +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The astute reader may have noticed that we've been somewhat vague in our +explanation of what the rewrite rules are actually rewriting. We've referred to +"code", but code can be represented both as raw source text and as an abstract +syntax tree. So, which one is it? + +Ideally, we'd be rewriting the input AST to a new AST, but clang's AST is not +terribly amenable to this kind of transformation. So, we compromise: we express +our patterns and the names that they bind in terms of the AST, but our changes +in terms of source code text. We've designed Transformer's language to bridge +the gap between the two representations, in an attempt to minimize the user's +need to reason about source code locations and other, low-level syntactic +details. + +Range Selectors +^^^^^^^^^^^^^^^ + +Transformer provides a small API for describing source ranges: the +``RangeSelector`` combinators. These ranges are most commonly used to specify the +source code affected by an edit and to extract source code in constructing new +text. + +Roughly, there are two kinds of range combinators: ones that select a source +range based on the AST, and others that combine existing ranges into new ranges. +For example, ``node`` selects the range of source spanned by a particular AST +node, as we've seen, while ``after`` selects the (empty) range located immediately +after its argument range. So, ``after(node("id"))`` is the empty range immediately +following the AST node bound to ``id``. + +For the full collection of ``RangeSelector``\ s, see the header, +`clang/Tooling/Transformer/RangeSelector.h `_ + +Stencils +^^^^^^^^ + +Transformer offers a large and growing collection of combinators for +constructing output. Above, we demonstrated ``cat``, the core function for +constructing stencils. It takes a series of arguments, of three possible kinds: + +#. Raw text, to be copied directly to the output. +#. Selector: specified with a ``RangeSelector``, indicates a range of source text + to copy to the output. +#. Builder: an operation that constructs a code snippet from its arguments. For + example, the ``access`` function we saw above. + +Data of these different types are all represented (generically) by a ``Stencil``. +``cat`` takes text and ``RangeSelector``\ s directly as arguments, rather than +requiring that they be constructed with a builder; other builders are +constructed explicitly. + +In general, ``Stencil``\ s produce text from a match result. So, they are not +limited to generating source code, but can also be used to generate diagnostic +messages that reference (named) elements of the matched code, like we saw in the +example of rewriting method calls. + +Further details of the ``Stencil`` type are documented in the header file +`clang/Tooling/Transformer/Stencil.h `_. + +Edits +^^^^^ + +Transformer supports additional forms of edits. First, in a ``changeTo``, we can +specify the particular portion of code to be replaced, using the same +``RangeSelector`` we saw earlier. For example, we could change the function name +in a function declaration with: + +.. code-block:: c++ + + makeRule(functionDecl(hasName("bad")).bind(f), + changeTo(name(f), cat("good")), + cat("bad is now good")); + +We also provide simpler editing primitives for insertion and deletion: +``insertBefore``, ``insertAfter`` and ``remove``. These can all be found in the header +file +`clang/Tooling/Transformer/RewriteRule.h `_. + +We are not limited one edit per match found. Some situations require making +multiple edits for each match. For example, suppose we wanted to swap two +arguments of a function call. + +For this, we provide an overload of ``makeRule`` that takes a list of edits, +rather than just a single one. Our example might look like: + +.. code-block:: c++ + + makeRule(callExpr(...), + {changeTo(node(arg0), cat(node(arg2))), + changeTo(node(arg2), cat(node(arg0)))}, + cat("swap the first and third arguments of the call")); + +``EditGenerator``\ s (Advanced) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The particular edits we've seen so far are all instances of the ``ASTEdit`` class, +or a list of such. But, not all edits can be expressed as ``ASTEdit``\ s. So, we +also support a very general signature for edit generators: + +.. code-block:: c++ + + using EditGenerator = MatchConsumer>; + +That is, an ``EditGenerator`` is function that maps a ``MatchResult`` to a set +of edits, or fails. This signature supports a very general form of computation +over match results. Transformer provides a number of functions for working with +``EditGenerator``\ s, most notably +`flatten `_ +``EditGenerator``\ s, like list flattening. For the full list, see the header file +`clang/Tooling/Transformer/RewriteRule.h `_. + +Rules +^^^^^ + +We can also compose multiple *rules*, rather than just edits within a rule, +using ``applyFirst``: it composes a list of rules as an ordered choice, where +Transformer applies the first rule whose pattern matches, ignoring others in the +list that follow. If the matchers are independent then order doesn't matter. In +that case, ``applyFirst`` is simply joining the set of rules into one. + +The benefit of ``applyFirst`` is that, for some problems, it allows the user to +more concisely formulate later rules in the list, since their patterns need not +explicitly exclude the earlier patterns of the list. For example, consider a set +of rules that rewrite compound statements, where one rule handles the case of an +empty compound statement and the other handles non-empty compound statements. +With ``applyFirst``, these rules can be expressed compactly as: + +.. code-block:: c++ + + applyFirst({ + makeRule(compoundStmt(statementCountIs(0)).bind("empty"), ...), + makeRule(compoundStmt().bind("non-empty"),...) + }) + +The second rule does not need to explicitly specify that the compound statement +is non-empty -- it follows from the rules position in ``applyFirst``. For more +complicated examples, this can lead to substantially more readable code. + +Sometimes, a modification to the code might require the inclusion of a +particular header file. To this end, users can modify rules to specify include +directives with ``addInclude``. + +For additional documentation on these functions, see the header file +`clang/Tooling/Transformer/RewriteRule.h `_. + +Using a RewriteRule as a clang-tidy check +----------------------------------------- + +Transformer supports executing a rewrite rule as a +`clang-tidy `_ check, with the class +``clang::tidy::utils::TransformerClangTidyCheck``. It is designed to require +minimal code in the definition. For example, given a rule +``MyCheckAsRewriteRule``, one can define a tidy check as follows: + +.. code-block:: c++ + + class MyCheck : public TransformerClangTidyCheck { + public: + MyCheck(StringRef Name, ClangTidyContext *Context) + : TransformerClangTidyCheck(MyCheckAsRewriteRule, Name, Context) {} + }; + +``TransformerClangTidyCheck`` implements the virtual ``registerMatchers`` and +``check`` methods based on your rule specification, so you don't need to implement +them yourself. If the rule needs to be configured based on the language options +and/or the clang-tidy configuration, it can be expressed as a function taking +these as parameters and (optionally) returning a ``RewriteRule``. This would be +useful, for example, for our method-renaming rule, which is parameterized by the +original name and the target. For details, see +`clang-tools-extra/clang-tidy/utils/TransformerClangTidyCheck.h `_ + +Related Reading +--------------- + +A good place to start understanding the clang AST and its matchers is with the +introductions on clang's site: + +* :doc:`Introduction to the Clang AST ` +* :doc:`Matching the Clang AST ` +* `AST Matcher Reference `_ + +.. rubric:: Footnotes + +.. [#f1] Technically, it binds it to the string "str", to which our + variable ``s`` is bound. But, the choice of that id string is + irrelevant, so elide the difference. diff --git a/gnu/llvm/clang/docs/CodeOwners.rst b/gnu/llvm/clang/docs/CodeOwners.rst new file mode 100644 index 00000000000..48128fbc5d9 --- /dev/null +++ b/gnu/llvm/clang/docs/CodeOwners.rst @@ -0,0 +1 @@ +.. include:: ../CodeOwners.rst diff --git a/gnu/llvm/clang/docs/ControlFlowIntegrity.rst b/gnu/llvm/clang/docs/ControlFlowIntegrity.rst index d8537cda1f3..ef47b1c5b4b 100644 --- a/gnu/llvm/clang/docs/ControlFlowIntegrity.rst +++ b/gnu/llvm/clang/docs/ControlFlowIntegrity.rst @@ -92,7 +92,7 @@ similar to the one below before the program aborts. bad-cast.cpp:109:7: runtime error: control flow integrity check for type 'B' failed during base-to-derived cast (vtable address 0x000000425a50) 0x000000425a50: note: vtable is of type 'A' 00 00 00 00 f0 f1 41 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 5a 42 00 - ^ + ^ If diagnostics are enabled, you can also configure CFI to continue program execution instead of aborting by using the :ref:`-fsanitize-recover= @@ -306,6 +306,19 @@ the identity of function pointers is maintained, and calls across shared library boundaries are no different from calls within a single program or shared library. +.. _kcfi: + +``-fsanitize=kcfi`` +------------------- + +This is an alternative indirect call control-flow integrity scheme designed +for low-level system software, such as operating system kernels. Unlike +``-fsanitize=cfi-icall``, it doesn't require ``-flto``, won't result in +function pointers being replaced with jump table references, and never breaks +cross-DSO function address equality. These properties make KCFI easier to +adopt in low-level software. KCFI is limited to checking only function +pointers, and isn't compatible with executable-only memory. + Member Function Pointer Call Checking ===================================== diff --git a/gnu/llvm/clang/docs/ControlFlowIntegrityDesign.rst b/gnu/llvm/clang/docs/ControlFlowIntegrityDesign.rst index 2505066098f..f3a3c8294f7 100644 --- a/gnu/llvm/clang/docs/ControlFlowIntegrityDesign.rst +++ b/gnu/llvm/clang/docs/ControlFlowIntegrityDesign.rst @@ -121,9 +121,9 @@ example class hierarchy will be emitted like this: .. csv-table:: Bit Vectors for A, B, C :header: Class, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14 - A, , , 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, , - B, , , , , , , , 1, , , , , , , - C, , , , , , , , , , , , , 1, , + A, , , 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, , + B, , , , , , , , 1, , , , , , , + C, , , , , , , , , , , , , 1, , Short Inline Bit Vectors ~~~~~~~~~~~~~~~~~~~~~~~~ @@ -149,7 +149,7 @@ If the bit vector fits in 32 bits, the code looks like this: de6: 48 89 df mov %rbx,%rdi de9: ff 10 callq *(%rax) [...] - e0b: 0f 0b ud2 + e0b: 0f 0b ud2 Or if the bit vector fits in 64 bits: @@ -163,13 +163,13 @@ Or if the bit vector fits in 64 bits: 11ba: 48 83 f9 2a cmp $0x2a,%rcx 11be: 77 35 ja 11f5 11c0: 48 ba 09 00 00 00 00 movabs $0x40000000009,%rdx - 11c7: 04 00 00 + 11c7: 04 00 00 11ca: 48 0f a3 ca bt %rcx,%rdx 11ce: 73 25 jae 11f5 11d0: 48 89 df mov %rbx,%rdi 11d3: ff 10 callq *(%rax) [...] - 11f5: 0f 0b ud2 + 11f5: 0f 0b ud2 If the bit vector consists of a single bit, there is only one possible virtual table, and the check can consist of a single equality comparison: @@ -277,14 +277,14 @@ likely to occur if the virtual tables are padded. Forward-Edge CFI for Virtual Calls by Interleaving Virtual Tables ----------------------------------------------------------------- -Dimitar et. al. proposed a novel approach that interleaves virtual tables in [1]_. -This approach is more efficient in terms of space because padding and bit vectors are no longer needed. -At the same time, it is also more efficient in terms of performance because in the interleaved layout -address points of the virtual tables are consecutive, thus the validity check of a virtual -vtable pointer is always a range check. +Dimitar et. al. proposed a novel approach that interleaves virtual tables in [1]_. +This approach is more efficient in terms of space because padding and bit vectors are no longer needed. +At the same time, it is also more efficient in terms of performance because in the interleaved layout +address points of the virtual tables are consecutive, thus the validity check of a virtual +vtable pointer is always a range check. -At a high level, the interleaving scheme consists of three steps: 1) split virtual table groups into -separate virtual tables, 2) order virtual tables by a pre-order traversal of the class hierarchy +At a high level, the interleaving scheme consists of three steps: 1) split virtual table groups into +separate virtual tables, 2) order virtual tables by a pre-order traversal of the class hierarchy and 3) interleave virtual tables. The interleaving scheme implemented in LLVM is inspired by [1]_ but has its own @@ -295,20 +295,20 @@ enhancements (more in `Interleave virtual tables`_). Split virtual table groups into separate virtual tables ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The Itanium C++ ABI glues multiple individual virtual tables for a class into a combined virtual table (virtual table group). +The Itanium C++ ABI glues multiple individual virtual tables for a class into a combined virtual table (virtual table group). The interleaving scheme, however, can only work with individual virtual tables so it must split the combined virtual tables first. In comparison, the old scheme does not require the splitting but it is more efficient when the combined virtual tables have been split. -The `GlobalSplit`_ pass is responsible for splitting combined virtual tables into individual ones. +The `GlobalSplit`_ pass is responsible for splitting combined virtual tables into individual ones. .. _GlobalSplit: https://github.com/llvm/llvm-project/blob/main/llvm/lib/Transforms/IPO/GlobalSplit.cpp -Order virtual tables by a pre-order traversal of the class hierarchy +Order virtual tables by a pre-order traversal of the class hierarchy ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -This step is common to both the old scheme described above and the interleaving scheme. -For the interleaving scheme, since the combined virtual tables have been split in the previous step, -this step ensures that for any class all the compatible virtual tables will appear consecutively. -For the old scheme, the same property may not hold since it may work on combined virtual tables. +This step is common to both the old scheme described above and the interleaving scheme. +For the interleaving scheme, since the combined virtual tables have been split in the previous step, +this step ensures that for any class all the compatible virtual tables will appear consecutively. +For the old scheme, the same property may not hold since it may work on combined virtual tables. For example, consider the following four C++ classes: @@ -338,67 +338,67 @@ This step will arrange the virtual tables for A, B, C, and D in the order of *vt Interleave virtual tables ~~~~~~~~~~~~~~~~~~~~~~~~~ -This step is where the interleaving scheme deviates from the old scheme. Instead of laying out -whole virtual tables in the previously computed order, the interleaving scheme lays out table -entries of the virtual tables strategically to ensure the following properties: +This step is where the interleaving scheme deviates from the old scheme. Instead of laying out +whole virtual tables in the previously computed order, the interleaving scheme lays out table +entries of the virtual tables strategically to ensure the following properties: (1) offset-to-top and RTTI fields layout property -The Itanium C++ ABI specifies that offset-to-top and RTTI fields appear at the offsets behind the -address point. Note that libraries like libcxxabi do assume this property. +The Itanium C++ ABI specifies that offset-to-top and RTTI fields appear at the offsets behind the +address point. Note that libraries like libcxxabi do assume this property. (2) virtual function entry layout property -For each virtual function the distance between an virtual table entry for this function and the corresponding +For each virtual function the distance between an virtual table entry for this function and the corresponding address point is always the same. This property ensures that dynamic dispatch still works with the interleaving layout. -Note that the interleaving scheme in the CFI implementation guarantees both properties above whereas the original scheme proposed -in [1]_ only guarantees the second property. +Note that the interleaving scheme in the CFI implementation guarantees both properties above whereas the original scheme proposed +in [1]_ only guarantees the second property. To illustrate how the interleaving algorithm works, let us continue with the running example. -The algorithm first separates all the virtual table entries into two work lists. To do so, -it starts by allocating two work lists, one initialized with all the offset-to-top entries of virtual tables in the order -computed in the last step, one initialized with all the RTTI entries in the same order. +The algorithm first separates all the virtual table entries into two work lists. To do so, +it starts by allocating two work lists, one initialized with all the offset-to-top entries of virtual tables in the order +computed in the last step, one initialized with all the RTTI entries in the same order. -.. csv-table:: Work list 1 Layout +.. csv-table:: Work list 1 Layout :header: 0, 1, 2, 3 - + A::offset-to-top, B::offset-to-top, D::offset-to-top, C::offset-to-top .. csv-table:: Work list 2 layout :header: 0, 1, 2, 3, - - &A::rtti, &B::rtti, &D::rtti, &C::rtti + + &A::rtti, &B::rtti, &D::rtti, &C::rtti Then for each virtual function the algorithm goes through all the virtual tables in the previously computed order -to collect all the related entries into a virtual function list. +to collect all the related entries into a virtual function list. After this step, there are the following virtual function lists: -.. csv-table:: f1 list +.. csv-table:: f1 list :header: 0, 1, 2, 3 &A::f1, &B::f1, &D::f1, &C::f1 -.. csv-table:: f2 list +.. csv-table:: f2 list :header: 0, 1 &B::f2, &D::f2 -.. csv-table:: f3 list +.. csv-table:: f3 list :header: 0 &C::f3 Next, the algorithm picks the longest remaining virtual function list and appends the whole list to the shortest work list -until no function lists are left, and pads the shorter work list so that they are of the same length. -In the example, f1 list will be first added to work list 1, then f2 list will be added -to work list 2, and finally f3 list will be added to the work list 2. Since work list 1 now has one more entry than -work list 2, a padding entry is added to the latter. After this step, the two work lists look like: +until no function lists are left, and pads the shorter work list so that they are of the same length. +In the example, f1 list will be first added to work list 1, then f2 list will be added +to work list 2, and finally f3 list will be added to the work list 2. Since work list 1 now has one more entry than +work list 2, a padding entry is added to the latter. After this step, the two work lists look like: -.. csv-table:: Work list 1 Layout +.. csv-table:: Work list 1 Layout :header: 0, 1, 2, 3, 4, 5, 6, 7 A::offset-to-top, B::offset-to-top, D::offset-to-top, C::offset-to-top, &A::f1, &B::f1, &D::f1, &C::f1 @@ -407,19 +407,19 @@ work list 2, a padding entry is added to the latter. After this step, the two wo .. csv-table:: Work list 2 layout :header: 0, 1, 2, 3, 4, 5, 6, 7 - &A::rtti, &B::rtti, &D::rtti, &C::rtti, &B::f2, &D::f2, &C::f3, padding + &A::rtti, &B::rtti, &D::rtti, &C::rtti, &B::f2, &D::f2, &C::f3, padding -Finally, the algorithm merges the two work lists into the interleaved layout by alternatingly +Finally, the algorithm merges the two work lists into the interleaved layout by alternatingly moving the head of each list to the final layout. After this step, the final interleaved layout looks like: .. csv-table:: Interleaved layout - :header: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 + :header: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 A::offset-to-top, &A::rtti, B::offset-to-top, &B::rtti, D::offset-to-top, &D::rtti, C::offset-to-top, &C::rtti, &A::f1, &B::f2, &B::f1, &D::f2, &D::f1, &C::f3, &C::f1, padding In the above interleaved layout, each virtual table's offset-to-top and RTTI are always adjacent, which shows that the layout has the first property. For the second property, let us look at f2 as an example. In the interleaved layout, -there are two entries for f2: B::f2 and D::f2. The distance between &B::f2 +there are two entries for f2: B::f2 and D::f2. The distance between &B::f2 and its address point D::offset-to-top (the entry immediately after &B::rtti) is 5 entry-length, so is the distance between &D::f2 and C::offset-to-top (the entry immediately after &D::rtti). Forward-Edge CFI for Indirect Function Calls diff --git a/gnu/llvm/clang/docs/DataFlowAnalysisIntro.md b/gnu/llvm/clang/docs/DataFlowAnalysisIntro.md new file mode 100644 index 00000000000..8bfecd24906 --- /dev/null +++ b/gnu/llvm/clang/docs/DataFlowAnalysisIntro.md @@ -0,0 +1,1000 @@ +# Data flow analysis: an informal introduction + +## Abstract + +This document introduces data flow analysis in an informal way. The goal is to +give the reader an intuitive understanding of how it works, and show how it +applies to a range of refactoring and bug finding problems. + +Data flow analysis is a well-established technique; it is described in many +papers, books, and videos. If you would like a more formal, or a more thorough +explanation of the concepts mentioned in this document, please refer to the +following resources: + +* [The Lattice article in Wikipedia](https://en.wikipedia.org/wiki/Lattice_\(order\)). +* Videos on the PacketPrep YouTube channel that introduce lattices and the + necessary background information: + [#20](https://www.youtube.com/watch?v=73j_FXBXGm8), + [#21](https://www.youtube.com/watch?v=b5sDjo9tfE8), + [#22](https://www.youtube.com/watch?v=saOG7Uooeho), + [#23](https://www.youtube.com/watch?v=3EAYX-wZH0g), + [#24](https://www.youtube.com/watch?v=KRkHwQtW6Cc), + [#25](https://www.youtube.com/watch?v=7Gwzsc4rAgw). +* [Introduction to Dataflow Analysis](https://www.youtube.com/watch?v=OROXJ9-wUQE) +* [Introduction to abstract interpretation](http://www.cs.tau.ac.il/~msagiv/courses/asv/absint-1.pdf). +* [Introduction to symbolic execution](https://www.cs.umd.edu/~mwh/se-tutorial/symbolic-exec.pdf). +* [Static Program Analysis by Anders Møller and Michael I. Schwartzbach](https://cs.au.dk/~amoeller/spa/). +* [EXE: automatically generating inputs of death](https://css.csail.mit.edu/6.858/2020/readings/exe.pdf) + (a paper that successfully applies symbolic execution to real-world + software). + +## Data flow analysis + +### The purpose of data flow analysis + +Data flow analysis is a static analysis technique that proves facts about a +program or its fragment. It can make conclusions about all paths through the +program, while taking control flow into account and scaling to large programs. +The basic idea is propagating facts about the program through the edges of the +control flow graph (CFG) until a fixpoint is reached. + +### Sample problem and an ad-hoc solution + +We would like to explain data flow analysis while discussing an example. Let's +imagine that we want to track possible values of an integer variable in our +program. Here is how a human could annotate the code: + +```c++ +void Example(int n) { + int x = 0; + // x is {0} + if (n > 0) { + x = 5; + // x is {5} + } else { + x = 42; + // x is {42} + } + // x is {5; 42} + print(x); +} +``` + +We use sets of integers to represent possible values of `x`. Local variables +have unambiguous values between statements, so we annotate program points +between statements with sets of possible values. + +Here is how we arrived at these annotations. Assigning a constant to `x` allows +us to make a conclusion that `x` can only have one value. When control flow from +the "then" and "else" branches joins, `x` can have either value. + +Abstract algebra provides a nice formalism that models this kind of structure, +namely, a lattice. A join-semilattice is a partially ordered set, in which every +two elements have a least upper bound (called a *join*). + +``` +join(a, b) ⩾ a and join(a, b) ⩾ b and join(x, x) = x +``` + +For this problem we will use the lattice of subsets of integers, with set +inclusion relation as ordering and set union as a join. + +Lattices are often represented visually as Hasse diagrams. Here is a Hasse +diagram for our lattice that tracks subsets of integers: + +![Hasse diagram for a lattice of integer sets](DataFlowAnalysisIntroImages/IntegerSetsInfiniteLattice.svg) + +Computing the join in the lattice corresponds to finding the lowest common +ancestor (LCA) between two nodes in its Hasse diagram. There is a vast amount of +literature on efficiently implementing LCA queries for a DAG, however Efficient +Implementation of Lattice Operations (1989) +([CiteSeerX](https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.106.4911), +[doi](https://doi.org/10.1145%2F59287.59293)) describes a scheme that +particularly well-suited for programmatic implementation. + +### Too much information and "top" values + +Let's try to find the possible sets of values of `x` in a function that modifies +`x` in a loop: + +```c++ +void ExampleOfInfiniteSets() { + int x = 0; // x is {0} + while (condition()) { + x += 1; // x is {0; 1; 2; …} + } + print(x); // x is {0; 1; 2; …} +} +``` + +We have an issue: `x` can have any value greater than zero; that's an infinite +set of values, if the program operated on mathematical integers. In C++ `int` is +limited by `INT_MAX` so technically we have a set `{0; 1; …; INT_MAX}` which is +still really big. + +To make our analysis practical to compute, we have to limit the amount of +information that we track. In this case, we can, for example, arbitrarily limit +the size of sets to 3 elements. If at a certain program point `x` has more than +3 possible values, we stop tracking specific values at that program point. +Instead, we denote possible values of `x` with the symbol `⊤` (pronounced "top" +according to a convention in abstract algebra). + +```c++ +void ExampleOfTopWithALoop() { + int x = 0; // x is {0} + while (condition()) { + x += 1; // x is ⊤ + } + print(x); // x is ⊤ +} +``` + +The statement "at this program point, `x`'s possible values are `⊤`" is +understood as "at this program point `x` can have any value because we have too +much information, or the information is conflicting". + +Note that we can get more than 3 possible values even without a loop: + +```c++ +void ExampleOfTopWithoutLoops(int n) { + int x = 0; // x is {0} + switch(n) { + case 0: x = 1; break; // x is {1} + case 1: x = 9; break; // x is {9} + case 2: x = 7; break; // x is {7} + default: x = 3; break; // x is {3} + } + // x is ⊤ +} +``` + +### Uninitialized variables and "bottom" values + +When `x` is declared but not initialized, it has no possible values. We +represent this fact symbolically as `⊥` (pronounced "bottom"). + +```c++ +void ExampleOfBottom() { + int x; // x is ⊥ + x = 42; // x is {42} + print(x); +} +``` + +Note that using values read from uninitialized variables is undefined behaviour +in C++. Generally, compilers and static analysis tools can assume undefined +behavior does not happen. We must model uninitialized variables only when we are +implementing a checker that specifically is trying to find uninitialized reads. +In this example we show how to model uninitialized variables only to demonstrate +the concept of "bottom", and how it applies to possible value analysis. We +describe an analysis that finds uninitialized reads in a section below. + +### A practical lattice that tracks sets of concrete values + +Taking into account all corner cases covered above, we can put together a +lattice that we can use in practice to track possible values of integer +variables. This lattice represents sets of integers with 1, 2, or 3 elements, as +well as top and bottom. Here is a Hasse diagram for it: + +![Hasse diagram for a lattice of integer sets](DataFlowAnalysisIntroImages/IntegerSetsFiniteLattice.svg) + +### Formalization + +Let's consider a slightly more complex example, and think about how we can +compute the sets of possible values algorithmically. + +```c++ +void Example(int n) { + int x; // x is ⊥ + if (n > 0) { + if (n == 42) { + x = 44; // x is {44} + } else { + x = 5; // x is {5} + } + print(x); // x is {44; 5} + } else { + x = n; // x is ⊤ + } + print(x); // x is ⊤ +} +``` + +As humans, we understand the control flow from the program text. We used our +understanding of control flow to find program points where two flows join. +Formally, control flow is represented by a CFG (control flow graph): + +![CFG for the code above](DataFlowAnalysisIntroImages/CFGExample.svg) + +We can compute sets of possible values by propagating them through the CFG of +the function: + +* When `x` is declared but not initialized, its possible values are `{}`. The + empty set plays the role of `⊥` in this lattice. + +* When `x` is assigned a concrete value, its possible set of values contains + just that specific value. + +* When `x` is assigned some unknown value, it can have any value. We represent + this fact as `⊤`. + +* When two control flow paths join, we compute the set union of incoming + values (limiting the number of elements to 3, representig larger sets as + `⊤`). + +The sets of possible values are influenced by: + +* Statements, for example, assignments. + +* Joins in control flow, for example, ones that appear at the end of "if" + statements. + +**Effects of statements** are modeled by what is formally known as a transfer +function. A transfer function takes two arguments: the statement, and the state +of `x` at the previous program point. It produces the state of `x` at the next +program point. For example, the transfer function for assignment ignores the +state at the previous program point: + +```c++ +// GIVEN: x is {42; 44} +x = 0; +// CONCLUSION: x is {0} +``` + +The transfer function for `+` performs arithmetic on every set member: + +```c++ +// GIVEN: x is {42, 44} +x = x + 100; +// CONCLUSION: x is {142, 144} +``` + +**Effects of control flow** are modeled by joining the knowledge from all +possible previous program points. + +```c++ +if (...) { + ... + // GIVEN: x is {42} +} else { + ... + // GIVEN: x is {44} +} +// CONCLUSION: x is {42; 44} +``` + +```c++ +// GIVEN: x is {42} +while (...) { + ... + // GIVEN: x is {44} +} +// CONCLUSION: {42; 44} +``` + +The predicate that we marked "given" is usually called a precondition, and the +conclusion is called a postcondition. + +In terms of the CFG, we join the information from all predecessor basic blocks. + +![Modeling the effects of a CFG basic block](DataFlowAnalysisIntroImages/CFGJoinRule.svg) + +Putting it all together, to model the effects of a basic block we compute: + +``` +out = transfer(basic_block, join(in_1, in_2, ..., in_n)) +``` + +(Note that there are other ways to write this equation that produce higher +precision analysis results. The trick is to keep exploring the execution paths +separately and delay joining until later. However, we won't discuss those +variations here.) + +To make a conclusion about all paths through the program, we repeat this +computation on all basic blocks until we reach a fixpoint. In other words, we +keep propagating information through the CFG until the computed sets of values +stop changing. + +If the lattice has a finite height and transfer functions are monotonic the +algorithm is guaranteed to terminate. Each iteration of the algorithm can +change computed values only to larger values from the lattice. In the worst +case, all computed values become `⊤`, which is not very useful, but at least the +analysis terminates at that point, because it can't change any of the values. + +Fixpoint iteration can be optimised by only reprocessing basic blocks which had +one of their inputs changed on the previous iteration. This is typically +implemented using a worklist queue. With this optimisation the time complexity +becomes `O(m * |L|)`, where `m` is the number of basic blocks in the CFG and +`|L|` is the size of lattice used by the analysis. + +## Symbolic execution: a very short informal introduction + +### Symbolic values + +In the previous example where we tried to figure out what values a variable can +have, the analysis had to be seeded with a concrete value. What if there are no +assignments of concrete values in the program? We can still deduce some +interesting information by representing unknown input values symbolically, and +computing results as symbolic expressions: + +```c++ +void PrintAbs(int x) { + int result; + if (x >= 0) { + result = x; // result is {x} + } else { + result = -x; // result is {-x} + } + print(result); // result is {x; -x} +} +``` + +We can't say what specific value gets printed, but we know that it is either `x` +or `-x`. + +Dataflow analysis is an istance of abstract interpretation, and does not dictate +how exactly the lattice and transfer functions should be designed, beyond the +necessary conditions for the analysis to converge. Nevertheless, we can use +symbolic execution ideas to guide our design of the lattice and transfer +functions: lattice values can be symbolic expressions, and transfer functions +can construct more complex symbolic expressions from symbolic expressions that +represent arguments. See [this StackOverflow +discussion](https://cstheory.stackexchange.com/questions/19708/symbolic-execution-is-a-case-of-abstract-interpretation) +for a further comparison of abstract interpretation and symbolic execution. + +### Flow condition + +A human can say about the previous example that the function returns `x` when +`x >= 0`, and `-x` when `x < 0`. We can make this conclusion programmatically by +tracking a flow condition. A flow condition is a predicate written in terms of +the program state that is true at a specific program point regardless of the +execution path that led to this statement. For example, the flow condition for +the program point right before evaluating `result = x` is `x >= 0`. + +If we enhance the lattice to be a set of pairs of values and predicates, the +dataflow analysis computes the following values: + +```c++ +void PrintAbs(int x) { + int result; + if (x >= 0) { + // Flow condition: x >= 0. + result = x; // result is {x if x >= 0} + } else { + // Flow condition: x < 0. + result = -x; // result is {-x if x < 0} + } + print(result); // result is {x if x >= 0; -x if x < 0} +} +``` + +Of course, in a program with loops, symbolic expressions for flow conditions can +grow unbounded. A practical static analysis system must control this growth to +keep the symbolic representations manageable and ensure that the data flow +analysis terminates. For example, it can use a constraint solver to prune +impossible flow conditions, and/or it can abstract them, losing precision, after +their symbolic representations grow beyond some threshold. This is similar to +how we had to limit the sizes of computed sets of possible values to 3 elements. + +### Symbolic pointers + +This approach proves to be particularly useful for modeling pointer values, +since we don't care about specific addresses but just want to give a unique +identifier to a memory location. + +```c++ +void ExampleOfSymbolicPointers(bool b) { + int x = 0; // x is {0} + int* ptr = &x; // x is {0} ptr is {&x} + if (b) { + *ptr = 42; // x is {42} ptr is {&x} + } + print(x); // x is {0; 42} ptr is {&x} +} +``` + +## Example: finding output parameters + +Let's explore how data flow analysis can help with a problem that is hard to +solve with other tools in Clang. + +### Problem description + +Output parameters are function parameters of pointer or reference type whose +pointee is completely overwritten by the function, and not read before it is +overwritten. They are common in pre-C++11 code due to the absence of move +semantics. In modern C++ output parameters are non-idiomatic, and return values +are used instead. + +Imagine that we would like to refactor output parameters to return values to +modernize old code. The first step is to identify refactoring candidates through +static analysis. + +For example, in the following code snippet the pointer `c` is an output +parameter: + +```c++ +struct Customer { + int account_id; + std::string name; +} + +void GetCustomer(Customer *c) { + c->account_id = ...; + if (...) { + c->name = ...; + } else { + c->name = ...; + } +} +``` + +We would like to refactor this code into: + +```c++ +Customer GetCustomer() { + Customer c; + c.account_id = ...; + if (...) { + c.name = ...; + } else { + c.name = ...; + } + return c; +} +``` + +However, in the function below the parameter `c` is not an output parameter +because its field `name` is not overwritten on every path through the function. + +```c++ +void GetCustomer(Customer *c) { + c->account_id = ...; + if (...) { + c->name = ...; + } +} +``` + +The code also cannot read the value of the parameter before overwriting it: + +```c++ +void GetCustomer(Customer *c) { + use(c->account_id); + c->name = ...; + c->account_id = ...; +} +``` + +Functions that escape the pointer also block the refactoring: + +```c++ +Customer* kGlobalCustomer; + +void GetCustomer(Customer *c) { + c->name = ...; + c->account_id = ...; + kGlobalCustomer = c; +} +``` + +To identify a candidate function for refactoring, we need to do the following: + +* Find a function with a non-const pointer or reference parameter. + +* Find the definition of that function. + +* Prove that the function completely overwrites the pointee on all paths + before returning. + +* Prove that the function reads the pointee only after overwriting it. + +* Prove that the function does not persist the pointer in a data structure + that is live after the function returns. + +There are also requirements that all usage sites of the candidate function must +satisfy, for example, that function arguments do not alias, that users are not +taking the address of the function, and so on. Let's consider verifying usage +site conditions to be a separate static analysis problem. + +### Lattice design + +To analyze the function body we can use a lattice which consists of normal +states and failure states. A normal state describes program points where we are +sure that no behaviors that block the refactoring have occurred. Normal states +keep track of all parameter's member fields that are known to be overwritten on +every path from function entry to the corresponding program point. Failure +states accumulate observed violations (unsafe reads and pointer escapes) that +block the refactoring. + +In the partial order of the lattice failure states compare greater than normal +states, which guarantees that they "win" when joined with normal states. Order +between failure states is determined by inclusion relation on the set of +accumulated violations (lattice's `⩽` is `⊆` on the set of violations). Order +between normal states is determined by reversed inclusion relation on the set of +overwritten parameter's member fields (lattice's `⩽` is `⊇` on the set of +overwritten fields). + +![Lattice for data flow analysis that identifies output parameters](DataFlowAnalysisIntroImages/OutputParameterIdentificationLattice.svg) + +To determine whether a statement reads or writes a field we can implement +symbolic evaluation of `DeclRefExpr`s, `LValueToRValue` casts, pointer +dereference operator and `MemberExpr`s. + +### Using data flow results to identify output parameters + +Let's take a look at how we use data flow analysis to identify an output +parameter. The refactoring can be safely done when the data flow algorithm +computes a normal state with all of the fields proven to be overwritten in the +exit basic block of the function. + +```c++ +struct Customer { + int account_id; + std::string name; +}; + +void GetCustomer(Customer* c) { + // Overwritten: {} + c->account_id = ...; // Overwritten: {c->account_id} + if (...) { + c->name = ...; // Overwritten: {c->account_id, c->name} + } else { + c->name = ...; // Overwritten: {c->account_id, c->name} + } + // Overwritten: {c->account_id, c->name} +} +``` + +When the data flow algorithm computes a normal state, but not all fields are +proven to be overwritten we can't perform the refactoring. + +```c++ +void target(bool b, Customer* c) { + // Overwritten: {} + if (b) { + c->account_id = 42; // Overwritten: {c->account_id} + } else { + c->name = "Konrad"; // Overwritten: {c->name} + } + // Overwritten: {} +} +``` + +Similarly, when the data flow algorithm computes a failure state, we also can't +perform the refactoring. + +```c++ +Customer* kGlobalCustomer; + +void GetCustomer(Customer* c) { + // Overwritten: {} + c->account_id = ...; // Overwritten: {c->account_id} + if (...) { + print(c->name); // Unsafe read + } else { + kGlobalCustomer = c; // Pointer escape + } + // Unsafe read, Pointer escape +} +``` + +## Example: finding dead stores + +Let's say we want to find redundant stores, because they indicate potential +bugs. + +```c++ +x = GetX(); +x = GetY(); +``` + +The first store to `x` is never read, probably there is a bug. + +The implementation of dead store analysis is very similar to output parameter +analysis: we need to track stores and loads, and find stores that were never +read. + +[Liveness analysis](https://en.wikipedia.org/wiki/Live_variable_analysis) is a +generalization of this idea, which is often used to answer many related +questions, for example: + +* finding dead stores, +* finding uninitialized variables, +* finding a good point to deallocate memory, +* finding out if it would be safe to move an object. + +## Example: definitive initialization + +Definitive initialization proves that variables are known to be initialized when +read. If we find a variable which is read when not initialized then we generate +a warning. + +```c++ +void Init() { + int x; // x is uninitialized + if (cond()) { + x = 10; // x is initialized + } else { + x = 20; // x is initialized + } + print(x); // x is initialized +} +``` + +```c++ +void Uninit() { + int x; // x is uninitialized + if (cond()) { + x = 10; // x is initialized + } + print(x); // x is maybe uninitialized, x is being read, report a bug. +} +``` + +For this purpose we can use lattice in a form of a mapping from variable +declarations to initialization states; each initialization state is represented +by the followingn lattice: + +![Lattice for definitive initialization analysis](DataFlowAnalysisIntroImages/DefinitiveInitializationLattice.svg) + +A lattice element could also capture the source locations of the branches that +lead us to the corresponding program point. Diagnostics would use this +information to show a sample buggy code path to the user. + +## Example: refactoring raw pointers to `unique_ptr` + +Modern idiomatic C++ uses smart pointers to express memory ownership, however in +pre-C++11 code one can often find raw pointers that own heap memory blocks. + +Imagine that we would like to refactor raw pointers that own memory to +`unique_ptr`. There are multiple ways to design a data flow analysis for this +problem; let's look at one way to do it. + +For example, we would like to refactor the following code that uses raw +pointers: + +```c++ +void UniqueOwnership1() { + int *pi = new int; + if (...) { + Borrow(pi); + delete pi; + } else { + TakeOwnership(pi); + } +} +``` + +into code that uses `unique_ptr`: + +```c++ +void UniqueOwnership1() { + auto pi = std::make_unique(); + if (...) { + Borrow(pi.get()); + } else { + TakeOwnership(pi.release()); + } +} +``` + +This problem can be solved with a lattice in form of map from value declarations +to pointer states: + +![Lattice that identifies candidates for unique_ptr refactoring](DataFlowAnalysisIntroImages/UniquePtrLattice.svg) + +We can perform the refactoring if at the exit of a function `pi` is +`Compatible`. + +```c++ +void UniqueOwnership1() { + int *pi; // pi is Compatible + pi = new int; // pi is Defined + if (...) { + Borrow(pi); // pi is Defined + delete pi; // pi is Compatible + } else { + TakeOwnership(pi); // pi is Compatible + } + // pi is Compatible +} +``` + +Let's look at an example where the raw pointer owns two different memory blocks: + +```c++ +void UniqueOwnership2() { + int *pi = new int; // pi is Defined + Borrow(pi); + delete pi; // pi is Compatible + if (smth) { + pi = new int; // pi is Defined + Borrow(pi); + delete pi; // pi is Compatible + } + // pi is Compatible +} +``` + +It can be refactored to use `unique_ptr` like this: + +```c++ +void UniqueOwnership2() { + auto pi = make_unique(); + Borrow(pi); + if (smth) { + pi = make_unique(); + Borrow(pi); + } +} +``` + +In the following example, the raw pointer is used to access the heap object +after the ownership has been transferred. + +```c++ +void UniqueOwnership3() { + int *pi = new int; // pi is Defined + if (...) { + Borrow(pi); + delete pi; // pi is Compatible + } else { + vector> v = {std::unique_ptr(pi)}; // pi is Compatible + print(*pi); + use(v); + } + // pi is Compatible +} +``` + +We can refactor this code to use `unique_ptr`, however we would have to +introduce a non-owning pointer variable, since we can't use the moved-from +`unique_ptr` to access the object: + +```c++ +void UniqueOwnership3() { + std::unique_ptr pi = std::make_unique(); + if (...) { + Borrow(pi); + } else { + int *pi_non_owning = pi.get(); + vector> v = {std::move(pi)}; + print(*pi_non_owning); + use(v); + } +} +``` + +If the original code didn't call `delete` at the very end of the function, then +our refactoring may change the point at which we run the destructor and release +memory. Specifically, if there is some user code after `delete`, then extending +the lifetime of the object until the end of the function may hold locks for +longer than necessary, introduce memory overhead etc. + +One solution is to always replace `delete` with a call to `reset()`, and then +perform another analysis that removes unnecessary `reset()` calls. + +```c++ +void AddedMemoryOverhead() { + HugeObject *ho = new HugeObject(); + use(ho); + delete ho; // Release the large amount of memory quickly. + LongRunningFunction(); +} +``` + +This analysis will refuse to refactor code that mixes borrowed pointer values +and unique ownership. In the following code, `GetPtr()` returns a borrowed +pointer, which is assigned to `pi`. Then, `pi` is used to hold a uniquely-owned +pointer. We don't distinguish between these two assignments, and we want each +assignment to be paired with a corresponding sink; otherwise, we transition the +pointer to a `Conflicting` state, like in this example. + +```c++ +void ConflictingOwnership() { + int *pi; // pi is Compatible + pi = GetPtr(); // pi is Defined + Borrow(pi); // pi is Defined + + pi = new int; // pi is Conflicting + Borrow(pi); + delete pi; + // pi is Conflicting +} +``` + +We could still handle this case by finding a maximal range in the code where +`pi` could be in the Compatible state, and only refactoring that part. + +```c++ +void ConflictingOwnership() { + int *pi; + pi = GetPtr(); + Borrow(pi); + + std::unique_ptr pi_unique = std::make_unique(); + Borrow(pi_unique.get()); +} +``` + +## Example: finding redundant branch conditions + +In the code below `b1` should not be checked in both the outer and inner "if" +statements. It is likely there is a bug in this code. + +```c++ +int F(bool b1, bool b2) { + if (b1) { + f(); + if (b1 && b2) { // Check `b1` again -- unnecessary! + g(); + } + } +} +``` + +A checker that finds this pattern syntactically is already implemented in +ClangTidy using AST matchers (`bugprone-redundant-branch-condition`). + +To implement it using the data flow analysis framework, we can produce a warning +if any part of the branch condition is implied by the flow condition. + +```c++ +int F(bool b1, bool b2) { + // Flow condition: true. + if (b1) { + // Flow condition: b1. + f(); + if (b1 && b2) { // `b1` is implied by the flow condition. + g(); + } + } +} +``` + +One way to check this implication is to use a SAT solver. Without a SAT solver, +we could keep the flow condition in the CNF form and then it would be easy to +check the implication. + +## Example: finding unchecked `std::optional` unwraps + +Calling `optional::value()` is only valid if `optional::has_value()` is true. We +want to show that when `x.value()` is executed, the flow condition implies +`x.has_value()`. + +In the example below `x.value()` is accessed safely because it is guarded by the +`x.has_value()` check. + +```c++ +void Example(std::optional &x) { + if (x.has_value()) { + use(x.value()); + } +} +``` + +While entering the if branch we deduce that `x.has_value()` is implied by the +flow condition. + +```c++ +void Example(std::optional x) { + // Flow condition: true. + if (x.has_value()) { + // Flow condition: x.has_value() == true. + use(x.value()); + } + // Flow condition: true. +} +``` + +We also need to prove that `x` is not modified between check and value access. +The modification of `x` may be very subtle: + +```c++ +void F(std::optional &x); + +void Example(std::optional &x) { + if (x.has_value()) { + // Flow condition: x.has_value() == true. + unknown_function(x); // may change x. + // Flow condition: true. + use(x.value()); + } +} +``` + +## Example: finding dead code behind A/B experiment flags + +Finding dead code is a classic application of data flow analysis. + +Unused flags for A/B experiment hide dead code. However, this flavor of dead +code is invisible to the compiler because the flag can be turned on at any +moment. + +We could make a tool that deletes experiment flags. The user tells us which flag +they want to delete, and we assume that the it's value is a given constant. + +For example, the user could use the tool to remove `example_flag` from this +code: + +```c++ +DEFINE_FLAG(std::string, example_flag, "", "A sample flag."); + +void Example() { + bool x = GetFlag(FLAGS_example_flag).empty(); + f(); + if (x) { + g(); + } else { + h(); + } +} +``` + +The tool would simplify the code to: + +```c++ +void Example() { + f(); + g(); +} +``` + +We can solve this problem with a classic constant propagation lattice combined +with symbolic evaluation. + +## Example: finding inefficient usages of associative containers + +Real-world code often accidentally performs repeated lookups in associative +containers: + +```c++ +map xs; +xs[42]->name = "..."; +xs[42]->title = "..."; +``` + +To find the above inefficiency we can use the available expressions analysis to +understand that `m[42]` is evaluated twice. + +```c++ +map xs; +Employee &e = xs[42]; +e->name = "..."; +e->title = "..."; +``` + +We can also track the `m.contains()` check in the flow condition to find +redundant checks, like in the example below. + +```c++ +std::map xs; +if (!xs.contains(42)) { + xs.insert({42, someEmployee}); +} +``` + +## Example: refactoring types that implicitly convert to each other + +Refactoring one strong type to another is difficult, but the compiler can help: +once you refactor one reference to the type, the compiler will flag other places +where this information flows with type mismatch errors. Unfortunately this +strategy does not work when you are refactoring types that implicitly convert to +each other, for example, replacing `int32_t` with `int64_t`. + +Imagine that we want to change user IDs from 32 to 64-bit integers. In other +words, we need to find all integers tainted with user IDs. We can use data flow +analysis to implement taint analysis. + +```c++ +void UseUser(int32_t user_id) { + int32_t id = user_id; + // Variable `id` is tainted with a user ID. + ... +} +``` + +Taint analysis is very well suited to this problem because the program rarely +branches on user IDs, and almost certainly does not perform any computation +(like arithmetic). diff --git a/gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/CFGExample.svg b/gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/CFGExample.svg new file mode 100644 index 00000000000..8e815760185 --- /dev/null +++ b/gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/CFGExample.svg @@ -0,0 +1,520 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Entry + + // Pre: x is ⊥int x;if (n > 0)// Post: x is ⊥ + + // Pre: x is ⊥x = n;// Post: x is ⊤ + + // Pre: x is ⊥if (n == 42)// Post: x is ⊥ + + // Pre: x is ⊥x = 5;// Post: x is {5} + + // Pre: x is ⊥x = 44;// Post: x is {44} + + // Pre: x is {5; 44}print(x);// Post: x is {5; 44} + + // Pre: x is ⊤print(x);// Post: x is ⊤ + + + + + + + + + + + Exit + + True + True + False + False + + diff --git a/gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/CFGJoinRule.svg b/gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/CFGJoinRule.svg new file mode 100644 index 00000000000..95daffa8d90 --- /dev/null +++ b/gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/CFGJoinRule.svg @@ -0,0 +1,222 @@ + + + + + + + + + + + + (Given) + (Conclusion) + in1 + in2 + inn + join(in1, in2, …, inn) + out = transfer(basic_block, join(in1, in2, …, inn)) + + Basic block + + + … + + + + diff --git a/gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/DefinitiveInitializationLattice.svg b/gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/DefinitiveInitializationLattice.svg new file mode 100644 index 00000000000..861a3f9c74b --- /dev/null +++ b/gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/DefinitiveInitializationLattice.svg @@ -0,0 +1,114 @@ + + + + + + + + + + + + Maybe uninitialized + Initialized + Uninitialized + + + + + + + diff --git a/gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/IntegerSetsFiniteLattice.svg b/gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/IntegerSetsFiniteLattice.svg new file mode 100644 index 00000000000..aab7d3e986b --- /dev/null +++ b/gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/IntegerSetsFiniteLattice.svg @@ -0,0 +1,403 @@ + + + + + ⊥ = {} + … + … + {−9} + {−5} + … + {−3} + {−2} + {−1} + {0} + {1} + {2} + {3} + … + + + + + + + + + + … + … + {−9, −5} + {−3, −1} + … + {1, 2} + … + + + + + + + + {1, 2, 3} + + … + … + ⊤ = ℤ + + + + + + + diff --git a/gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/IntegerSetsInfiniteLattice.svg b/gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/IntegerSetsInfiniteLattice.svg new file mode 100644 index 00000000000..380aa2a0b4e --- /dev/null +++ b/gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/IntegerSetsInfiniteLattice.svg @@ -0,0 +1,403 @@ + + + + + ⊥ = {} + … + … + {−9} + {−5} + … + {−3} + {−2} + {−1} + {0} + {1} + {2} + {3} + … + + + + + + + + + + … + … + {−9, −5} + {−3, −1} + … + {1, 2} + … + + + + + + + + {1, 2, 3} + + … + … + (goes up infinitely) + + + + + + + diff --git a/gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/OutputParameterIdentificationLattice.svg b/gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/OutputParameterIdentificationLattice.svg new file mode 100644 index 00000000000..5658587c2ee --- /dev/null +++ b/gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/OutputParameterIdentificationLattice.svg @@ -0,0 +1,340 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Overwritten: {p->x, p->y, p->z} + Overwritten: {p->x, p->z} + Overwritten: {p->x, p->z} + Overwritten: {p->q} + Overwritten: {} + + + + + Normal states + + + Failure states + {Unsafe read at line 3} + {Pointer escape at line 5} + {Unsafe read at line 7} + {Unsafe read at line 3, Pointer escape at line 5} + + + {Unsafe read at line 3, Pointer escape at line 5, Unsafe read at line 7} + + + + + diff --git a/gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/UniquePtrLattice.svg b/gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/UniquePtrLattice.svg new file mode 100644 index 00000000000..f7a618ab0c9 --- /dev/null +++ b/gnu/llvm/clang/docs/DataFlowAnalysisIntroImages/UniquePtrLattice.svg @@ -0,0 +1,114 @@ + + + + + + + + + + + + Conflicting + Defined + Compatible + + + + + + + diff --git a/gnu/llvm/clang/docs/DataFlowSanitizer.rst b/gnu/llvm/clang/docs/DataFlowSanitizer.rst index 1253cb98e63..6faca3f2ed9 100644 --- a/gnu/llvm/clang/docs/DataFlowSanitizer.rst +++ b/gnu/llvm/clang/docs/DataFlowSanitizer.rst @@ -32,15 +32,15 @@ libc++ and the libc++ ABI with data flow sanitizer instrumentation. .. code-block:: console + mkdir libcxx-build cd libcxx-build # An example using ninja - cmake -GNinja path/to/llvm-project/llvm \ + cmake -GNinja -S /runtimes \ -DCMAKE_C_COMPILER=clang \ -DCMAKE_CXX_COMPILER=clang++ \ -DLLVM_USE_SANITIZER="DataFlow" \ - -DLLVM_ENABLE_LIBCXX=ON \ - -DLLVM_ENABLE_PROJECTS="libcxx;libcxxabi" + -DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi" ninja cxx cxxabi @@ -137,6 +137,20 @@ For example: fun:memcpy=uninstrumented fun:memcpy=custom +For instrumented functions, the ABI list supports a ``force_zero_labels`` +category, which will make all stores and return values set zero labels. +Functions should never be labelled with both ``force_zero_labels`` +and ``uninstrumented`` or any of the unistrumented wrapper kinds. + +For example: + +.. code-block:: none + + # e.g. void writes_data(char* out_buf, int out_buf_len) {...} + # Applying force_zero_labels will force out_buf shadow to zero. + fun:writes_data=force_zero_labels + + Compilation Flags ----------------- @@ -200,6 +214,25 @@ labels of just ``v1`` and ``v2``. void __dfsan_mem_transfer_callback(dfsan_label *Start, size_t Len); void __dfsan_cmp_callback(dfsan_label CombinedLabel); +* ``-dfsan-conditional-callbacks`` -- An experimental feature that inserts + callbacks for control flow conditional expressions. + This can be used to find where tainted values can control execution. + + In addition to this compilation flag, a callback handler must be registered + using ``dfsan_set_conditional_callback(my_callback);``, where my_callback is + a function with a signature matching + ``void my_callback(dfsan_label l, dfsan_origin o);``. + This signature is the same when origin tracking is disabled - in this case + the dfsan_origin passed in it will always be 0. + + The callback will only be called when a tainted value reaches a conditional + expression for control flow (such as an if's condition). + The callback will be skipped for conditional expressions inside signal + handlers, as this is prone to deadlock. Tainted values used in conditional + expressions inside signal handlers will instead be aggregated via bitwise + or, and can be accessed using + ``dfsan_label dfsan_get_labels_in_signal_conditional();``. + * ``-dfsan-track-origins`` -- Controls how to track origins. When its value is 0, the runtime does not track origins. When its value is 1, the runtime tracks origins at memory store operations. When its value is 2, the runtime tracks diff --git a/gnu/llvm/clang/docs/DataFlowSanitizerDesign.rst b/gnu/llvm/clang/docs/DataFlowSanitizerDesign.rst index bed4d2f38cb..4f60391d9f5 100644 --- a/gnu/llvm/clang/docs/DataFlowSanitizerDesign.rst +++ b/gnu/llvm/clang/docs/DataFlowSanitizerDesign.rst @@ -51,7 +51,7 @@ file ``sanitizer/dfsan_interface.h``. /// Retrieves the label associated with the data at the given address. dfsan_label dfsan_read_label(const void *addr, size_t size); - /// Returns whether the given label label contains the label elem. + /// Returns whether the given label contains the label elem. int dfsan_has_label(dfsan_label label, dfsan_label elem); /// Computes the union of \c l1 and \c l2, resulting in a union label. @@ -139,7 +139,7 @@ Origin tracking trace representation ------------------------------------ An origin tracking trace is a list of chains. Each chain has a stack trace -where the DFSan runtime records a label propapation, and a pointer to its +where the DFSan runtime records a label propagation, and a pointer to its previous chain. The very first chain does not point to any chain. Every four 4-bytes aligned application bytes share a 4-byte origin trace ID. A diff --git a/gnu/llvm/clang/docs/DebuggingCoroutines.rst b/gnu/llvm/clang/docs/DebuggingCoroutines.rst new file mode 100644 index 00000000000..ae535911777 --- /dev/null +++ b/gnu/llvm/clang/docs/DebuggingCoroutines.rst @@ -0,0 +1,741 @@ +======================== +Debugging C++ Coroutines +======================== + +.. contents:: + :local: + +Introduction +============ + +For performance and other architectural reasons, the C++ Coroutines feature in +the Clang compiler is implemented in two parts of the compiler. Semantic +analysis is performed in Clang, and Coroutine construction and optimization +takes place in the LLVM middle-end. + +However, this design forces us to generate insufficient debugging information. +Typically, the compiler generates debug information in the Clang frontend, as +debug information is highly language specific. However, this is not possible +for Coroutine frames because the frames are constructed in the LLVM middle-end. + +To mitigate this problem, the LLVM middle end attempts to generate some debug +information, which is unfortunately incomplete, since much of the language +specific information is missing in the middle end. + +This document describes how to use this debug information to better debug +coroutines. + +Terminology +=========== + +Due to the recent nature of C++20 Coroutines, the terminology used to describe +the concepts of Coroutines is not settled. This section defines a common, +understandable terminology to be used consistently throughout this document. + +coroutine type +-------------- + +A `coroutine function` is any function that contains any of the Coroutine +Keywords `co_await`, `co_yield`, or `co_return`. A `coroutine type` is a +possible return type of one of these `coroutine functions`. `Task` and +`Generator` are commonly referred to coroutine types. + +coroutine +--------- + +By technical definition, a `coroutine` is a suspendable function. However, +programmers typically use `coroutine` to refer to an individual instance. +For example: + +.. code-block:: c++ + + std::vector Coros; // Task is a coroutine type. + for (int i = 0; i < 3; i++) + Coros.push_back(CoroTask()); // CoroTask is a coroutine function, which + // would return a coroutine type 'Task'. + +In practice, we typically say "`Coros` contains 3 coroutines" in the above +example, though this is not strictly correct. More technically, this should +say "`Coros` contains 3 coroutine instances" or "Coros contains 3 coroutine +objects." + +In this document, we follow the common practice of using `coroutine` to refer +to an individual `coroutine instance`, since the terms `coroutine instance` and +`coroutine object` aren't sufficiently defined in this case. + +coroutine frame +--------------- + +The C++ Standard uses `coroutine state` to describe the allocated storage. In +the compiler, we use `coroutine frame` to describe the generated data structure +that contains the necessary information. + +The structure of coroutine frames +================================= + +The structure of coroutine frames is defined as: + +.. code-block:: c++ + + struct { + void (*__r)(); // function pointer to the `resume` function + void (*__d)(); // function pointer to the `destroy` function + promise_type; // the corresponding `promise_type` + ... // Any other needed information + } + +In the debugger, the function's name is obtainable from the address of the +function. And the name of `resume` function is equal to the name of the +coroutine function. So the name of the coroutine is obtainable once the +address of the coroutine is known. + +Print promise_type +================== + +Every coroutine has a `promise_type`, which defines the behavior +for the corresponding coroutine. In other words, if two coroutines have the +same `promise_type`, they should behave in the same way. +To print a `promise_type` in a debugger when stopped at a breakpoint inside a +coroutine, printing the `promise_type` can be done by: + +.. parsed-literal:: + + print __promise + +It is also possible to print the `promise_type` of a coroutine from the address +of the coroutine frame. For example, if the address of a coroutine frame is +0x416eb0, and the type of the `promise_type` is `task::promise_type`, printing +the `promise_type` can be done by: + +.. parsed-literal:: + + print (task::promise_type)*(0x416eb0+0x10) + +This is possible because the `promise_type` is guaranteed by the ABI to be at a +16 bit offset from the coroutine frame. + +Note that there is also an ABI independent method: + +.. parsed-literal:: + + print std::coroutine_handle::from_address((void*)0x416eb0).promise() + +The functions `from_address(void*)` and `promise()` are often small enough to +be removed during optimization, so this method may not be possible. + +Print coroutine frames +====================== + +LLVM generates the debug information for the coroutine frame in the LLVM middle +end, which permits printing of the coroutine frame in the debugger. Much like +the `promise_type`, when stopped at a breakpoint inside a coroutine we can +print the coroutine frame by: + +.. parsed-literal:: + + print __coro_frame + + +Just as printing the `promise_type` is possible from the coroutine address, +printing the details of the coroutine frame from an address is also possible: + +:: + + (gdb) # Get the address of coroutine frame + (gdb) print/x *0x418eb0 + $1 = 0x4019e0 + (gdb) # Get the linkage name for the coroutine + (gdb) x 0x4019e0 + 0x4019e0 <_ZL9coro_taski>: 0xe5894855 + (gdb) # Turn off the demangler temporarily to avoid the debugger misunderstanding the name. + (gdb) set demangle-style none + (gdb) # The coroutine frame type is 'linkage_name.coro_frame_ty' + (gdb) print ('_ZL9coro_taski.coro_frame_ty')*(0x418eb0) + $2 = {__resume_fn = 0x4019e0 , __destroy_fn = 0x402000 , __promise = {...}, ...} + +The above is possible because: + +(1) The name of the debug type of the coroutine frame is the `linkage_name`, +plus the `.coro_frame_ty` suffix because each coroutine function shares the +same coroutine type. + +(2) The coroutine function name is accessible from the address of the coroutine +frame. + +The above commands can be simplified by placing them in debug scripts. + +Examples to print coroutine frames +---------------------------------- + +The print examples below use the following definition: + +.. code-block:: c++ + + #include + #include + + struct task{ + struct promise_type { + task get_return_object() { return std::coroutine_handle::from_promise(*this); } + std::suspend_always initial_suspend() { return {}; } + std::suspend_always final_suspend() noexcept { return {}; } + void return_void() noexcept {} + void unhandled_exception() noexcept {} + + int count = 0; + }; + + void resume() noexcept { + handle.resume(); + } + + task(std::coroutine_handle hdl) : handle(hdl) {} + ~task() { + if (handle) + handle.destroy(); + } + + std::coroutine_handle<> handle; + }; + + class await_counter : public std::suspend_always { + public: + template + void await_suspend(std::coroutine_handle handle) noexcept { + handle.promise().count++; + } + }; + + static task coro_task(int v) { + int a = v; + co_await await_counter{}; + a++; + std::cout << a << "\n"; + a++; + std::cout << a << "\n"; + a++; + std::cout << a << "\n"; + co_await await_counter{}; + a++; + std::cout << a << "\n"; + a++; + std::cout << a << "\n"; + } + + int main() { + task t = coro_task(43); + t.resume(); + t.resume(); + t.resume(); + return 0; + } + +In debug mode (`O0` + `g`), the printing result would be: + +.. parsed-literal:: + + {__resume_fn = 0x4019e0 , __destroy_fn = 0x402000 , __promise = {count = 1}, v = 43, a = 45, __coro_index = 1 '\001', struct_std__suspend_always_0 = {__int_8 = 0 '\000'}, + class_await_counter_1 = {__int_8 = 0 '\000'}, class_await_counter_2 = {__int_8 = 0 '\000'}, struct_std__suspend_always_3 = {__int_8 = 0 '\000'}} + +In the above, the values of `v` and `a` are clearly expressed, as are the +temporary values for `await_counter` (`class_await_counter_1` and +`class_await_counter_2`) and `std::suspend_always` ( +`struct_std__suspend_always_0` and `struct_std__suspend_always_3`). The index +of the current suspension point of the coroutine is emitted as `__coro_index`. +In the above example, the `__coro_index` value of `1` means the coroutine +stopped at the second suspend point (Note that `__coro_index` is zero indexed) +which is the first `co_await await_counter{};` in `coro_task`. Note that the +first initial suspend point is the compiler generated +`co_await promise_type::initial_suspend()`. + +However, when optimizations are enabled, the printed result changes drastically: + +.. parsed-literal:: + + {__resume_fn = 0x401280 , __destroy_fn = 0x401390 , __promise = {count = 1}, __int_32_0 = 43, __coro_index = 1 '\001'} + +Unused values are optimized out, as well as the name of the local variable `a`. +The only information remained is the value of a 32 bit integer. In this simple +case, it seems to be pretty clear that `__int_32_0` represents `a`. However, it +is not true. + +An important note with optimization is that the value of a variable may not +properly express the intended value in the source code. For example: + +.. code-block:: c++ + + static task coro_task(int v) { + int a = v; + co_await await_counter{}; + a++; // __int_32_0 is 43 here + std::cout << a << "\n"; + a++; // __int_32_0 is still 43 here + std::cout << a << "\n"; + a++; // __int_32_0 is still 43 here! + std::cout << a << "\n"; + co_await await_counter{}; + a++; // __int_32_0 is still 43 here!! + std::cout << a << "\n"; + a++; // Why is __int_32_0 still 43 here? + std::cout << a << "\n"; + } + +When debugging step-by-step, the value of `__int_32_0` seemingly does not +change, despite being frequently incremented, and instead is always `43`. +While this might be surprising, this is a result of the optimizer recognizing +that it can eliminate most of the load/store operations. The above code gets +optimized to the equivalent of: + +.. code-block:: c++ + + static task coro_task(int v) { + store v to __int_32_0 in the frame + co_await await_counter{}; + a = load __int_32_0 + std::cout << a+1 << "\n"; + std::cout << a+2 << "\n"; + std::cout << a+3 << "\n"; + co_await await_counter{}; + a = load __int_32_0 + std::cout << a+4 << "\n"; + std::cout << a+5 << "\n"; + } + +It should now be obvious why the value of `__int_32_0` remains unchanged +throughout the function. It is important to recognize that `__int_32_0` +does not directly correspond to `a`, but is instead a variable generated +to assist the compiler in code generation. The variables in an optimized +coroutine frame should not be thought of as directly representing the +variables in the C++ source. + +Get the suspended points +======================== + +An important requirement for debugging coroutines is to understand suspended +points, which are where the coroutine is currently suspended and awaiting. + +For simple cases like the above, inspecting the value of the `__coro_index` +variable in the coroutine frame works well. + +However, it is not quite so simple in really complex situations. In these +cases, it is necessary to use the coroutine libraries to insert the +line-number. + +For example: + +.. code-block:: c++ + + // For all the promise_type we want: + class promise_type { + ... + + unsigned line_number = 0xffffffff; + }; + + #include + + // For all the awaiter types we need: + class awaiter { + ... + template + void await_suspend(std::coroutine_handle handle, + std::source_location sl = std::source_location::current()) { + ... + handle.promise().line_number = sl.line(); + } + }; + +In this case, we use `std::source_location` to store the line number of the +await inside the `promise_type`. Since we can locate the coroutine function +from the address of the coroutine, we can identify suspended points this way +as well. + +The downside here is that this comes at the price of additional runtime cost. +This is consistent with the C++ philosophy of "Pay for what you use". + +Get the asynchronous stack +========================== + +Another important requirement to debug a coroutine is to print the asynchronous +stack to identify the asynchronous caller of the coroutine. As many +implementations of coroutine types store `std::coroutine_handle<> continuation` +in the promise type, identifying the caller should be trivial. The +`continuation` is typically the awaiting coroutine for the current coroutine. +That is, the asynchronous parent. + +Since the `promise_type` is obtainable from the address of a coroutine and +contains the corresponding continuation (which itself is a coroutine with a +`promise_type`), it should be trivial to print the entire asynchronous stack. + +This logic should be quite easily captured in a debugger script. + +Examples to print asynchronous stack +------------------------------------ + +Here is an example to print the asynchronous stack for the normal task implementation. + +.. code-block:: c++ + + // debugging-example.cpp + #include + #include + #include + + struct task { + struct promise_type { + task get_return_object(); + std::suspend_always initial_suspend() { return {}; } + + void unhandled_exception() noexcept {} + + struct FinalSuspend { + std::coroutine_handle<> continuation; + auto await_ready() noexcept { return false; } + auto await_suspend(std::coroutine_handle<> handle) noexcept { + return continuation; + } + void await_resume() noexcept {} + }; + FinalSuspend final_suspend() noexcept { return {continuation}; } + + void return_value(int res) { result = res; } + + std::coroutine_handle<> continuation = std::noop_coroutine(); + int result = 0; + }; + + task(std::coroutine_handle handle) : handle(handle) {} + ~task() { + if (handle) + handle.destroy(); + } + + auto operator co_await() { + struct Awaiter { + std::coroutine_handle handle; + auto await_ready() { return false; } + auto await_suspend(std::coroutine_handle<> continuation) { + handle.promise().continuation = continuation; + return handle; + } + int await_resume() { + int ret = handle.promise().result; + handle.destroy(); + return ret; + } + }; + return Awaiter{std::exchange(handle, nullptr)}; + } + + int syncStart() { + handle.resume(); + return handle.promise().result; + } + + private: + std::coroutine_handle handle; + }; + + task task::promise_type::get_return_object() { + return std::coroutine_handle::from_promise(*this); + } + + namespace detail { + template + task chain_fn() { + co_return N + co_await chain_fn(); + } + + template <> + task chain_fn<0>() { + // This is the default breakpoint. + __builtin_debugtrap(); + co_return 0; + } + } // namespace detail + + task chain() { + co_return co_await detail::chain_fn<30>(); + } + + int main() { + std::cout << chain().syncStart() << "\n"; + return 0; + } + +In the example, the ``task`` coroutine holds a ``continuation`` field, +which would be resumed once the ``task`` completes. +In another word, the ``continuation`` is the asynchronous caller for the ``task``. +Just like the normal function returns to its caller when the function completes. + +So we can use the ``continuation`` field to construct the asynchronous stack: + +.. code-block:: python + + # debugging-helper.py + import gdb + from gdb.FrameDecorator import FrameDecorator + + class SymValueWrapper(): + def __init__(self, symbol, value): + self.sym = symbol + self.val = value + + def __str__(self): + return str(self.sym) + " = " + str(self.val) + + def get_long_pointer_size(): + return gdb.lookup_type('long').pointer().sizeof + + def cast_addr2long_pointer(addr): + return gdb.Value(addr).cast(gdb.lookup_type('long').pointer()) + + def dereference(addr): + return long(cast_addr2long_pointer(addr).dereference()) + + class CoroutineFrame(object): + def __init__(self, task_addr): + self.frame_addr = task_addr + self.resume_addr = task_addr + self.destroy_addr = task_addr + get_long_pointer_size() + self.promise_addr = task_addr + get_long_pointer_size() * 2 + # In the example, the continuation is the first field member of the promise_type. + # So they have the same addresses. + # If we want to generalize the scripts to other coroutine types, we need to be sure + # the continuation field is the first memeber of promise_type. + self.continuation_addr = self.promise_addr + + def next_task_addr(self): + return dereference(self.continuation_addr) + + class CoroutineFrameDecorator(FrameDecorator): + def __init__(self, coro_frame): + super(CoroutineFrameDecorator, self).__init__(None) + self.coro_frame = coro_frame + self.resume_func = dereference(self.coro_frame.resume_addr) + self.resume_func_block = gdb.block_for_pc(self.resume_func) + if self.resume_func_block == None: + raise Exception('Not stackless coroutine.') + self.line_info = gdb.find_pc_line(self.resume_func) + + def address(self): + return self.resume_func + + def filename(self): + return self.line_info.symtab.filename + + def frame_args(self): + return [SymValueWrapper("frame_addr", cast_addr2long_pointer(self.coro_frame.frame_addr)), + SymValueWrapper("promise_addr", cast_addr2long_pointer(self.coro_frame.promise_addr)), + SymValueWrapper("continuation_addr", cast_addr2long_pointer(self.coro_frame.continuation_addr)) + ] + + def function(self): + return self.resume_func_block.function.print_name + + def line(self): + return self.line_info.line + + class StripDecorator(FrameDecorator): + def __init__(self, frame): + super(StripDecorator, self).__init__(frame) + self.frame = frame + f = frame.function() + self.function_name = f + + def __str__(self, shift = 2): + addr = "" if self.address() == None else '%#x' % self.address() + " in " + location = "" if self.filename() == None else " at " + self.filename() + ":" + str(self.line()) + return addr + self.function() + " " + str([str(args) for args in self.frame_args()]) + location + + class CoroutineFilter: + def create_coroutine_frames(self, task_addr): + frames = [] + while task_addr != 0: + coro_frame = CoroutineFrame(task_addr) + frames.append(CoroutineFrameDecorator(coro_frame)) + task_addr = coro_frame.next_task_addr() + return frames + + class AsyncStack(gdb.Command): + def __init__(self): + super(AsyncStack, self).__init__("async-bt", gdb.COMMAND_USER) + + def invoke(self, arg, from_tty): + coroutine_filter = CoroutineFilter() + argv = gdb.string_to_argv(arg) + if len(argv) == 0: + try: + task = gdb.parse_and_eval('__coro_frame') + task = int(str(task.address), 16) + except Exception: + print ("Can't find __coro_frame in current context.\n" + + "Please use `async-bt` in stackless coroutine context.") + return + elif len(argv) != 1: + print("usage: async-bt ") + return + else: + task = int(argv[0], 16) + + frames = coroutine_filter.create_coroutine_frames(task) + i = 0 + for f in frames: + print '#'+ str(i), str(StripDecorator(f)) + i += 1 + return + + AsyncStack() + + class ShowCoroFrame(gdb.Command): + def __init__(self): + super(ShowCoroFrame, self).__init__("show-coro-frame", gdb.COMMAND_USER) + + def invoke(self, arg, from_tty): + argv = gdb.string_to_argv(arg) + if len(argv) != 1: + print("usage: show-coro-frame
") + return + + addr = int(argv[0], 16) + block = gdb.block_for_pc(long(cast_addr2long_pointer(addr).dereference())) + if block == None: + print "block " + str(addr) + " is none." + return + + # Disable demangling since gdb will treat names starting with `_Z`(The marker for Itanium ABI) specially. + gdb.execute("set demangle-style none") + + coro_frame_type = gdb.lookup_type(block.function.linkage_name + ".coro_frame_ty") + coro_frame_ptr_type = coro_frame_type.pointer() + coro_frame = gdb.Value(addr).cast(coro_frame_ptr_type).dereference() + + gdb.execute("set demangle-style auto") + gdb.write(coro_frame.format_string(pretty_structs = True)) + + ShowCoroFrame() + +Then let's run: + +.. code-block:: text + + $ clang++ -std=c++20 -g debugging-example.cpp -o debugging-example + $ gdb ./debugging-example + (gdb) # We've alreay set the breakpoint. + (gdb) r + Program received signal SIGTRAP, Trace/breakpoint trap. + detail::chain_fn<0> () at debugging-example2.cpp:73 + 73 co_return 0; + (gdb) # Executes the debugging scripts + (gdb) source debugging-helper.py + (gdb) # Print the asynchronous stack + (gdb) async-bt + #0 0x401c40 in detail::chain_fn<0>() ['frame_addr = 0x441860', 'promise_addr = 0x441870', 'continuation_addr = 0x441870'] at debugging-example.cpp:71 + #1 0x4022d0 in detail::chain_fn<1>() ['frame_addr = 0x441810', 'promise_addr = 0x441820', 'continuation_addr = 0x441820'] at debugging-example.cpp:66 + #2 0x403060 in detail::chain_fn<2>() ['frame_addr = 0x4417c0', 'promise_addr = 0x4417d0', 'continuation_addr = 0x4417d0'] at debugging-example.cpp:66 + #3 0x403df0 in detail::chain_fn<3>() ['frame_addr = 0x441770', 'promise_addr = 0x441780', 'continuation_addr = 0x441780'] at debugging-example.cpp:66 + #4 0x404b80 in detail::chain_fn<4>() ['frame_addr = 0x441720', 'promise_addr = 0x441730', 'continuation_addr = 0x441730'] at debugging-example.cpp:66 + #5 0x405910 in detail::chain_fn<5>() ['frame_addr = 0x4416d0', 'promise_addr = 0x4416e0', 'continuation_addr = 0x4416e0'] at debugging-example.cpp:66 + #6 0x4066a0 in detail::chain_fn<6>() ['frame_addr = 0x441680', 'promise_addr = 0x441690', 'continuation_addr = 0x441690'] at debugging-example.cpp:66 + #7 0x407430 in detail::chain_fn<7>() ['frame_addr = 0x441630', 'promise_addr = 0x441640', 'continuation_addr = 0x441640'] at debugging-example.cpp:66 + #8 0x4081c0 in detail::chain_fn<8>() ['frame_addr = 0x4415e0', 'promise_addr = 0x4415f0', 'continuation_addr = 0x4415f0'] at debugging-example.cpp:66 + #9 0x408f50 in detail::chain_fn<9>() ['frame_addr = 0x441590', 'promise_addr = 0x4415a0', 'continuation_addr = 0x4415a0'] at debugging-example.cpp:66 + #10 0x409ce0 in detail::chain_fn<10>() ['frame_addr = 0x441540', 'promise_addr = 0x441550', 'continuation_addr = 0x441550'] at debugging-example.cpp:66 + #11 0x40aa70 in detail::chain_fn<11>() ['frame_addr = 0x4414f0', 'promise_addr = 0x441500', 'continuation_addr = 0x441500'] at debugging-example.cpp:66 + #12 0x40b800 in detail::chain_fn<12>() ['frame_addr = 0x4414a0', 'promise_addr = 0x4414b0', 'continuation_addr = 0x4414b0'] at debugging-example.cpp:66 + #13 0x40c590 in detail::chain_fn<13>() ['frame_addr = 0x441450', 'promise_addr = 0x441460', 'continuation_addr = 0x441460'] at debugging-example.cpp:66 + #14 0x40d320 in detail::chain_fn<14>() ['frame_addr = 0x441400', 'promise_addr = 0x441410', 'continuation_addr = 0x441410'] at debugging-example.cpp:66 + #15 0x40e0b0 in detail::chain_fn<15>() ['frame_addr = 0x4413b0', 'promise_addr = 0x4413c0', 'continuation_addr = 0x4413c0'] at debugging-example.cpp:66 + #16 0x40ee40 in detail::chain_fn<16>() ['frame_addr = 0x441360', 'promise_addr = 0x441370', 'continuation_addr = 0x441370'] at debugging-example.cpp:66 + #17 0x40fbd0 in detail::chain_fn<17>() ['frame_addr = 0x441310', 'promise_addr = 0x441320', 'continuation_addr = 0x441320'] at debugging-example.cpp:66 + #18 0x410960 in detail::chain_fn<18>() ['frame_addr = 0x4412c0', 'promise_addr = 0x4412d0', 'continuation_addr = 0x4412d0'] at debugging-example.cpp:66 + #19 0x4116f0 in detail::chain_fn<19>() ['frame_addr = 0x441270', 'promise_addr = 0x441280', 'continuation_addr = 0x441280'] at debugging-example.cpp:66 + #20 0x412480 in detail::chain_fn<20>() ['frame_addr = 0x441220', 'promise_addr = 0x441230', 'continuation_addr = 0x441230'] at debugging-example.cpp:66 + #21 0x413210 in detail::chain_fn<21>() ['frame_addr = 0x4411d0', 'promise_addr = 0x4411e0', 'continuation_addr = 0x4411e0'] at debugging-example.cpp:66 + #22 0x413fa0 in detail::chain_fn<22>() ['frame_addr = 0x441180', 'promise_addr = 0x441190', 'continuation_addr = 0x441190'] at debugging-example.cpp:66 + #23 0x414d30 in detail::chain_fn<23>() ['frame_addr = 0x441130', 'promise_addr = 0x441140', 'continuation_addr = 0x441140'] at debugging-example.cpp:66 + #24 0x415ac0 in detail::chain_fn<24>() ['frame_addr = 0x4410e0', 'promise_addr = 0x4410f0', 'continuation_addr = 0x4410f0'] at debugging-example.cpp:66 + #25 0x416850 in detail::chain_fn<25>() ['frame_addr = 0x441090', 'promise_addr = 0x4410a0', 'continuation_addr = 0x4410a0'] at debugging-example.cpp:66 + #26 0x4175e0 in detail::chain_fn<26>() ['frame_addr = 0x441040', 'promise_addr = 0x441050', 'continuation_addr = 0x441050'] at debugging-example.cpp:66 + #27 0x418370 in detail::chain_fn<27>() ['frame_addr = 0x440ff0', 'promise_addr = 0x441000', 'continuation_addr = 0x441000'] at debugging-example.cpp:66 + #28 0x419100 in detail::chain_fn<28>() ['frame_addr = 0x440fa0', 'promise_addr = 0x440fb0', 'continuation_addr = 0x440fb0'] at debugging-example.cpp:66 + #29 0x419e90 in detail::chain_fn<29>() ['frame_addr = 0x440f50', 'promise_addr = 0x440f60', 'continuation_addr = 0x440f60'] at debugging-example.cpp:66 + #30 0x41ac20 in detail::chain_fn<30>() ['frame_addr = 0x440f00', 'promise_addr = 0x440f10', 'continuation_addr = 0x440f10'] at debugging-example.cpp:66 + #31 0x41b9b0 in chain() ['frame_addr = 0x440eb0', 'promise_addr = 0x440ec0', 'continuation_addr = 0x440ec0'] at debugging-example.cpp:77 + +Now we get the complete asynchronous stack! +It is also possible to print other asynchronous stack which doesn't live in the top of the stack. +We can make it by passing the address of the corresponding coroutine frame to ``async-bt`` command. + +By the debugging scripts, we can print any coroutine frame too as long as we know the address. +For example, we can print the coroutine frame for ``detail::chain_fn<18>()`` in the above example. +From the log record, we know the address of the coroutine frame is ``0x4412c0`` in the run. Then we can: + +.. code-block:: text + + (gdb) show-coro-frame 0x4412c0 + { + __resume_fn = 0x410960 ()>, + __destroy_fn = 0x410d60 ()>, + __promise = { + continuation = { + _M_fr_ptr = 0x441270 + }, + result = 0 + }, + struct_Awaiter_0 = { + struct_std____n4861__coroutine_handle_0 = { + struct_std____n4861__coroutine_handle = { + PointerType = 0x441310 + } + } + }, + struct_task_1 = { + struct_std____n4861__coroutine_handle_0 = { + struct_std____n4861__coroutine_handle = { + PointerType = 0x0 + } + } + }, + struct_task__promise_type__FinalSuspend_2 = { + struct_std____n4861__coroutine_handle = { + PointerType = 0x0 + } + }, + __coro_index = 1 '\001', + struct_std____n4861__suspend_always_3 = { + __int_8 = 0 '\000' + } + + +Get the living coroutines +========================= + +Another useful task when debugging coroutines is to enumerate the list of +living coroutines, which is often done with threads. While technically +possible, this task is not recommended in production code as it is costly at +runtime. One such solution is to store the list of currently running coroutines +in a collection: + +.. code-block:: c++ + + inline std::unordered_set lived_coroutines; + // For all promise_type we want to record + class promise_type { + public: + promise_type() { + // Note to avoid data races + lived_coroutines.insert(std::coroutine_handle::from_promise(*this).address()); + } + ~promise_type() { + // Note to avoid data races + lived_coroutines.erase(std::coroutine_handle::from_promise(*this).address()); + } + }; + +In the above code snippet, we save the address of every lived coroutine in the +`lived_coroutines` `unordered_set`. As before, once we know the address of the +coroutine we can derive the function, `promise_type`, and other members of the +frame. Thus, we could print the list of lived coroutines from that collection. + +Please note that the above is expensive from a storage perspective, and requires +some level of locking (not pictured) on the collection to prevent data races. diff --git a/gnu/llvm/clang/docs/ExternalClangExamples.rst b/gnu/llvm/clang/docs/ExternalClangExamples.rst index 58c605a9a83..080114740dd 100644 --- a/gnu/llvm/clang/docs/ExternalClangExamples.rst +++ b/gnu/llvm/clang/docs/ExternalClangExamples.rst @@ -18,9 +18,9 @@ where Clang is used are: - Static analysis. - Documentation/cross-reference generation. -If you know of (or wrote!) a tool or project using Clang, please send an -email to Clang's `development discussion mailing list -`_ to have it added. +If you know of (or wrote!) a tool or project using Clang, please post on +`the Discourse forums (Clang Frontend category) +`_ to have it added. (or if you are already a Clang contributor, feel free to directly commit additions). Since the primary purpose of this page is to provide examples that can help developers, generally they must have code available. diff --git a/gnu/llvm/clang/docs/HLSL/EntryFunctions.rst b/gnu/llvm/clang/docs/HLSL/EntryFunctions.rst new file mode 100644 index 00000000000..518698b9b1f --- /dev/null +++ b/gnu/llvm/clang/docs/HLSL/EntryFunctions.rst @@ -0,0 +1,73 @@ +==================== +HLSL Entry Functions +==================== + +.. contents:: + :local: + +Usage +===== + +In HLSL, entry functions denote the starting point for shader execution. They +must be known at compile time. For all non-library shaders, the compiler assumes +the default entry function name ``main``, unless the DXC ``/E`` option is +provided to specify an alternate entry point. For library shaders entry points +are denoted using the ``[shader(...)]`` attribute. + +All scalar parameters to entry functions must have semantic annotations, and all +struct parameters must have semantic annotations on every field in the struct +declaration. Additionally if the entry function has a return type, a semantic +annotation must be provided for the return type as well. + +HLSL entry functions can be called from other parts of the shader, which has +implications on code generation. + +Implementation Details +====================== + +In Clang, the DXC ``/E`` option is translated to the cc1 flag ``-hlsl-entry``, +which in turn applies the ``HLSLShader`` attribute to the function with the +specified name. This allows code generation for entry functions to always key +off the presence of the ``HLSLShader`` attribute, regardless of what shader +profile you are compiling. + +In code generation, two functions are generated. One is the user defined +function, which is code generated as a mangled C++ function with internal +linkage following normal function code generation. + +The actual exported entry function which can be called by the GPU driver is a +``void(void)`` function that isn't name mangled. In code generation we generate +the unmangled entry function to serve as the actual shader entry. The shader +entry function is annotated with the ``hlsl.shader`` function attribute +identifying the entry's pipeline stage. + +The body of the unmangled entry function contains first a call to execute global +constructors, then instantiations of the user-defined entry parameters with +their semantic values populated, and a call to the user-defined function. +After the call instruction the return value (if any) is saved using a +target-appropriate intrinsic for storing outputs (for DirectX, the +``llvm.dx.store.output``). Lastly, any present global destructors will be called +immediately before the return. HLSL does not support C++ ``atexit`` +registrations, instead calls to global destructors are compile-time generated. + +.. note:: + + HLSL support in Clang is currently focused on compute shaders, which do not + support output semantics. Support for output semantics will not be + implemented until other shader profiles are supported. + +Below is example IR that represents the planned implementation, subject to +change as the ``llvm.dx.store.output`` and ``llvm.dx.load.input`` intrinsics are +not yet implemented. + +.. code-block:: none + + ; Function Attrs: norecurse + define void @main() #1 { + entry: + %0 = call i32 @llvm.dx.load.input.i32(...) + %1 = call i32 @"?main@@YAXII@Z"(i32 %0) + call @llvm.dx.store.output.i32(%1, ...) + ret void + } + diff --git a/gnu/llvm/clang/docs/HLSL/HLSLDocs.rst b/gnu/llvm/clang/docs/HLSL/HLSLDocs.rst new file mode 100644 index 00000000000..a02dd2e8a96 --- /dev/null +++ b/gnu/llvm/clang/docs/HLSL/HLSLDocs.rst @@ -0,0 +1,16 @@ +.. title:: Clang HLSL Documentation + +.. toctree:: + :maxdepth: 1 + + HLSLSupport + +HLSL Design and Implementation +============================== + +.. toctree:: + :maxdepth: 1 + + HLSLIRReference + ResourceTypes + EntryFunctions diff --git a/gnu/llvm/clang/docs/HLSL/HLSLIRReference.rst b/gnu/llvm/clang/docs/HLSL/HLSLIRReference.rst new file mode 100644 index 00000000000..c0d8d33f33b --- /dev/null +++ b/gnu/llvm/clang/docs/HLSL/HLSLIRReference.rst @@ -0,0 +1,31 @@ +================= +HLSL IR Reference +================= + +.. contents:: + :local: + +Introduction +============ + +The goal of this document is to provide a reference for all the special purpose +IR metadata and attributes used by the HLSL code generation path. + +IR Metadata +=========== + +``hlsl.uavs`` +------------- + +The ``hlsl.uavs`` metadata is a list of all the external global variables that +represent UAV resources. + +Function Attributes +=================== + +``hlsl.shader`` +--------------- + +The ``hlsl.shader`` function attribute is a string attribute applied to entry +functions. The value is the string representation of the shader stage (i.e. +``compute``, ``pixel``, etc). diff --git a/gnu/llvm/clang/docs/HLSL/HLSLSupport.rst b/gnu/llvm/clang/docs/HLSL/HLSLSupport.rst new file mode 100644 index 00000000000..b091c17fd2a --- /dev/null +++ b/gnu/llvm/clang/docs/HLSL/HLSLSupport.rst @@ -0,0 +1,249 @@ +============ +HLSL Support +============ + +.. contents:: + :local: + +Introduction +============ + +HLSL Support is under active development in the Clang codebase. This document +describes the high level goals of the project, the guiding principles, as well +as some idiosyncrasies of the HLSL language and how we intend to support them in +Clang. + +Project Goals +============= + +The long term goal of this project is to enable Clang to function as a +replacement for the `DirectXShaderCompiler (DXC) +`_ in all its supported +use cases. Accomplishing that goal will require Clang to be able to process most +existing HLSL programs with a high degree of source compatibility. + +Non-Goals +--------- + +HLSL ASTs do not need to be compatible between DXC and Clang. We do not expect +identical code generation or that features will resemble DXC's implementation or +architecture. In fact, we explicitly expect to deviate from DXC's implementation +in key ways. + +Guiding Principles +================== + +This document lacks details for architectural decisions that are not yet +finalized. Our top priorities are quality, maintainability, and flexibility. In +accordance with community standards we are expecting a high level of test +coverage, and we will engineer our solutions with long term maintenance in mind. +We are also working to limit modifications to the Clang C++ code paths and +share as much functionality as possible. + +Architectural Direction +======================= + +HLSL support in Clang is expressed as C++ minus unsupported C and C++ features. +This is different from how other Clang languages are implemented. Most languages +in Clang are additive on top of C. + +HLSL is not a formally or fully specified language, and while our goals require +a high level of source compatibility, implementations can vary and we have some +flexibility to be more or less permissive in some cases. For modern HLSL DXC is +the reference implementation. + +The HLSL effort prioritizes following similar patterns for other languages, +drivers, runtimes and targets. Specifically, We will maintain separation between +HSLS-specific code and the rest of Clang as much as possible following patterns +in use in Clang code today (i.e. ParseHLSL.cpp, SemaHLSL.cpp, CGHLSL*.cpp...). +We will use inline checks on language options where the code is simple and +isolated, and prefer HLSL-specific implementation files for any code of +reasonable complexity. + +In places where the HLSL language is in conflict with C and C++, we will seek to +make minimally invasive changes guarded under the HLSL language options. We will +seek to make HLSL language support as minimal a maintenance burden as possible. + +DXC Driver +---------- + +A DXC driver mode will provide command-line compatibility with DXC, supporting +DXC's options and flags. The DXC driver is HLSL-specific and will create an +HLSLToolchain which will provide the basis to support targeting both DirectX and +Vulkan. + +Parser +------ + +Following the examples of other parser extensions HLSL will add a ParseHLSL.cpp +file to contain the implementations of HLSL-specific extensions to the Clang +parser. The HLSL grammar shares most of its structure with C and C++, so we will +use the existing C/C++ parsing code paths. + +Sema +---- + +HLSL's Sema implementation will also provide an ``ExternalSemaSource``. In DXC, +an ``ExternalSemaSource`` is used to provide definitions for HLSL built-in data +types and built-in templates. Clang is already designed to allow an attached +``ExternalSemaSource`` to lazily complete data types, which is a **huge** +performance win for HLSL. + +If precompiled headers are used when compiling HLSL, the ``ExternalSemaSource`` +will be a ``MultiplexExternalSemaSource`` which includes both the ``ASTReader`` +and ``HLSLExternalSemaSource``. For Built-in declarations that are already +completed in the serialized AST, the ``HLSLExternalSemaSource`` will reuse the +existing declarations and not introduce new declarations. If the built-in types +are not completed in the serialized AST, the ``HLSLExternalSemaSource`` will +create new declarations and connect the de-serialized decls as the previous +declaration. + +CodeGen +------- + +Like OpenCL, HLSL relies on capturing a lot of information into IR metadata. +*hand wave* *hand wave* *hand wave* As a design principle here we want our IR to +be idiomatic Clang IR as much as possible. We will use IR attributes wherever we +can, and use metadata as sparingly as possible. One example of a difference from +DXC already implemented in Clang is the use of target triples to communicate +shader model versions and shader stages. + +Our HLSL CodeGen implementation should also have an eye toward generating IR +that will map directly to targets other than DXIL. While IR itself is generally +not re-targetable, we want to share the Clang CodeGen implementation for HLSL +with other GPU graphics targets like SPIR-V and possibly other GPU and even CPU +targets. + +HLSL Language +============= + +The HLSL language is insufficiently documented, and not formally specified. +Documentation is available on `Microsoft's website +`_. +The language syntax is similar enough to C and C++ that carefully written C and +C++ code is valid HLSL. HLSL has some key differences from C & C++ which we will +need to handle in Clang. + +HLSL is not a conforming or valid extension or superset of C or C++. The +language has key incompatibilities with C and C++, both syntactically and +semantically. + +An Aside on GPU Languages +------------------------- + +Due to HLSL being a GPU targeted language HLSL is a Single Program Multiple Data +(SPMD) language relying on the implicit parallelism provided by GPU hardware. +Some language features in HLSL enable programmers to take advantage of the +parallel nature of GPUs in a hardware abstracted language. + +HLSL also prohibits some features of C and C++ which can have catastrophic +performance or are not widely supportable on GPU hardware or drivers. As an +example, register spilling is often excessively expensive on GPUs, so HLSL +requires all functions to be inlined during code generation, and does not +support a runtime calling convention. + +Pointers & References +--------------------- + +HLSL does not support referring to values by address. Semantically all variables +are value-types and behave as such. HLSL disallows the pointer dereference +operators (unary ``*``, and ``->``), as well as the address of operator (unary +&). While HLSL disallows pointers and references in the syntax, HLSL does use +reference types in the AST, and we intend to use pointer decay in the AST in +the Clang implementation. + +HLSL ``this`` Keyword +--------------------- + +HLSL does support member functions, and (in HLSL 2021) limited operator +overloading. With member function support, HLSL also has a ``this`` keyword. The +``this`` keyword is an example of one of the places where HLSL relies on +references in the AST, because ``this`` is a reference. + +Bitshifts +--------- + +In deviation from C, HLSL bitshifts are defined to mask the shift count by the +size of the type. In DXC, the semantics of LLVM IR were altered to accommodate +this, in Clang we intend to generate the mask explicitly in the IR. In cases +where the shift value is constant, this will be constant folded appropriately, +in other cases we can clean it up in the DXIL target. + +Non-short Circuiting Logical Operators +-------------------------------------- + +In HLSL 2018 and earlier, HLSL supported logical operators (and the ternary +operator) on vector types. This behavior required that operators not short +circuit. The non-short circuiting behavior applies to all data types until HLSL +2021. In HLSL 2021, logical and ternary operators do not support vector types +instead builtin functions ``and``, ``or`` and ``select`` are available, and +operators short circuit matching C behavior. + +Precise Qualifier +----------------- + +HLSL has a ``precise`` qualifier that behaves unlike anything else in the C +language. The support for this qualifier in DXC is buggy, so our bar for +compatibility is low. + +The ``precise`` qualifier applies in the inverse direction from normal +qualifiers. Rather than signifying that the declaration containing ``precise`` +qualifier be precise, it signifies that the operations contributing to the +declaration's value be ``precise``. Additionally, ``precise`` is a misnomer: +values attributed as ``precise`` comply with IEEE-754 floating point semantics, +and are prevented from optimizations which could decrease *or increase* +precision. + +Differences in Templates +------------------------ + +HLSL uses templates to define builtin types and methods, but disallowed +user-defined templates until HLSL 2021. HLSL also allows omitting empty template +parameter lists when all template parameters are defaulted. This is an ambiguous +syntax in C++, but Clang detects the case and issues a diagnostic. This makes +supporting the case in Clang minimally invasive. + +Vector Extensions +----------------- + +HLSL uses the OpenCL vector extensions, and also provides C++-style constructors +for vectors that are not supported by Clang. + +Standard Library +---------------- + +HLSL does not support the C or C++ standard libraries. Like OpenCL, HLSL +describes its own library of built in types, complex data types, and functions. + +Unsupported C & C++ Features +---------------------------- + +HLSL does not support all features of C and C++. In implementing HLSL in Clang +use of some C and C++ features will produce diagnostics under HLSL, and others +will be supported as language extensions. In general, any C or C++ feature that +can be supported by the DXIL and SPIR-V code generation targets could be treated +as a clang HLSL extension. Features that cannot be lowered to DXIL or SPIR-V, +must be diagnosed as errors. + +HLSL does not support the following C features: + +* Pointers +* References +* ``goto`` or labels +* Variable Length Arrays +* ``_Complex`` and ``_Imaginary`` +* C Threads or Atomics (or Obj-C blocks) +* ``union`` types `(in progress for HLSL 202x) `_ +* Most features C11 and later + +HLSL does not support the following C++ features: + +* RTTI +* Exceptions +* Multiple inheritance +* Access specifiers +* Anonymous or inline namespaces +* ``new`` & ``delete`` operators in all of their forms (array, placement, etc) +* Constructors and destructors +* Any use of the ``virtual`` keyword +* Most features C++11 and later diff --git a/gnu/llvm/clang/docs/HLSL/ResourceTypes.rst b/gnu/llvm/clang/docs/HLSL/ResourceTypes.rst new file mode 100644 index 00000000000..aad7b3314f0 --- /dev/null +++ b/gnu/llvm/clang/docs/HLSL/ResourceTypes.rst @@ -0,0 +1,34 @@ +=================== +HLSL Resource Types +=================== + +.. contents:: + :local: + +Introduction +============ + +HLSL Resources are runtime-bound data that is provided as input, output or both +to shader programs written in HLSL. Resource Types in HLSL provide key user +abstractions for reading and writing resource data. + +Implementation Details +====================== + +In Clang resource types are forward declared by the ``HLSLExternalSemaSource`` +on initialization. They are then lazily completed when ``requiresCompleteType`` +is called later in Sema. + +Resource types are templated class declarations. The template parameter +specifies the expected return type of resource loads, and the expected parameter +type for stores. + +In Clang's AST and code generation, resource types are classes that store a +pointer of the template parameter type. The pointer is populated from a call to +``__builtin_hlsl_create_handle``, and treated as a pointer to an array of typed +data through until lowering in the backend. + +Resource types are annotated with the ``HLSLResource`` attribute, which drives +code generation for resource binding metadata. The ``hlsl`` metadata nodes are +transformed in the backend to the binding information expected by the target +runtime. diff --git a/gnu/llvm/clang/docs/HowToSetupToolingForLLVM.rst b/gnu/llvm/clang/docs/HowToSetupToolingForLLVM.rst index cbe15abaab3..62189511aeb 100644 --- a/gnu/llvm/clang/docs/HowToSetupToolingForLLVM.rst +++ b/gnu/llvm/clang/docs/HowToSetupToolingForLLVM.rst @@ -53,6 +53,54 @@ Now you are ready to build and test LLVM using make: $ make check-all +Setup Clang Tooling Using CMake on Windows +========================================== + +For Windows developers, the Visual Studio project generators in CMake do +not support `CMAKE_EXPORT_COMPILE_COMMANDS +`_. +However, the Ninja generator does support this variable and can be used +on Windows to generate a suitable ``compile_commands.json`` that invokes +the MSVC compiler. + +First, you will need to install `Ninja`_. Once installed, the Ninja +executable will need to be in your search path for CMake to locate it. + +Next, assuming you already have Visual Studio installed on your machine, you +need to have the appropriate environment variables configured so that CMake +will locate the MSVC compiler for the Ninja generator. The `documentation +`_ +describes the necessary environment variable settings, but the simplest thing +is to use a `developer command-prompt window +`_ +or call a `developer command file +`_ +to set the environment variables appropriately. + +Now you can run CMake with the Ninja generator to export a compilation +database: + +.. code-block:: console + + C:\> mkdir build-ninja + C:\> cd build-ninja + C:\build-ninja> cmake -G Ninja -DCMAKE_EXPORT_COMPILE_COMMANDS=ON path/to/llvm/sources + +It is best to keep your Visual Studio IDE build folder separate from the +Ninja build folder. This prevents the two build systems from negatively +interacting with each other. + +Once the ``compile_commands.json`` file has been created by Ninja, you can +use that compilation database with Clang Tooling. One caveat is that because +there are indirect settings obtained through the environment variables, +you may need to run any Clang Tooling executables through a command prompt +window created for use with Visual Studio as described above. An +alternative, e.g. for using the Visual Studio debugger on a Clang Tooling +executable, is to ensure that the environment variables are also visible +to the debugger settings. This can be done locally in Visual Studio's +debugger configuration locally or globally by launching the Visual Studio +IDE from a suitable command-prompt window. + Using Clang Tools ================= @@ -143,9 +191,9 @@ Examples: Using Ninja Build System ======================================= -Optionally you can use the `Ninja `_ -build system instead of make. It is aimed at making your builds faster. -Currently this step will require building Ninja from sources. +Optionally you can use the `Ninja`_ build system instead of make. It is +aimed at making your builds faster. Currently this step will require +building Ninja from sources. To take advantage of using Clang Tools along with Ninja build you need at least CMake 2.8.9. @@ -197,3 +245,5 @@ Now you are ready to build and test LLVM using Ninja: $ ninja check-all Other target names can be used in the same way as with make. + +.. _Ninja: https://ninja-build.org/ diff --git a/gnu/llvm/clang/docs/InternalsManual.rst b/gnu/llvm/clang/docs/InternalsManual.rst index ddc873c253e..a20fe623a5c 100644 --- a/gnu/llvm/clang/docs/InternalsManual.rst +++ b/gnu/llvm/clang/docs/InternalsManual.rst @@ -192,13 +192,18 @@ This gives the ``DiagnosticConsumer`` information about what the argument means without requiring it to use a specific presentation (consider this MVC for Clang :). +It is really easy to add format specifiers to the Clang diagnostics system, but +they should be discussed before they are added. If you are creating a lot of +repetitive diagnostics and/or have an idea for a useful formatter, please bring +it up on the cfe-dev mailing list. + Here are the different diagnostic argument formats currently supported by Clang: **"s" format** Example: - ``"requires %1 parameter%s1"`` + ``"requires %0 parameter%s0"`` Class: Integers Description: @@ -206,12 +211,15 @@ Description: diagnostics. When the integer is 1, it prints as nothing. When the integer is not 1, it prints as "``s``". This allows some simple grammatical forms to be to be handled correctly, and eliminates the need to use gross things like - ``"requires %1 parameter(s)"``. + ``"requires %1 parameter(s)"``. Note, this only handles adding a simple + "``s``" character, it will not handle situations where pluralization is more + complicated such as turning ``fancy`` into ``fancies`` or ``mouse`` into + ``mice``. You can use the "plural" format specifier to handle such situations. **"select" format** Example: - ``"must be a %select{unary|binary|unary or binary}2 operator"`` + ``"must be a %select{unary|binary|unary or binary}0 operator"`` Class: Integers Description: @@ -219,7 +227,7 @@ Description: into one common one, without requiring the difference to be specified as an English string argument. Instead of specifying the string, the diagnostic gets an integer argument and the format string selects the numbered option. - In this case, the "``%2``" value must be an integer in the range [0..2]. If + In this case, the "``%0``" value must be an integer in the range [0..2]. If it is 0, it prints "unary", if it is 1 it prints "binary" if it is 2, it prints "unary or binary". This allows other language translations to substitute reasonable words (or entire phrases) based on the semantics of the @@ -229,11 +237,11 @@ Description: **"plural" format** Example: - ``"you have %1 %plural{1:mouse|:mice}1 connected to your computer"`` + ``"you have %0 %plural{1:mouse|:mice}0 connected to your computer"`` Class: Integers Description: - This is a formatter for complex plural forms. It is designed to handle even + This is a formatter for complex plural forms. It is designed to handle even the requirements of languages with very complex plural forms, as many Baltic languages have. The argument consists of a series of expression/form pairs, separated by ":", where the first form whose expression evaluates to true is @@ -245,10 +253,10 @@ Description: numeric condition can take one of three forms. * number: A simple decimal number matches if the argument is the same as the - number. Example: ``"%plural{1:mouse|:mice}4"`` + number. Example: ``"%plural{1:mouse|:mice}0"`` * range: A range in square brackets matches if the argument is within the range. Then range is inclusive on both ends. Example: - ``"%plural{0:none|1:one|[2,5]:some|:many}2"`` + ``"%plural{0:none|1:one|[2,5]:some|:many}0"`` * modulo: A modulo operator is followed by a number, and equals sign and either a number or a range. The tests are the same as for plain numbers and ranges, but the argument is taken modulo the number first. Example: @@ -314,11 +322,6 @@ Description: If tree printing is on, the text after the pipe is printed and a type tree is printed after the diagnostic message. -It is really easy to add format specifiers to the Clang diagnostics system, but -they should be discussed before they are added. If you are creating a lot of -repetitive diagnostics and/or have an idea for a useful formatter, please bring -it up on the cfe-dev mailing list. - **"sub" format** Example: @@ -537,7 +540,7 @@ token. This concept maps directly to the "spelling location" for the token. ``SourceRange`` and ``CharSourceRange`` --------------------------------------- -.. mostly taken from https://lists.llvm.org/pipermail/cfe-dev/2010-August/010595.html +.. mostly taken from https://discourse.llvm.org/t/code-ranges-of-tokens-ast-elements/16893/2 Clang represents most source ranges by [first, last], where "first" and "last" each point to the beginning of their respective tokens. For example consider @@ -685,7 +688,7 @@ use them to construct the ``-cc1`` job: void Clang::ConstructJob(const ArgList &Args /*...*/) const { ArgStringList CmdArgs; - // ... + // ... + for (const Arg *A : Args.filtered(OPT_fpass_plugin_EQ)) { + CmdArgs.push_back(Args.MakeArgString(Twine("-fpass-plugin=") + A->getValue())); @@ -2883,7 +2886,7 @@ are created implicitly. The following spellings are accepted: Subjects ~~~~~~~~ -Attributes appertain to one or more subjects. If the attribute attempts to +Attributes appertain to one or more subjects. If the attribute attempts to attach to a subject that is not in the subject list, a diagnostic is issued automatically. Whether the diagnostic is a warning or an error depends on how the attribute's ``SubjectList`` is defined, but the default behavior is to warn. @@ -2914,13 +2917,13 @@ Documentation All attributes must have some form of documentation associated with them. Documentation is table generated on the public web server by a server-side process that runs daily. Generally, the documentation for an attribute is a -stand-alone definition in `include/clang/Basic/AttrDocs.td +stand-alone definition in `include/clang/Basic/AttrDocs.td `_ that is named after the attribute being documented. If the attribute is not for public consumption, or is an implicitly-created attribute that has no visible spelling, the documentation list can specify the -``Undocumented`` object. Otherwise, the attribute should have its documentation +``InternalOnly`` object. Otherwise, the attribute should have its documentation added to AttrDocs.td. Documentation derives from the ``Documentation`` tablegen type. All derived @@ -2932,7 +2935,7 @@ There are four predefined documentation categories: ``DocCatFunction`` for attributes that appertain to function-like subjects, ``DocCatVariable`` for attributes that appertain to variable-like subjects, ``DocCatType`` for type attributes, and ``DocCatStmt`` for statement attributes. A custom documentation -category should be used for groups of attributes with similar functionality. +category should be used for groups of attributes with similar functionality. Custom categories are good for providing overview information for the attributes grouped under it. For instance, the consumed annotation attributes define a custom category, ``DocCatConsumed``, that explains what consumed annotations are @@ -3265,4 +3268,3 @@ are similar. proper visitation for your expression, enabling various IDE features such as syntax highlighting, cross-referencing, and so on. The ``c-index-test`` helper program can be used to test these features. - diff --git a/gnu/llvm/clang/docs/IntroductionToTheClangAST.rst b/gnu/llvm/clang/docs/IntroductionToTheClangAST.rst index 286ab88d01e..6fbb8f1d644 100644 --- a/gnu/llvm/clang/docs/IntroductionToTheClangAST.rst +++ b/gnu/llvm/clang/docs/IntroductionToTheClangAST.rst @@ -32,7 +32,7 @@ clang ParenExpr). Examining the AST ================= -A good way to familarize yourself with the Clang AST is to actually look +A good way to familiarize yourself with the Clang AST is to actually look at it on some simple example code. Clang has a builtin AST-dump mode, which can be enabled with the flag ``-ast-dump``. diff --git a/gnu/llvm/clang/docs/JSONCompilationDatabase.rst b/gnu/llvm/clang/docs/JSONCompilationDatabase.rst index bd91db25839..0227f0bfe3e 100644 --- a/gnu/llvm/clang/docs/JSONCompilationDatabase.rst +++ b/gnu/llvm/clang/docs/JSONCompilationDatabase.rst @@ -29,6 +29,10 @@ system is not necessarily the best solution: Supported Systems ================= +Clang has the ability to generate compilation database fragments via +``-MJ argument >``. You can concatenate those +fragments together between ``[`` and ``]`` to create a compilation database. + Currently `CMake `_ (since 2.8.5) supports generation of compilation databases for Unix Makefile builds (Ninja builds in the works) with the option ``CMAKE_EXPORT_COMPILE_COMMANDS``. @@ -36,6 +40,12 @@ works) with the option ``CMAKE_EXPORT_COMPILE_COMMANDS``. For projects on Linux, there is an alternative to intercept compiler calls with a tool called `Bear `_. +`Bazel `_ can export a compilation database via +`this extractor extension +`_. +Bazel is otherwise resistant to Bear and other compiler-intercept +techniques. + Clang's tooling interface supports reading compilation databases; see the :doc:`LibTooling documentation `. libclang and its python bindings also support this (since clang 3.2); see @@ -57,8 +67,13 @@ Example: [ { "directory": "/home/user/llvm/build", - "command": "/usr/bin/clang++ -Irelative -DSOMEDEF=\"With spaces, quotes and \\-es.\" -c -o file.o file.cc", + "arguments": ["/usr/bin/clang++", "-Irelative", "-DSOMEDEF=With spaces, quotes and \\-es.", "-c", "-o", "file.o", "file.cc"], "file": "file.cc" }, + + { "directory": "/home/user/llvm/build", + "command": "/usr/bin/clang++ -Irelative -DSOMEDEF=\"With spaces, quotes and \\-es.\" -c -o file.o file.cc", + "file": "file2.cc" }, + ... ] @@ -72,14 +87,17 @@ The contracts for each field in the command object are: compilation database. There can be multiple command objects for the same file, for example if the same source file is compiled with different configurations. -- **command:** The compile command executed. After JSON unescaping, - this must be a valid command to rerun the exact compilation step for - the translation unit in the environment the build system uses. - Parameters use shell quoting and shell escaping of quotes, with '``"``' - and '``\``' being the only special characters. Shell expansion is not - supported. -- **arguments:** The compile command executed as list of strings. - Either **arguments** or **command** is required. +- **arguments:** The compile command argv as list of strings. + This should run the compilation step for the translation unit ``file``. + ``arguments[0]`` should be the executable name, such as ``clang++``. + Arguments should not be escaped, but ready to pass to ``execvp()``. +- **command:** The compile command as a single shell-escaped string. + Arguments may be shell quoted and escaped following platform conventions, + with '``"``' and '``\``' being the only special characters. Shell expansion + is not supported. + + Either **arguments** or **command** is required. **arguments** is preferred, + as shell (un)escaping is a possible source of errors. - **output:** The name of the output created by this compilation step. This field is optional. It can be used to distinguish different processing modes of the same input file. diff --git a/gnu/llvm/clang/docs/LTOVisibility.rst b/gnu/llvm/clang/docs/LTOVisibility.rst index cdc0b9cc0e1..ebc4cc906aa 100644 --- a/gnu/llvm/clang/docs/LTOVisibility.rst +++ b/gnu/llvm/clang/docs/LTOVisibility.rst @@ -35,13 +35,14 @@ other classes receive hidden LTO visibility. Classes with internal linkage (e.g. classes declared in unnamed namespaces) also receive hidden LTO visibility. -During the LTO link, all classes with public LTO visibility will be refined -to hidden LTO visibility when the ``--lto-whole-program-visibility`` lld linker -option is applied (``-plugin-opt=whole-program-visibility`` for gold). This flag -can be used to defer specifying whether classes have hidden LTO visibility until -link time, to allow bitcode objects to be shared by different LTO links. -Due to an implementation limitation, symbols associated with classes with hidden -LTO visibility may still be exported from the binary when using this flag. It is +During the LTO link, all classes with public LTO visibility but not marked with +``[[clang::lto_visibility_public]]`` (see below) will be refined to hidden LTO +visibility when the ``--lto-whole-program-visibility`` lld linker option is +applied (``-plugin-opt=whole-program-visibility`` for gold). This flag can be +used to defer specifying whether classes have hidden LTO visibility until link +time, to allow bitcode objects to be shared by different LTO links. Due to an +implementation limitation, symbols associated with classes with hidden LTO +visibility may still be exported from the binary when using this flag. It is unsafe to refer to these symbols, and their visibility may be relaxed to hidden in a future compiler release. diff --git a/gnu/llvm/clang/docs/LanguageExtensions.rst b/gnu/llvm/clang/docs/LanguageExtensions.rst index f14f986c646..e5df4d52433 100644 --- a/gnu/llvm/clang/docs/LanguageExtensions.rst +++ b/gnu/llvm/clang/docs/LanguageExtensions.rst @@ -66,6 +66,35 @@ It can be used like this: ``__has_builtin`` should not be used to detect support for a builtin macro; use ``#ifdef`` instead. +``__has_constexpr_builtin`` +--------------------------- + +This function-like macro takes a single identifier argument that is the name of +a builtin function, a builtin pseudo-function (taking one or more type +arguments), or a builtin template. +It evaluates to 1 if the builtin is supported and can be constant evaluated or +0 if not. It can be used for writing conditionally constexpr code like this: + +.. code-block:: c++ + + #ifndef __has_constexpr_builtin // Optional of course. + #define __has_constexpr_builtin(x) 0 // Compatibility with non-clang compilers. + #endif + + ... + #if __has_constexpr_builtin(__builtin_fmax) + constexpr + #endif + double money_fee(double amount) { + return __builtin_fmax(amount * 0.03, 10.0); + } + ... + +For example, ``__has_constexpr_builtin`` is used in libcxx's implementation of +the ```` header file to conditionally make a function constexpr whenever +the constant evaluation of the corresponding builtin (for example, +``std::fmax`` calls ``__builtin_fmax``) is supported in Clang. + .. _langext-__has_feature-__has_extension: ``__has_feature`` and ``__has_extension`` @@ -400,7 +429,7 @@ Builtin Macros Vectors and Extended Vectors ============================ -Supports the GCC, OpenCL, AltiVec and NEON vector extensions. +Supports the GCC, OpenCL, AltiVec, NEON and SVE vector extensions. OpenCL vector types are created using the ``ext_vector_type`` attribute. It supports the ``V.xyzw`` syntax and other tidbits as seen in OpenCL. An example @@ -445,6 +474,67 @@ NEON vector types are created using ``neon_vector_type`` and return v; } +GCC vector types are created using the ``vector_size(N)`` attribute. The +argument ``N`` specifies the number of bytes that will be allocated for an +object of this type. The size has to be multiple of the size of the vector +element type. For example: + +.. code-block:: c++ + + // OK: This declares a vector type with four 'int' elements + typedef int int4 __attribute__((vector_size(4 * sizeof(int)))); + + // ERROR: '11' is not a multiple of sizeof(int) + typedef int int_impossible __attribute__((vector_size(11))); + + int4 foo(int4 a) { + int4 v; + v = a; + return v; + } + + +Boolean Vectors +--------------- + +Clang also supports the ext_vector_type attribute with boolean element types in +C and C++. For example: + +.. code-block:: c++ + + // legal for Clang, error for GCC: + typedef bool bool4 __attribute__((ext_vector_type(4))); + // Objects of bool4 type hold 8 bits, sizeof(bool4) == 1 + + bool4 foo(bool4 a) { + bool4 v; + v = a; + return v; + } + +Boolean vectors are a Clang extension of the ext vector type. Boolean vectors +are intended, though not guaranteed, to map to vector mask registers. The size +parameter of a boolean vector type is the number of bits in the vector. The +boolean vector is dense and each bit in the boolean vector is one vector +element. + +The semantics of boolean vectors borrows from C bit-fields with the following +differences: + +* Distinct boolean vectors are always distinct memory objects (there is no + packing). +* Only the operators `?:`, `!`, `~`, `|`, `&`, `^` and comparison are allowed on + boolean vectors. +* Casting a scalar bool value to a boolean vector type means broadcasting the + scalar value onto all lanes (same as general ext_vector_type). +* It is not possible to access or swizzle elements of a boolean vector + (different than general ext_vector_type). + +The size and alignment are both the number of bits rounded up to the next power +of two, but the alignment is at most the maximum vector alignment of the +target. + + Vector Literals --------------- @@ -478,33 +568,126 @@ The table below shows the support for each operation by vector extension. A dash indicates that an operation is not accepted according to a corresponding specification. -============================== ======= ======= ============= ======= - Operator OpenCL AltiVec GCC NEON -============================== ======= ======= ============= ======= -[] yes yes yes -- -unary operators +, -- yes yes yes -- -++, -- -- yes yes yes -- -+,--,*,/,% yes yes yes -- -bitwise operators &,|,^,~ yes yes yes -- ->>,<< yes yes yes -- -!, &&, || yes -- yes -- -==, !=, >, <, >=, <= yes yes yes -- -= yes yes yes yes -?: [#]_ yes -- yes -- -sizeof yes yes yes yes -C-style cast yes yes yes no -reinterpret_cast yes no yes no -static_cast yes no yes no -const_cast no no no no -============================== ======= ======= ============= ======= +============================== ======= ======= ============= ======= ===== + Operator OpenCL AltiVec GCC NEON SVE +============================== ======= ======= ============= ======= ===== +[] yes yes yes yes yes +unary operators +, -- yes yes yes yes yes +++, -- -- yes yes yes no no ++,--,*,/,% yes yes yes yes yes +bitwise operators &,|,^,~ yes yes yes yes yes +>>,<< yes yes yes yes yes +!, &&, || yes -- yes yes yes +==, !=, >, <, >=, <= yes yes yes yes yes += yes yes yes yes yes +?: [#]_ yes -- yes yes yes +sizeof yes yes yes yes yes [#]_ +C-style cast yes yes yes no no +reinterpret_cast yes no yes no no +static_cast yes no yes no no +const_cast no no no no no +address &v[i] no no no [#]_ no no +============================== ======= ======= ============= ======= ===== See also :ref:`langext-__builtin_shufflevector`, :ref:`langext-__builtin_convertvector`. .. [#] ternary operator(?:) has different behaviors depending on condition operand's vector type. If the condition is a GNU vector (i.e. __vector_size__), - it's only available in C++ and uses normal bool conversions (that is, != 0). + a NEON vector or an SVE vector, it's only available in C++ and uses normal bool + conversions (that is, != 0). If it's an extension (OpenCL) vector, it's only available in C and OpenCL C. And it selects base on signedness of the condition operands (OpenCL v1.1 s6.3.9). +.. [#] sizeof can only be used on vector length specific SVE types. +.. [#] Clang does not allow the address of an element to be taken while GCC + allows this. This is intentional for vectors with a boolean element type and + not implemented otherwise. + +Vector Builtins +--------------- + +**Note: The implementation of vector builtins is work-in-progress and incomplete.** + +In addition to the operators mentioned above, Clang provides a set of builtins +to perform additional operations on certain scalar and vector types. + +Let ``T`` be one of the following types: + +* an integer type (as in C2x 6.2.5p19), but excluding enumerated types and _Bool +* the standard floating types float or double +* a half-precision floating point type, if one is supported on the target +* a vector type. + +For scalar types, consider the operation applied to a vector with a single element. + +*Elementwise Builtins* + +Each builtin returns a vector equivalent to applying the specified operation +elementwise to the input. + +Unless specified otherwise operation(±0) = ±0 and operation(±infinity) = ±infinity + +=========================================== ================================================================ ========================================= + Name Operation Supported element types +=========================================== ================================================================ ========================================= + T __builtin_elementwise_abs(T x) return the absolute value of a number x; the absolute value of signed integer and floating point types + the most negative integer remains the most negative integer + T __builtin_elementwise_ceil(T x) return the smallest integral value greater than or equal to x floating point types + T __builtin_elementwise_sin(T x) return the sine of x interpreted as an angle in radians floating point types + T __builtin_elementwise_cos(T x) return the cosine of x interpreted as an angle in radians floating point types + T __builtin_elementwise_floor(T x) return the largest integral value less than or equal to x floating point types + T __builtin_elementwise_roundeven(T x) round x to the nearest integer value in floating point format, floating point types + rounding halfway cases to even (that is, to the nearest value + that is an even integer), regardless of the current rounding + direction. + T __builtin_elementwise_trunc(T x) return the integral value nearest to but no larger in floating point types + magnitude than x + T __builtin_elementwise_canonicalize(T x) return the platform specific canonical encoding floating point types + of a floating-point number + T __builtin_elementwise_copysign(T x, T y) return the magnitude of x with the sign of y. floating point types + T __builtin_elementwise_max(T x, T y) return x or y, whichever is larger integer and floating point types + T __builtin_elementwise_min(T x, T y) return x or y, whichever is smaller integer and floating point types + T __builtin_elementwise_add_sat(T x, T y) return the sum of x and y, clamped to the range of integer types + representable values for the signed/unsigned integer type. + T __builtin_elementwise_sub_sat(T x, T y) return the difference of x and y, clamped to the range of integer types + representable values for the signed/unsigned integer type. +=========================================== ================================================================ ========================================= + + +*Reduction Builtins* + +Each builtin returns a scalar equivalent to applying the specified +operation(x, y) as recursive even-odd pairwise reduction to all vector +elements. ``operation(x, y)`` is repeatedly applied to each non-overlapping +even-odd element pair with indices ``i * 2`` and ``i * 2 + 1`` with +``i in [0, Number of elements / 2)``. If the numbers of elements is not a +power of 2, the vector is widened with neutral elements for the reduction +at the end to the next power of 2. + +Example: + +.. code-block:: c++ + + __builtin_reduce_add([e3, e2, e1, e0]) = __builtin_reduced_add([e3 + e2, e1 + e0]) + = (e3 + e2) + (e1 + e0) + + +Let ``VT`` be a vector type and ``ET`` the element type of ``VT``. + +======================================= ================================================================ ================================== + Name Operation Supported element types +======================================= ================================================================ ================================== + ET __builtin_reduce_max(VT a) return x or y, whichever is larger; If exactly one argument is integer and floating point types + a NaN, return the other argument. If both arguments are NaNs, + fmax() return a NaN. + ET __builtin_reduce_min(VT a) return x or y, whichever is smaller; If exactly one argument integer and floating point types + is a NaN, return the other argument. If both arguments are + NaNs, fmax() return a NaN. + ET __builtin_reduce_add(VT a) \+ integer types + ET __builtin_reduce_mul(VT a) \* integer types + ET __builtin_reduce_and(VT a) & integer types + ET __builtin_reduce_or(VT a) \| integer types + ET __builtin_reduce_xor(VT a) ^ integer types +======================================= ================================================================ ================================== Matrix Types ============ @@ -596,19 +779,33 @@ targets pending ABI standardization: * 64-bit ARM (AArch64) * AMDGPU * SPIR +* X86 (see below) + +On X86 targets, ``_Float16`` is supported as long as SSE2 is available, which +includes all 64-bit and all recent 32-bit processors. When the target supports +AVX512-FP16, ``_Float16`` arithmetic is performed using that native support. +Otherwise, ``_Float16`` arithmetic is performed by promoting to ``float``, +performing the operation, and then truncating to ``_Float16``. When doing this +emulation, Clang defaults to following the C standard's rules for excess +precision arithmetic, which avoids intermediate truncations within statements +and may generate different results from a strict operation-by-operation +emulation. ``_Float16`` will be supported on more targets as they define ABIs for it. ``__bf16`` is purely a storage format; it is currently only supported on the following targets: + * 32-bit ARM * 64-bit ARM (AArch64) +* X86 (see below) -The ``__bf16`` type is only available when supported in hardware. +On X86 targets, ``__bf16`` is supported as long as SSE2 is available, which +includes all 64-bit and all recent 32-bit processors. ``__fp16`` is a storage and interchange format only. This means that values of ``__fp16`` are immediately promoted to (at least) ``float`` when used in arithmetic operations, so that e.g. the result of adding two ``__fp16`` values has type ``float``. -The behavior of ``__fp16`` is specified by the ARM C Language Extensions (`ACLE `_). +The behavior of ``__fp16`` is specified by the Arm C Language Extensions (`ACLE `_). Clang uses the ``binary16`` format from IEEE 754-2008 for ``__fp16``, not the ARM alternative format. @@ -1215,7 +1412,7 @@ The following type trait primitives are supported by Clang. Those traits marked * ``__has_trivial_move_assign`` (GNU, Microsoft): Deprecated, use ``__is_trivially_assignable`` instead. * ``__has_trivial_copy`` (GNU, Microsoft): - Deprecated, use ``__is_trivially_constructible`` instead. + Deprecated, use ``__is_trivially_copyable`` instead. * ``__has_trivial_constructor`` (GNU, Microsoft): Deprecated, use ``__is_trivially_constructible`` instead. * ``__has_trivial_move_constructor`` (GNU, Microsoft): @@ -1230,6 +1427,7 @@ The following type trait primitives are supported by Clang. Those traits marked * ``__is_array`` (C++, Embarcadero) * ``__is_assignable`` (C++, MSVC 2015) * ``__is_base_of`` (C++, GNU, Microsoft, Embarcadero) +* ``__is_bounded_array`` (C++, GNU, Microsoft, Embarcadero) * ``__is_class`` (C++, GNU, Microsoft, Embarcadero) * ``__is_complete_type(type)`` (Embarcadero): Return ``true`` if ``type`` is a complete type. @@ -1241,8 +1439,7 @@ The following type trait primitives are supported by Clang. Those traits marked * ``__is_convertible`` (C++, Embarcadero) * ``__is_convertible_to`` (Microsoft): Synonym for ``__is_convertible``. -* ``__is_destructible`` (C++, MSVC 2013): - Only available in ``-fms-extensions`` mode. +* ``__is_destructible`` (C++, MSVC 2013) * ``__is_empty`` (C++, GNU, Microsoft, Embarcadero) * ``__is_enum`` (C++, GNU, Microsoft, Embarcadero) * ``__is_final`` (C++, GNU, Microsoft) @@ -1264,17 +1461,25 @@ The following type trait primitives are supported by Clang. Those traits marked * ``__is_nothrow_assignable`` (C++, MSVC 2013) * ``__is_nothrow_constructible`` (C++, MSVC 2013) * ``__is_nothrow_destructible`` (C++, MSVC 2013) - Only available in ``-fms-extensions`` mode. +* ``__is_nullptr`` (C++, GNU, Microsoft, Embarcadero): + Returns true for ``std::nullptr_t`` and false for everything else. The + corresponding standard library feature is ``std::is_null_pointer``, but + ``__is_null_pointer`` is already in use by some implementations. * ``__is_object`` (C++, Embarcadero) * ``__is_pod`` (C++, GNU, Microsoft, Embarcadero): Note, the corresponding standard trait was deprecated in C++20. * ``__is_pointer`` (C++, Embarcadero) * ``__is_polymorphic`` (C++, GNU, Microsoft, Embarcadero) * ``__is_reference`` (C++, Embarcadero) +* ``__is_referenceable`` (C++, GNU, Microsoft, Embarcadero): + Returns true if a type is referenceable, and false otherwise. A referenceable + type is a type that's either an object type, a reference type, or an unqualified + function type. * ``__is_rvalue_reference`` (C++, Embarcadero) * ``__is_same`` (C++, Embarcadero) * ``__is_same_as`` (GCC): Synonym for ``__is_same``. * ``__is_scalar`` (C++, Embarcadero) +* ``__is_scoped_enum`` (C++, GNU, Microsoft, Embarcadero) * ``__is_sealed`` (Microsoft): Synonym for ``__is_final``. * ``__is_signed`` (C++, Embarcadero): @@ -1287,6 +1492,12 @@ The following type trait primitives are supported by Clang. Those traits marked * ``__is_trivially_constructible`` (C++, GNU, Microsoft) * ``__is_trivially_copyable`` (C++, GNU, Microsoft) * ``__is_trivially_destructible`` (C++, MSVC 2013) +* ``__is_trivially_relocatable`` (Clang): Returns true if moving an object + of the given type, and then destroying the source object, is known to be + functionally equivalent to copying the underlying bytes and then dropping the + source object on the floor. This is true of trivial types and types which + were made trivially relocatable via the ``clang::trivial_abi`` attribute. +* ``__is_unbounded_array`` (C++, GNU, Microsoft, Embarcadero) * ``__is_union`` (C++, GNU, Microsoft, Embarcadero) * ``__is_unsigned`` (C++, Embarcadero): Returns false for enumeration types. Note, before Clang 13, returned true for @@ -1370,28 +1581,52 @@ Query for this feature with ``__has_extension(blocks)``. ASM Goto with Output Constraints ================================ -In addition to the functionality provided by `GCC's extended -assembly `_, clang -supports output constraints with the `goto` form. +.. note:: + + Clang's implementation of ASM goto differs from `GCC's + implementation `_ in + that Clang doesn't yet support outputs on the indirect branch. Use of an + output on the indirect branch may result in undefined behavior and should be + avoided. E.g., in the following `z` isn't valid when used and may have + different values depending on optimization levels. (Clang may not warn about + such constructs.) + + .. code-block:: c++ + + int foo(int x) { + int y, z; + asm goto(... : "=r"(y), "=r"(z): "r"(x) : : err); + return y; + err: + return z; + } -The goto form of GCC's extended assembly allows the programmer to branch to a C -label from within an inline assembly block. Clang extends this behavior by -allowing the programmer to use output constraints: +When using tied-outputs (i.e. outputs that are inputs and outputs, not just +outputs) with the `+r` constraint, there is a hidden input that's created +before the label, so numeric references to operands must account for that. .. code-block:: c++ int foo(int x) { - int y; - asm goto("# %0 %1 %l2" : "=r"(y) : "r"(x) : : err); - return y; + // %0 and %1 both refer to x + // %l2 refers to err + asm goto("# %0 %1 %l2" : "+r"(x) : : : err); + return x; err: return -1; } -It's important to note that outputs are valid only on the "fallthrough" branch. -Using outputs on an indirect branch may result in undefined behavior. For -example, in the function above, use of the value assigned to `y` in the `err` -block is undefined behavior. +This was changed to match GCC in clang-13; for better portability, symbolic +references can be used instead of numeric references. + +.. code-block:: c++ + + int foo(int x) { + asm goto("# %[x] %l[err]" : [x]"+r"(x) : : : err); + return x; + err: + return -1; + } Query for this feature with ``__has_extension(gnu_asm_goto_with_outputs)``. @@ -1942,7 +2177,7 @@ between the host and device is known to be compatible. struct OnlySL { int a; int b; - NotPod() : a(0), b(0) {} + OnlySL() : a(0), b(0) {} }; // Not standard layout type because of two different access controls. @@ -1950,16 +2185,41 @@ between the host and device is known to be compatible. int a; private: int b; - } + }; + #pragma OPENCL EXTENSION __cl_clang_non_portable_kernel_param_types : enable kernel void kernel_main( Pod a, - #pragma OPENCL EXTENSION __cl_clang_non_portable_kernel_param_types : enable + OnlySL b, global NotSL *c, - #pragma OPENCL EXTENSION __cl_clang_non_portable_kernel_param_types : disable - global OnlySL *d, + global OnlySL *d ); + #pragma OPENCL EXTENSION __cl_clang_non_portable_kernel_param_types : disable + +Remove address space builtin function +------------------------------------- + +``__remove_address_space`` allows to derive types in C++ for OpenCL +that have address space qualifiers removed. This utility only affects +address space qualifiers, therefore, other type qualifiers such as +``const`` or ``volatile`` remain unchanged. + +**Example of Use**: + +.. code-block:: c++ + + template + void foo(T *par){ + T var1; // error - local function variable with global address space + __private T var2; // error - conflicting address space qualifiers + __private __remove_address_space::type var3; // var3 is __private int + } + + void bar(){ + __global int* ptr; + foo(ptr); + } Legacy 1.x atomics with generic address space --------------------------------------------- @@ -1996,10 +2256,79 @@ implemented directly in terms of :ref:`extended vector support ` instead of builtins, in order to reduce the number of builtins that we need to implement. +``__builtin_alloca`` +-------------------- + +``__builtin_alloca`` is used to dynamically allocate memory on the stack. Memory +is automatically freed upon function termination. + +**Syntax**: + +.. code-block:: c++ + + __builtin_alloca(size_t n) + +**Example of Use**: + +.. code-block:: c++ + + void init(float* data, size_t nbelems); + void process(float* data, size_t nbelems); + int foo(size_t n) { + auto mem = (float*)__builtin_alloca(n * sizeof(float)); + init(mem, n); + process(mem, n); + /* mem is automatically freed at this point */ + } + +**Description**: + +``__builtin_alloca`` is meant to be used to allocate a dynamic amount of memory +on the stack. This amount is subject to stack allocation limits. + +Query for this feature with ``__has_builtin(__builtin_alloca)``. + +``__builtin_alloca_with_align`` +------------------------------- + +``__builtin_alloca_with_align`` is used to dynamically allocate memory on the +stack while controlling its alignment. Memory is automatically freed upon +function termination. + + +**Syntax**: + +.. code-block:: c++ + + __builtin_alloca_with_align(size_t n, size_t align) + +**Example of Use**: + +.. code-block:: c++ + + void init(float* data, size_t nbelems); + void process(float* data, size_t nbelems); + int foo(size_t n) { + auto mem = (float*)__builtin_alloca_with_align( + n * sizeof(float), + CHAR_BIT * alignof(float)); + init(mem, n); + process(mem, n); + /* mem is automatically freed at this point */ + } + +**Description**: + +``__builtin_alloca_with_align`` is meant to be used to allocate a dynamic amount of memory +on the stack. It is similar to ``__builtin_alloca`` but accepts a second +argument whose value is the alignment constraint, as a power of 2 in *bits*. + +Query for this feature with ``__has_builtin(__builtin_alloca_with_align)``. + .. _langext-__builtin_assume: ``__builtin_assume`` ------------------------------- +-------------------- ``__builtin_assume`` is used to provide the optimizer with a boolean invariant that is defined to be true. @@ -2008,20 +2337,18 @@ invariant that is defined to be true. .. code-block:: c++ - __builtin_assume(bool) + __builtin_assume(bool) **Example of Use**: .. code-block:: c++ int foo(int x) { - __builtin_assume(x != 0); - - // The optimizer may short-circuit this check using the invariant. - if (x == 0) - return do_something(); - - return do_something_else(); + __builtin_assume(x != 0); + // The optimizer may short-circuit this check using the invariant. + if (x == 0) + return do_something(); + return do_something_else(); } **Description**: @@ -2034,6 +2361,76 @@ evaluated, so any side effects of the expression will be discarded. Query for this feature with ``__has_builtin(__builtin_assume)``. +``__builtin_offsetof`` +---------------------- + +``__builtin_offsetof`` is used to implement the ``offsetof`` macro, which +calculates the offset (in bytes) to a given member of the given type. + +**Syntax**: + +.. code-block:: c++ + + __builtin_offsetof(type-name, member-designator) + +**Example of Use**: + +.. code-block:: c++ + + struct S { + char c; + int i; + struct T { + float f[2]; + } t; + }; + + const int offset_to_i = __builtin_offsetof(struct S, i); + const int ext1 = __builtin_offsetof(struct U { int i; }, i); // C extension + const int ext2 = __builtin_offsetof(struct S, t.f[1]); + +**Description**: + +This builtin is usable in an integer constant expression which returns a value +of type ``size_t``. The value returned is the offset in bytes to the subobject +designated by the member-designator from the beginning of an object of type +``type-name``. Clang extends the required standard functionality in the +following way: + +* In C language modes, the first argument may be the definition of a new type. + Any type declared this way is scoped to the nearest scope containing the call + to the builtin. + +Query for this feature with ``__has_builtin(__builtin_offsetof)``. + +``__builtin_call_with_static_chain`` +------------------------------------ + +``__builtin_call_with_static_chain`` is used to perform a static call while +setting updating the static chain register. + +**Syntax**: + +.. code-block:: c++ + + T __builtin_call_with_static_chain(T expr, void* ptr) + +**Example of Use**: + +.. code-block:: c++ + + auto v = __builtin_call_with_static_chain(foo(3), foo); + +**Description**: + +This builtin returns ``expr`` after checking that ``expr`` is a non-member +static call expression. The call to that expression is made while using ``ptr`` +as a function pointer stored in a dedicated register to implement *static chain* +calling convention, as used by some language to implement closures or nested +functions. + +Query for this feature with ``__has_builtin(__builtin_call_with_static_chain)``. + ``__builtin_readcyclecounter`` ------------------------------ @@ -2075,44 +2472,82 @@ controlled state. .. code-block:: c++ - __builtin_dump_struct(&some_struct, &some_printf_func); + __builtin_dump_struct(&some_struct, some_printf_func, args...); **Examples**: .. code-block:: c++ - struct S { - int x, y; - float f; - struct T { - int i; - } t; - }; + struct S { + int x, y; + float f; + struct T { + int i; + } t; + }; - void func(struct S *s) { - __builtin_dump_struct(s, &printf); - } + void func(struct S *s) { + __builtin_dump_struct(s, printf); + } Example output: .. code-block:: none - struct S { - int i : 100 - int j : 42 - float f : 3.14159 - struct T t : struct T { - int i : 1997 - } - } + struct S { + int x = 100 + int y = 42 + float f = 3.141593 + struct T t = { + int i = 1997 + } + } + +.. code-block:: c++ + + #include + struct T { int a, b; }; + constexpr void constexpr_sprintf(std::string &out, const char *format, + auto ...args) { + // ... + } + constexpr std::string dump_struct(auto &x) { + std::string s; + __builtin_dump_struct(&x, constexpr_sprintf, s); + return s; + } + static_assert(dump_struct(T{1, 2}) == R"(struct T { + int a = 1 + int b = 2 + } + )"); **Description**: -The '``__builtin_dump_struct``' function is used to print the fields of a simple -structure and their values for debugging purposes. The builtin accepts a pointer -to a structure to dump the fields of, and a pointer to a formatted output -function whose signature must be: ``int (*)(const char *, ...)`` and must -support the format specifiers used by ``printf()``. +The ``__builtin_dump_struct`` function is used to print the fields of a simple +structure and their values for debugging purposes. The first argument of the +builtin should be a pointer to the struct to dump. The second argument ``f`` +should be some callable expression, and can be a function object or an overload +set. The builtin calls ``f``, passing any further arguments ``args...`` +followed by a ``printf``-compatible format string and the corresponding +arguments. ``f`` may be called more than once, and ``f`` and ``args`` will be +evaluated once per call. In C++, ``f`` may be a template or overload set and +resolve to different functions for each call. + +In the format string, a suitable format specifier will be used for builtin +types that Clang knows how to format. This includes standard builtin types, as +well as aggregate structures, ``void*`` (printed with ``%p``), and ``const +char*`` (printed with ``%s``). A ``*%p`` specifier will be used for a field +that Clang doesn't know how to format, and the corresopnding argument will be a +pointer to the field. This allows a C++ templated formatting function to detect +this case and implement custom formatting. A ``*`` will otherwise not precede a +format specifier. + +This builtin does not return a value. + +This builtin can be used in constant expressions. + +Query for this feature with ``__has_builtin(__builtin_dump_struct)`` .. _langext-__builtin_shufflevector: @@ -2372,6 +2807,98 @@ flow conditions such as in ``if`` and ``switch`` statements. Query for this feature with ``__has_builtin(__builtin_unpredictable)``. + +``__builtin_expect`` +-------------------- + +``__builtin_expect`` is used to indicate that the value of an expression is +anticipated to be the same as a statically known result. + +**Syntax**: + +.. code-block:: c++ + + long __builtin_expect(long expr, long val) + +**Example of use**: + +.. code-block:: c++ + + if (__builtin_expect(x, 0)) { + bar(); + } + +**Description**: + +The ``__builtin_expect()`` builtin is typically used with control flow +conditions such as in ``if`` and ``switch`` statements to help branch +prediction. It means that its first argument ``expr`` is expected to take the +value of its second argument ``val``. It always returns ``expr``. + +Query for this feature with ``__has_builtin(__builtin_expect)``. + +``__builtin_expect_with_probability`` +------------------------------------- + +``__builtin_expect_with_probability`` is similar to ``__builtin_expect`` but it +takes a probability as third argument. + +**Syntax**: + +.. code-block:: c++ + + long __builtin_expect_with_probability(long expr, long val, double p) + +**Example of use**: + +.. code-block:: c++ + + if (__builtin_expect_with_probability(x, 0, .3)) { + bar(); + } + +**Description**: + +The ``__builtin_expect_with_probability()`` builtin is typically used with +control flow conditions such as in ``if`` and ``switch`` statements to help +branch prediction. It means that its first argument ``expr`` is expected to take +the value of its second argument ``val`` with probability ``p``. ``p`` must be +within ``[0.0 ; 1.0]`` bounds. This builtin always returns the value of ``expr``. + +Query for this feature with ``__has_builtin(__builtin_expect_with_probability)``. + +``__builtin_prefetch`` +---------------------- + +``__builtin_prefetch`` is used to communicate with the cache handler to bring +data into the cache before it gets used. + +**Syntax**: + +.. code-block:: c++ + + void __builtin_prefetch(const void *addr, int rw=0, int locality=3) + +**Example of use**: + +.. code-block:: c++ + + __builtin_prefetch(a + i); + +**Description**: + +The ``__builtin_prefetch(addr, rw, locality)`` builtin is expected to be used to +avoid cache misses when the developper has a good understanding of which data +are going to be used next. ``addr`` is the address that needs to be brought into +the cache. ``rw`` indicates the expected access mode: ``0`` for *read* and ``1`` +for *write*. In case of *read write* access, ``1`` is to be used. ``locality`` +indicates the expected persistance of data in cache, from ``0`` which means that +data can be discarded from cache after its next use to ``3`` which means that +data is going to be reused a lot once in cache. ``1`` and ``2`` provide +intermediate behavior between these two extremes. + +Query for this feature with ``__has_builtin(__builtin_prefetch)``. + ``__sync_swap`` --------------- @@ -2405,7 +2932,8 @@ implementation details of ``__sync_lock_test_and_set()``. The ``__builtin_addressof`` performs the functionality of the built-in ``&`` operator, ignoring any ``operator&`` overload. This is useful in constant expressions in C++11, where there is no other way to take the address of an -object that overloads ``operator&``. +object that overloads ``operator&``. Clang automatically adds +``[[clang::lifetimebound]]`` to the parameter of ``__builtin_addressof``. **Example of use**: @@ -2415,6 +2943,48 @@ object that overloads ``operator&``. return __builtin_addressof(value); } +``__builtin_function_start`` +----------------------------- + +``__builtin_function_start`` returns the address of a function body. + +**Syntax**: + +.. code-block:: c++ + + void *__builtin_function_start(function) + +**Example of use**: + +.. code-block:: c++ + + void a() {} + void *p = __builtin_function_start(a); + + class A { + public: + void a(int n); + void a(); + }; + + void A::a(int n) {} + void A::a() {} + + void *pa1 = __builtin_function_start((void(A::*)(int)) &A::a); + void *pa2 = __builtin_function_start((void(A::*)()) &A::a); + +**Description**: + +The ``__builtin_function_start`` builtin accepts an argument that can be +constant-evaluated to a function, and returns the address of the function +body. This builtin is not supported on all targets. + +The returned pointer may differ from the normally taken function address +and is not safe to call. For example, with ``-fsanitize=cfi``, taking a +function address produces a callable pointer to a CFI jump table, while +``__builtin_function_start`` returns an address that fails +:doc:`cfi-icall` checks. + ``__builtin_operator_new`` and ``__builtin_operator_delete`` ------------------------------------------------------------ @@ -2476,6 +3046,42 @@ argument. int *pb =__builtin_preserve_access_index(&v->c[3].b); __builtin_preserve_access_index(v->j); +``__builtin_debugtrap`` +----------------------- + +``__builtin_debugtrap`` causes the program to stop its execution in such a way that a debugger can catch it. + +**Syntax**: + +.. code-block:: c++ + + __builtin_debugtrap() + +**Description** + +``__builtin_debugtrap`` is lowered to the ` ``llvm.debugtrap`` `_ builtin. It should have the same effect as setting a breakpoint on the line where the builtin is called. + +Query for this feature with ``__has_builtin(__builtin_debugtrap)``. + + +``__builtin_trap`` +------------------ + +``__builtin_trap`` causes the program to stop its execution abnormally. + +**Syntax**: + +.. code-block:: c++ + + __builtin_trap() + +**Description** + +``__builtin_trap`` is lowered to the ` ``llvm.trap`` `_ builtin. + +Query for this feature with ``__has_builtin(__builtin_trap)``. + + ``__builtin_sycl_unique_stable_name`` ------------------------------------- @@ -2493,15 +3099,12 @@ stable numbering order in which they appear in their local declaration contexts. Once this builtin is evaluated in a constexpr context, it is erroneous to use it in an instantiation which changes its value. -In order to produce the unique name, the current implementation of the bultin +In order to produce the unique name, the current implementation of the builtin uses Itanium mangling even if the host compilation uses a different name mangling scheme at runtime. The mangler marks all the lambdas required to name -the SYCL kernel and emits a stable local ordering of the respective lambdas, -starting from ``10000``. The initial value of ``10000`` serves as an obvious -differentiator from ordinary lambda mangling numbers but does not serve any -other purpose and may change in the future. The resulting pattern is -demanglable. When non-lambda types are passed to the builtin, the mangler emits -their usual pattern without any special treatment. +the SYCL kernel and emits a stable local ordering of the respective lambdas. +The resulting pattern is demanglable. When non-lambda types are passed to the +builtin, the mangler emits their usual pattern without any special treatment. **Syntax**: @@ -2673,6 +3276,52 @@ despite these functions accepting an argument of type ``const void*``. Support for constant expression evaluation for the above builtins can be detected with ``__has_feature(cxx_constexpr_string_builtins)``. +Variadic function builtins +-------------------------- + +Clang provides several builtins for working with variadic functions from the C +standard library ```` header: + +* ``__builtin_va_list`` + +A predefined typedef for the target-specific ``va_list`` type. + +* ``void __builtin_va_start(__builtin_va_list list, )`` + +A builtin function for the target-specific ``va_start`` function-like macro. +The ``parameter-name`` argument is the name of the parameter preceding the +ellipsis (``...``) in the function signature. Alternatively, in C2x mode or +later, it may be the integer literal ``0`` if there is no parameter preceding +the ellipsis. This function initializes the given ``__builtin_va_list`` object. +It is undefined behavior to call this function on an already initialized +``__builin_va_list`` object. + +* ``void __builtin_va_end(__builtin_va_list list)`` + +A builtin function for the target-specific ``va_end`` function-like macro. This +function finalizes the given ``__builtin_va_list`` object such that it is no +longer usable unless re-initialized with a call to ``__builtin_va_start`` or +``__builtin_va_copy``. It is undefined behavior to call this function with a +``list`` that has not been initialized by either ``__builtin_va_start`` or +``__builtin_va_copy``. + +* `` __builtin_va_arg(__builtin_va_list list, )`` + +A builtin function for the target-specific ``va_arg`` function-like macro. This +function returns the value of the next variadic argument to the call. It is +undefined behavior to call this builtin when there is no next varadic argument +to retrieve or if the next variadic argument does not have a type compatible +with the given ``type-name``. The return type of the function is the +``type-name`` given as the second argument. It is undefined behavior to call +this function with a ``list`` that has not been initialized by either +``__builtin_va_start`` or ``__builtin_va_copy``. + +* ``void __builtin_va_copy(__builtin_va_list dest, __builtin_va_list src)`` + +A builtin function for the target-specific ``va_copy`` function-like macro. +This function initializes ``dest`` as a copy of ``src``. It is undefined +behavior to call this function with an already initialized ``dest`` argument. + Memory builtins --------------- @@ -2714,6 +3363,26 @@ Note that the `size` argument must be a compile time constant. Note that this intrinsic cannot yet be called in a ``constexpr`` context. +Guaranteed inlined memset +^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. code-block:: c + + void __builtin_memset_inline(void *dst, int value, size_t size); + + +``__builtin_memset_inline`` has been designed as a building block for efficient +``memset`` implementations. It is identical to ``__builtin_memset`` but also +guarantees not to call any external functions. See LLVM IR `llvm.memset.inline +`_ intrinsic +for more information. + +This is useful to implement a custom version of ``memset``, implement a +``libc`` memset or work around the absence of a ``libc``. + +Note that the `size` argument must be a compile time constant. + +Note that this intrinsic cannot yet be called in a ``constexpr`` context. Atomic Min/Max builtins with memory ordering -------------------------------------------- @@ -2767,6 +3436,7 @@ the corresponding C11 operations, are: * ``__c11_atomic_fetch_and`` * ``__c11_atomic_fetch_or`` * ``__c11_atomic_fetch_xor`` +* ``__c11_atomic_fetch_nand`` (Nand is not presented in ````) * ``__c11_atomic_fetch_max`` * ``__c11_atomic_fetch_min`` @@ -2847,7 +3517,7 @@ C++ Coroutines support builtins Clang provides experimental builtins to support C++ Coroutines as defined by https://wg21.link/P0057. The following four are intended to be used by the -standard library to implement `std::experimental::coroutine_handle` type. +standard library to implement the ``std::coroutine_handle`` type. **Syntax**: @@ -2907,7 +3577,6 @@ an appropriate value during the emission. void *__builtin_coro_begin(void *memory) void __builtin_coro_end(void *coro_frame, bool unwind) char __builtin_coro_suspend(bool final) - bool __builtin_coro_param(void *original, void *copy) Note that there is no builtin matching the `llvm.coro.save` intrinsic. LLVM automatically will insert one if the first argument to `llvm.coro.suspend` is @@ -2917,10 +3586,9 @@ as the first argument to the intrinsic. Source location builtins ------------------------ -Clang provides experimental builtins to support C++ standard library implementation -of ``std::experimental::source_location`` as specified in http://wg21.link/N4600. -With the exception of ``__builtin_COLUMN``, these builtins are also implemented by -GCC. +Clang provides builtins to support C++ standard library implementation +of ``std::source_location`` as specified in C++20. With the exception +of ``__builtin_COLUMN``, these builtins are also implemented by GCC. **Syntax**: @@ -2930,6 +3598,7 @@ GCC. const char *__builtin_FUNCTION(); unsigned __builtin_LINE(); unsigned __builtin_COLUMN(); // Clang only + const std::source_location::__impl *__builtin_source_location(); **Example of use**: @@ -2956,9 +3625,11 @@ GCC. **Description**: -The builtins ``__builtin_LINE``, ``__builtin_FUNCTION``, and ``__builtin_FILE`` return -the values, at the "invocation point", for ``__LINE__``, ``__FUNCTION__``, and -``__FILE__`` respectively. These builtins are constant expressions. +The builtins ``__builtin_LINE``, ``__builtin_FUNCTION``, and ``__builtin_FILE`` +return the values, at the "invocation point", for ``__LINE__``, +``__FUNCTION__``, and ``__FILE__`` respectively. ``__builtin_COLUMN`` similarly +returns the column, though there is no corresponding macro. These builtins are +constant expressions. When the builtins appear as part of a default function argument the invocation point is the location of the caller. When the builtins appear as part of a @@ -2969,6 +3640,15 @@ the invocation point is the same as the location of the builtin. When the invocation point of ``__builtin_FUNCTION`` is not a function scope the empty string is returned. +The builtin ``__builtin_source_location`` returns a pointer to constant static +data of type ``std::source_location::__impl``. This type must have already been +defined, and must contain exactly four fields: ``const char *_M_file_name``, +``const char *_M_function_name``, `` _M_line``, and +`` _M_column``. The fields will be populated in the same +manner as the above four builtins, except that ``_M_function_name`` is populated +with ``__PRETTY_FUNCTION__`` rather than ``__FUNCTION__``. + + Alignment builtins ------------------ Clang provides builtins to support checking and adjusting alignment of @@ -3078,8 +3758,8 @@ ARM/AArch64 Language Extensions Memory Barrier Intrinsics ^^^^^^^^^^^^^^^^^^^^^^^^^ Clang implements the ``__dmb``, ``__dsb`` and ``__isb`` intrinsics as defined -in the `ARM C Language Extensions Release 2.0 -`_. +in the `Arm C Language Extensions +`_. Note that these intrinsics are implemented as motion barriers that block reordering of memory accesses and side effect instructions. Other instructions like simple arithmetic may be reordered around the intrinsic. If you expect to @@ -3123,7 +3803,7 @@ the same purpose. The preprocessor symbols ``__SEG_FS`` and ``__SEG_GS`` indicate their support. PowerPC Language Extensions ------------------------------- +--------------------------- Set the Floating Point Rounding Mode ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -3193,6 +3873,9 @@ with :doc:`ThreadSanitizer`. Use ``__has_feature(memory_sanitizer)`` to check if the code is being built with :doc:`MemorySanitizer`. +Use ``__has_feature(dataflow_sanitizer)`` to check if the code is being built +with :doc:`DataFlowSanitizer`. + Use ``__has_feature(safe_stack)`` to check if the code is being built with :doc:`SafeStack`. @@ -3275,6 +3958,44 @@ it causes the instantiation of ``twice`` and ``thrice`` with an ``int`` type; of these two instantiations, ``twice`` will be optimized (because its definition was outside the region) and ``thrice`` will not be optimized. +Clang also implements MSVC's range-based pragma, +``#pragma optimize("[optimization-list]", on | off)``. At the moment, Clang only +supports an empty optimization list, whereas MSVC supports the arguments, ``s``, +``g``, ``t``, and ``y``. Currently, the implementation of ``pragma optimize`` behaves +the same as ``#pragma clang optimize``. All functions +between ``off`` and ``on`` will be decorated with the ``optnone`` attribute. + +.. code-block:: c++ + + #pragma optimize("", off) + // This function will be decorated with optnone. + void f1() {} + + #pragma optimize("", on) + // This function will be optimized with whatever was specified on + // the commandline. + void f2() {} + + // This will warn with Clang's current implementation. + #pragma optimize("g", on) + void f3() {} + +For MSVC, an empty optimization list and ``off`` parameter will turn off +all optimizations, ``s``, ``g``, ``t``, and ``y``. An empty optimization and +``on`` parameter will reset the optimizations to the ones specified on the +commandline. + +.. list-table:: Parameters (unsupported by Clang) + + * - Parameter + - Type of optimization + * - g + - Deprecated + * - s or t + - Short or fast sequences of machine code + * - y + - Enable frame pointers + Extensions for loop hint optimizations ====================================== @@ -3519,7 +4240,7 @@ Note that ``-ffp-contract=fast`` will override pragmas to fuse multiply and addition across statements regardless of any controlling pragmas. ``#pragma clang fp exceptions`` specifies floating point exception behavior. It -may take one the the values: ``ignore``, ``maytrap`` or ``strict``. Meaning of +may take one of the values: ``ignore``, ``maytrap`` or ``strict``. Meaning of these values is same as for `constrained floating point intrinsics `_. .. code-block:: c++ @@ -3529,7 +4250,7 @@ these values is same as for `constrained floating point intrinsics ") + + /// Foo.h + struct Foo { + #if TARGET_ARM // warning: TARGET_ARM is marked unsafe in headers: + uint32_t X; + #else + uint64_t X; + #endif + }; + + /// main.c + #include "foo.h" + #if TARGET_ARM // No warning in main source file + X_TYPE uint32_t + #else + X_TYPE uint64_t + #endif + +This warning is controlled by ``-Wpedantic-macros``. + +Final Macros +============ + +Clang supports the pragma ``#pragma clang final``, which can be used to +mark macros as final, meaning they cannot be undef'd or re-defined. For example: + +.. code-block:: c + + #define FINAL_MACRO 1 + #pragma clang final(FINAL_MACRO) + + #define FINAL_MACRO // warning: FINAL_MACRO is marked final and should not be redefined + #undef FINAL_MACRO // warning: FINAL_MACRO is marked final and should not be undefined + +This is useful for enforcing system-provided macros that should not be altered +in user headers or code. This is controlled by ``-Wpedantic-macros``. Final +macros will always warn on redefinition, including situations with identical +bodies and in system headers. + +Line Control +============ + +Clang supports an extension for source line control, which takes the +form of a preprocessor directive starting with an unsigned integral +constant. In addition to the standard ``#line`` directive, this form +allows control of an include stack and header file type, which is used +in issuing diagnostics. These lines are emitted in preprocessed +output. + +.. code-block:: c + + # + +The filename is optional, and if unspecified indicates no change in +source filename. The header-type is an optional, whitespace-delimited, +sequence of magic numbers as follows. + +* ``1:`` Push the current source file name onto the include stack and + enter a new file. + +* ``2``: Pop the include stack and return to the specified file. If + the filename is ``""``, the name popped from the include stack is + used. Otherwise there is no requirement that the specified filename + matches the current source when originally pushed. + +* ``3``: Enter a system-header region. System headers often contain + implementation-specific source that would normally emit a diagnostic. + +* ``4``: Enter an implicit ``extern "C"`` region. This is not required on + modern systems where system headers are C++-aware. + +At most a single ``1`` or ``2`` can be present, and values must be in +ascending order. + +Examples are: + +.. code-block:: c + + # 57 // Advance (or return) to line 57 of the current source file + # 57 "frob" // Set to line 57 of "frob" + # 1 "foo.h" 1 // Enter "foo.h" at line 1 + # 59 "main.c" 2 // Leave current include and return to "main.c" + # 1 "/usr/include/stdio.h" 1 3 // Enter a system header + # 60 "" 2 // return to "main.c" + # 1 "/usr/ancient/header.h" 1 4 // Enter an implicit extern "C" header + Extended Integer Types ====================== -Clang supports a set of extended integer types under the syntax ``_ExtInt(N)`` -where ``N`` is an integer that specifies the number of bits that are used to represent -the type, including the sign bit. The keyword ``_ExtInt`` is a type specifier, thus -it can be used in any place a type can, including as a non-type-template-parameter, -as the type of a bitfield, and as the underlying type of an enumeration. - -An extended integer can be declared either signed, or unsigned by using the -``signed``/``unsigned`` keywords. If no sign specifier is used or if the ``signed`` -keyword is used, the extended integer type is a signed integer and can represent -negative values. - -The ``N`` expression is an integer constant expression, which specifies the number -of bits used to represent the type, following normal integer representations for -both signed and unsigned types. Both a signed and unsigned extended integer of the -same ``N`` value will have the same number of bits in its representation. Many -architectures don't have a way of representing non power-of-2 integers, so these -architectures emulate these types using larger integers. In these cases, they are -expected to follow the 'as-if' rule and do math 'as-if' they were done at the -specified number of bits. - -In order to be consistent with the C language specification, and make the extended -integer types useful for their intended purpose, extended integers follow the C -standard integer conversion ranks. An extended integer type has a greater rank than -any integer type with less precision. However, they have lower rank than any -of the built in or other integer types (such as __int128). Usual arithmetic conversions -also work the same, where the smaller ranked integer is converted to the larger. - -The one exception to the C rules for integers for these types is Integer Promotion. -Unary +, -, and ~ operators typically will promote operands to ``int``. Doing these -promotions would inflate the size of required hardware on some platforms, so extended -integer types aren't subject to the integer promotion rules in these cases. - -In languages (such as OpenCL) that define shift by-out-of-range behavior as a mask, -non-power-of-two versions of these types use an unsigned remainder operation to constrain -the value to the proper range, preventing undefined behavior. - -Extended integer types are aligned to the next greatest power-of-2 up to 64 bits. -The size of these types for the purposes of layout and ``sizeof`` are the number of -bits aligned to this calculated alignment. This permits the use of these types in -allocated arrays using common ``sizeof(Array)/sizeof(ElementType)`` pattern. - -Extended integer types work with the C _Atomic type modifier, however only precisions -that are powers-of-2 greater than 8 bit are accepted. - -Extended integer types align with existing calling conventions. They have the same size -and alignment as the smallest basic type that can contain them. Types that are larger -than 64 bits are handled in the same way as _int128 is handled; they are conceptually -treated as struct of register size chunks. They number of chunks are the smallest -number that can contain the types which does not necessarily mean a power-of-2 size. +Clang supports the C23 ``_BitInt(N)`` feature as an extension in older C modes +and in C++. This type was previously implemented in Clang with the same +semantics, but spelled ``_ExtInt(N)``. This spelling has been deprecated in +favor of the standard type. + +Note: the ABI for ``_BitInt(N)`` is still in the process of being stabilized, +so this type should not yet be used in interfaces that require ABI stability. Intrinsics Support within Constant Expressions ============================================== @@ -3943,6 +4790,8 @@ The following builtin intrinsics can be used in constant expressions: * ``__builtin_ffs`` * ``__builtin_ffsl`` * ``__builtin_ffsll`` +* ``__builtin_fmax`` +* ``__builtin_fmin`` * ``__builtin_fpclassify`` * ``__builtin_inf`` * ``__builtin_isinf`` diff --git a/gnu/llvm/clang/docs/LibASTImporter.rst b/gnu/llvm/clang/docs/LibASTImporter.rst index bedaf527f5e..515eff7ebe3 100644 --- a/gnu/llvm/clang/docs/LibASTImporter.rst +++ b/gnu/llvm/clang/docs/LibASTImporter.rst @@ -468,7 +468,7 @@ Note, there may be several different ASTImporter objects which import into the s cxxRecordDecl(hasName("Y"), isDefinition()), ToUnit); ToYDef->dump(); // An error is set for "ToYDef" in the shared state. - Optional OptErr = + Optional OptErr = ImporterState->getImportDeclErrorIfAny(ToYDef); assert(OptErr); diff --git a/gnu/llvm/clang/docs/LibASTMatchersReference.html b/gnu/llvm/clang/docs/LibASTMatchersReference.html index 9999565f7f2..571dfc3f21b 100644 --- a/gnu/llvm/clang/docs/LibASTMatchersReference.html +++ b/gnu/llvm/clang/docs/LibASTMatchersReference.html @@ -112,7 +112,7 @@ This affects both matchers and AST dump output in results. traverse() matcher is used to set the mode:
 Finder->addMatcher(traverse(TK_IgnoreUnlessSpelledInSource,
-  returnStmt(hasReturnArgument(integerLiteral(equals(0))))
+  returnStmt(hasReturnValue(integerLiteral(equals(0))))
   ), this);
 

@@ -573,6 +573,24 @@ recordDecl(decl().bind("id"), hasName("::MyClass")) Return typeNameParameters +Matcher<Attr>attrMatcher<Attr>... +
Matches attributes.
+Attributes may be attached with a variety of different syntaxes (including
+keywords, C++11 attributes, GNU ``__attribute``` and MSVC `__declspec``,
+and ``#pragma``s). They may also be implicit.
+
+Given
+  struct [[nodiscard]] Foo{};
+  void bar(int * __attribute__((nonnull)) );
+  __declspec(noinline) void baz();
+
+  #pragma omp declare simd
+  int min();
+attr()
+  matches "nodiscard", "nonnull", "noinline", and the whole "#pragma" line.
+
+ + Matcher<CXXBaseSpecifier>cxxBaseSpecifierMatcher<CXXBaseSpecifier>...
Matches class bases.
 
@@ -994,7 +1012,7 @@ Example matches X, Z, U, and S
 
Matches a C++ static_assert declaration.
 
 Example:
-  staticAssertExpr()
+  staticAssertDecl()
 matches
   static_assert(sizeof(S) == sizeof(int))
 in
@@ -1142,6 +1160,16 @@ usingDirectiveDecl()
   matches using namespace X 
+Matcher<Decl>usingEnumDeclMatcher<UsingEnumDecl>... +
Matches using-enum declarations.
+
+Given
+  namespace X { enum x {...}; }
+  using enum X::x;
+usingEnumDecl()
+  matches using enum X::x 
+ + Matcher<Decl>valueDeclMatcher<ValueDecl>...
Matches any value declaration.
 
@@ -1162,6 +1190,20 @@ Example matches a
 
+Matcher<LambdaCapture>lambdaCaptureMatcher<LambdaCapture>... +
Matches lambda captures.
+
+Given
+  int main() {
+    int x;
+    auto f = [x](){};
+    auto g = [x = 1](){};
+  }
+In the matcher `lambdaExpr(hasAnyCapture(lambdaCapture()))`,
+`lambdaCapture()` matches `x` and `x=1`.
+
+ + Matcher<NestedNameSpecifierLoc>nestedNameSpecifierLocMatcher<NestedNameSpecifierLoc>...
Same as nestedNameSpecifier but matches NestedNameSpecifierLoc.
 
@@ -1189,11 +1231,12 @@ Given #pragma omp parallel default(none) #pragma omp parallel default(shared) + #pragma omp parallel default(private) #pragma omp parallel default(firstprivate) #pragma omp parallel -``ompDefaultClause()`` matches ``default(none)``, ``default(shared)``, and -``default(firstprivate)`` +``ompDefaultClause()`` matches ``default(none)``, ``default(shared)``, +`` default(private)`` and ``default(firstprivate)``
@@ -1993,6 +2036,14 @@ NSString's "alloc". This matcher should match both message sends. +Matcher<Stmt>objcStringLiteralMatcher<ObjCStringLiteral>... +
Matches ObjectiveC String literal expressions.
+
+Example matches @"abcd"
+  NSString *s = @"abcd";
+
+ + Matcher<Stmt>objcThrowStmtMatcher<ObjCAtThrowStmt>...
Matches Objective-C statements.
 
@@ -2234,6 +2285,60 @@ templateName()
 
+Matcher<TypeLoc>elaboratedTypeLocMatcher<ElaboratedTypeLoc>... +
Matches C or C++ elaborated `TypeLoc`s.
+
+Given
+  struct s {};
+  struct s ss;
+elaboratedTypeLoc()
+  matches the `TypeLoc` of the variable declaration of `ss`.
+
+ + +Matcher<TypeLoc>pointerTypeLocMatcher<PointerTypeLoc>... +
Matches pointer `TypeLoc`s.
+
+Given
+  int* x;
+pointerTypeLoc()
+  matches `int*`.
+
+ + +Matcher<TypeLoc>qualifiedTypeLocMatcher<QualifiedTypeLoc>... +
Matches `QualifiedTypeLoc`s in the clang AST.
+
+Given
+  const int x = 0;
+qualifiedTypeLoc()
+  matches `const int`.
+
+ + +Matcher<TypeLoc>referenceTypeLocMatcher<ReferenceTypeLoc>... +
Matches reference `TypeLoc`s.
+
+Given
+  int x = 3;
+  int& l = x;
+  int&& r = 3;
+referenceTypeLoc()
+  matches `int&` and `int&&`.
+
+ + +Matcher<TypeLoc>templateSpecializationTypeLocMatcher<TemplateSpecializationTypeLoc>... +
Matches template specialization `TypeLoc`s.
+
+Given
+  template <typename T> class C {};
+  C<char> var;
+varDecl(hasTypeLoc(templateSpecializationTypeLoc(typeLoc())))
+  matches `C<char> var`.
+
+ + Matcher<TypeLoc>typeLocMatcher<TypeLoc>...
Matches TypeLocs in the clang AST.
 
@@ -2649,6 +2754,18 @@ unaryTransformType() +Matcher<Type>usingTypeMatcher<UsingType>... +
Matches types specified through a using declaration.
+
+Given
+  namespace a { struct S {}; }
+  using a::S;
+  S s;
+
+usingType() matches the type of the variable declaration of s.
+
+ + Matcher<Type>variableArrayTypeMatcher<VariableArrayType>...
Matches C arrays with a specified size that is not an
 integer-constant-expression.
@@ -2744,6 +2861,12 @@ Usable as: Any Matcher
 
+Matcher<Attr>isImplicit +
Matches an entity that has been implicitly added by the compiler (e.g.
+implicit default/copy constructors).
+
+ + Matcher<BinaryOperator>hasAnyOperatorNameStringRef, ..., StringRef
Matches operator expressions (binary or unary) that have any of the
 specified names.
@@ -3007,6 +3130,10 @@ cxxDeductionGuideDecl(isExplicit()) will match #6, but not #5.
 
+Matcher<CXXConstructorDecl>isInheritingConstructor +

+
+
 Matcher<CXXConstructorDecl>isMoveConstructor
 
Matches constructor declarations that are move constructors.
 
@@ -3755,7 +3882,7 @@ passed as a quoted string. e.g., hasAttr("attr::CUDADevice").
 Matcher<Decl>isExpandedFromMacrostd::string MacroName
 
Matches statements that are (transitively) expanded from the named macro.
 Does not match if only part of the statement is expanded from that macro or
-if different parts of the the statement are expanded from different
+if different parts of the statement are expanded from different
 appearances of the macro.
 
@@ -3808,8 +3935,30 @@ Usable as: Matcher<Decl>isImplicit -
Matches a declaration that has been implicitly added
-by the compiler (eg. implicit default/copy constructors).
+
Matches an entity that has been implicitly added by the compiler (e.g.
+implicit default/copy constructors).
+
+ + +Matcher<Decl>isInAnonymousNamespace +
Matches declarations in an anonymous namespace.
+
+Given
+  class vector {};
+  namespace foo {
+    class vector {};
+    namespace {
+      class vector {}; // #1
+    }
+  }
+  namespace {
+    class vector {}; // #2
+    namespace foo {
+      class vector{}; // #3
+    }
+  }
+cxxRecordDecl(hasName("vector"), isInAnonymousNamespace()) will match
+#1, #2 and #3.
 
@@ -4095,6 +4244,22 @@ auto Y() -> int {}
+Matcher<FunctionDecl>isConsteval +
Matches consteval function declarations and if consteval/if ! consteval
+statements.
+
+Given:
+  consteval int a();
+  void b() { if consteval {} }
+  void c() { if ! consteval {} }
+  void d() { if ! consteval {} else {} }
+functionDecl(isConsteval())
+  matches the declaration of "int a()".
+ifStmt(isConsteval())
+  matches the if statement in "void b()", "void c()", "void d()".
+
+ + Matcher<FunctionDecl>isConstexpr
Matches constexpr variable and function declarations,
        and if constexpr.
@@ -4188,7 +4353,7 @@ varDecl(isExternC())
 
 
 Matcher<FunctionDecl>isInline
-
Matches function and namespace declarations that are marked with
+
Matches functions, variables and namespace declarations that are marked with
 the inline keyword.
 
 Given
@@ -4197,8 +4362,10 @@ Given
   namespace n {
   inline namespace m {}
   }
+  inline int Foo = 5;
 functionDecl(isInline()) will match ::f().
 namespaceDecl(isInline()) will match n::m.
+varDecl(isInline()) will match Foo;
 
@@ -4367,6 +4534,22 @@ functionProtoType(parameterCountIs(3))
+Matcher<IfStmt>isConsteval +
Matches consteval function declarations and if consteval/if ! consteval
+statements.
+
+Given:
+  consteval int a();
+  void b() { if consteval {} }
+  void c() { if ! consteval {} }
+  void d() { if ! consteval {} else {} }
+functionDecl(isConsteval())
+  matches the declaration of "int a()".
+ifStmt(isConsteval())
+  matches the if statement in "void b()", "void c()", "void d()".
+
+ + Matcher<IfStmt>isConstexpr
Matches constexpr variable and function declarations,
        and if constexpr.
@@ -4422,6 +4605,28 @@ Usable as: Matcher<

 
 
+Matcher<
LambdaCapture>capturesThis +
Matches a `LambdaCapture` that refers to 'this'.
+
+Given
+class C {
+  int cc;
+  int f() {
+    auto l = [this]() { return cc; };
+    return l();
+  }
+};
+lambdaExpr(hasAnyCapture(lambdaCapture(capturesThis())))
+  matches `[this]() { return cc; }`.
+
+ + +Matcher<LambdaCapture>isImplicit +
Matches an entity that has been implicitly added by the compiler (e.g.
+implicit default/copy constructors).
+
+ + Matcher<MemberExpr>isArrow
Matches member expressions that are called with '->' as opposed
 to '.'.
@@ -4525,7 +4730,7 @@ namespaceDecl(isAnonymous()) will match #1 but not ::n.
 
 
 Matcher<NamespaceDecl>isInline
-
Matches function and namespace declarations that are marked with
+
Matches functions, variables and namespace declarations that are marked with
 the inline keyword.
 
 Given
@@ -4534,8 +4739,10 @@ Given
   namespace n {
   inline namespace m {}
   }
+  inline int Foo = 5;
 functionDecl(isInline()) will match ::f().
 namespaceDecl(isInline()) will match n::m.
+varDecl(isInline()) will match Foo;
 
@@ -4548,6 +4755,7 @@ Given #pragma omp parallel #pragma omp parallel default(none) #pragma omp parallel default(shared) + #pragma omp parallel default(private) #pragma omp parallel default(firstprivate) ``ompDefaultClause(isFirstPrivateKind())`` matches only @@ -4563,12 +4771,30 @@ Given #pragma omp parallel #pragma omp parallel default(none) #pragma omp parallel default(shared) + #pragma omp parallel default(private) #pragma omp parallel default(firstprivate) ``ompDefaultClause(isNoneKind())`` matches only ``default(none)``.
+Matcher<OMPDefaultClause>isPrivateKind +
Matches if the OpenMP ``default`` clause has ``private`` kind
+specified.
+
+Given
+
+  #pragma omp parallel
+  #pragma omp parallel default(none)
+  #pragma omp parallel default(shared)
+  #pragma omp parallel default(private)
+  #pragma omp parallel default(firstprivate)
+
+``ompDefaultClause(isPrivateKind())`` matches only
+``default(private)``.
+
+ + Matcher<OMPDefaultClause>isSharedKind
Matches if the OpenMP ``default`` clause has ``shared`` kind specified.
 
@@ -4577,6 +4803,7 @@ Given
   #pragma omp parallel
   #pragma omp parallel default(none)
   #pragma omp parallel default(shared)
+  #pragma omp parallel default(private)
   #pragma omp parallel default(firstprivate)
 
 ``ompDefaultClause(isSharedKind())`` matches only ``default(shared)``.
@@ -5014,7 +5241,7 @@ Stmt has pointer identity in the AST.
 Matcher<Stmt>isExpandedFromMacrostd::string MacroName
 
Matches statements that are (transitively) expanded from the named macro.
 Does not match if only part of the statement is expanded from that macro or
-if different parts of the the statement are expanded from different
+if different parts of the statement are expanded from different
 appearances of the macro.
 
@@ -5208,7 +5435,7 @@ classTemplateSpecializationDecl(templateArgumentCountIs(1)) Matcher<TypeLoc>isExpandedFromMacrostd::string MacroName
Matches statements that are (transitively) expanded from the named macro.
 Does not match if only part of the statement is expanded from that macro or
-if different parts of the the statement are expanded from different
+if different parts of the statement are expanded from different
 appearances of the macro.
 
@@ -5468,6 +5695,19 @@ ifStmt(isConstexpr())
+Matcher<VarDecl>isConstinit +
Matches constinit variable declarations.
+
+Given:
+  constinit int foo = 42;
+  constinit const char* bar = "bar";
+  int baz = 42;
+  [[clang::require_constant_initialization]] int xyz = 42;
+varDecl(isConstinit())
+  matches the declaration of `foo` and `bar`, but not `baz` and `xyz`.
+
+ + Matcher<VarDecl>isDefinition
Matches if a declaration has a body attached.
 
@@ -5534,6 +5774,32 @@ varDecl(isExternC())
 
+Matcher<VarDecl>isInitCapture +
Matches a variable serving as the implicit variable for a lambda init-
+capture.
+
+Example matches x (matcher = varDecl(isInitCapture()))
+auto f = [x=3]() { return x; };
+
+ + +Matcher<VarDecl>isInline +
Matches functions, variables and namespace declarations that are marked with
+the inline keyword.
+
+Given
+  inline void f();
+  void g();
+  namespace n {
+  inline namespace m {}
+  }
+  inline int Foo = 5;
+functionDecl(isInline()) will match ::f().
+namespaceDecl(isInline()) will match n::m.
+varDecl(isInline()) will match Foo;
+
+ + Matcher<VarDecl>isStaticLocal
Matches a static variable with local scope.
 
@@ -6036,6 +6302,16 @@ Usable as: Matcher<BaseUsingDecl>hasAnyUsingShadowDeclMatcher<UsingShadowDecl> InnerMatcher
+
Matches any using shadow declaration.
+
+Given
+  namespace X { void b(); }
+  using X::b;
+usingDecl(hasAnyUsingShadowDecl(hasName("b"))))
+  matches using X::b 
+ + Matcher<BinaryOperator>hasEitherOperandMatcher<Expr> InnerMatcher
Matches if either the left hand side or the right hand side of a
 binary operator matches.
@@ -6471,7 +6747,26 @@ memberExpr(hasObjectExpression(hasType(pointsTo(
 
 
 Matcher<CXXForRangeStmt>hasBodyMatcher<Stmt> InnerMatcher
-

+
Matches a 'for', 'while', 'do' statement or a function definition that has
+a given body. Note that in case of functions this matcher only matches the
+definition itself and not the other declarations of the same function.
+
+Given
+  for (;;) {}
+forStmt(hasBody(compoundStmt()))
+  matches 'for (;;) {}'
+with compoundStmt()
+  matching '{}'
+
+Given
+  void f();
+  void f() {}
+functionDecl(hasBody(compoundStmt()))
+  matches 'void f() {}'
+with compoundStmt()
+  matching '{}'
+  but does not match 'void f();'
+
Matcher<CXXForRangeStmt>hasInitStatementMatcher<Stmt> InnerMatcher @@ -7001,14 +7296,24 @@ Usable as: Matcher<CallExpr>calleeMatcher<Decl> InnerMatcher -
Matches if the call expression's callee's declaration matches the
-given matcher.
+Matcher<CallExpr>calleeMatcher<Decl> InnerMatcher
+
Matches 1) if the call expression's callee's declaration matches the
+given matcher; or 2) if the Obj-C message expression's callee's method
+declaration matches the given matcher.
 
 Example matches y.x() (matcher = callExpr(callee(
                                    cxxMethodDecl(hasName("x")))))
   class Y { public: void x(); };
   void z() { Y y; y.x(); }
+
+Example 2. Matches [I foo] with
+objcMessageExpr(callee(objcMethodDecl(hasName("foo"))))
+
+  @interface I: NSObject
+  +(void)foo;
+  @end
+  ...
+  [I foo]
 
@@ -7166,6 +7471,31 @@ int a = b ?: 1;
+Matcher<ClassTemplateSpecializationDecl>forEachTemplateArgumentclang::ast_matchers::Matcher<TemplateArgument> InnerMatcher +
Matches classTemplateSpecialization, templateSpecializationType and
+functionDecl nodes where the template argument matches the inner matcher.
+This matcher may produce multiple matches.
+
+Given
+  template <typename T, unsigned N, unsigned M>
+  struct Matrix {};
+
+  constexpr unsigned R = 2;
+  Matrix<int, R * 2, R * 4> M;
+
+  template <typename T, typename U>
+  void f(T&& t, U&& u) {}
+
+  bool B = false;
+  f(R, B);
+templateSpecializationType(forEachTemplateArgument(isExpr(expr())))
+  matches twice, with expr() matching 'R * 2' and 'R * 4'
+functionDecl(forEachTemplateArgument(refersToType(builtinType())))
+  matches the specialization f<unsigned, bool> twice, for 'unsigned'
+  and 'bool'
+
+ + Matcher<ClassTemplateSpecializationDecl>hasAnyTemplateArgumentMatcher<TemplateArgument> InnerMatcher
Matches classTemplateSpecializations, templateSpecializationType and
 functionDecl that have at least one TemplateArgument matching the given
@@ -7343,19 +7673,38 @@ Usable as: Matcher<DeclRefExpr>throughUsingDeclMatcher<UsingShadowDecl> InnerMatcher
-
Matches a DeclRefExpr that refers to a declaration through a
-specific using shadow declaration.
+Matcher<DeclRefExpr>hasTemplateArgumentLocunsigned Index, Matcher<TemplateArgumentLoc> InnerMatcher
+
Matches template specialization `TypeLoc`s where the n'th
+`TemplateArgumentLoc` matches the given `InnerMatcher`.
 
 Given
-  namespace a { void f() {} }
+  template<typename T, typename U> class A {};
+  A<double, int> b;
+  A<int, double> c;
+varDecl(hasTypeLoc(templateSpecializationTypeLoc(hasTemplateArgumentLoc(0,
+  hasTypeLoc(loc(asString("double")))))))
+  matches `A<double, int> b`, but not `A<int, double> c`.
+
+ + +Matcher<DeclRefExpr>throughUsingDeclMatcher<UsingShadowDecl> Inner +
Matches if a node refers to a declaration through a specific
+using shadow declaration.
+
+Examples:
+  namespace a { int f(); }
   using a::f;
-  void g() {
-    f();     // Matches this ..
-    a::f();  // .. but not this.
-  }
+  int x = f();
 declRefExpr(throughUsingDecl(anything()))
-  matches f()
+  matches f
+
+  namespace a { class X{}; }
+  using a::X;
+  X x;
+typeLoc(loc(usingType(throughUsingDecl(anything()))))
+  matches X
+
+Usable as: Matcher<DeclRefExpr>, Matcher<UsingType>
 
@@ -7445,7 +7794,7 @@ declaration of class D. Matcher<DecltypeType>hasUnderlyingTypeMatcher<Type> -
Matches DecltypeType nodes to find out the underlying type.
+
Matches DecltypeType or UsingType nodes to find the underlying type.
 
 Given
   decltype(1) a = 1;
@@ -7453,7 +7802,7 @@ Given
 decltypeType(hasUnderlyingType(isInteger()))
   matches the type of "a"
 
-Usable as: Matcher<DecltypeType>
+Usable as: Matcher<DecltypeType>, Matcher<UsingType>
 
@@ -7493,7 +7842,26 @@ matches the decomposition decl with 'f' bound to "fBinding". Matcher<DoStmt>hasBodyMatcher<Stmt> InnerMatcher -

+
Matches a 'for', 'while', 'do' statement or a function definition that has
+a given body. Note that in case of functions this matcher only matches the
+definition itself and not the other declarations of the same function.
+
+Given
+  for (;;) {}
+forStmt(hasBody(compoundStmt()))
+  matches 'for (;;) {}'
+with compoundStmt()
+  matching '{}'
+
+Given
+  void f();
+  void f() {}
+functionDecl(hasBody(compoundStmt()))
+  matches 'void f() {}'
+with compoundStmt()
+  matching '{}'
+  but does not match 'void f();'
+
Matcher<DoStmt>hasConditionMatcher<Expr> InnerMatcher @@ -7505,6 +7873,22 @@ Example matches true (matcher = hasCondition(cxxBoolLiteral(equals(true))))
+Matcher<ElaboratedTypeLoc>hasNamedTypeLocMatcher<TypeLoc> InnerMatcher +
Matches elaborated `TypeLoc`s that have a named `TypeLoc` matching
+`InnerMatcher`.
+
+Given
+  template <typename T>
+  class C {};
+  class C<int> c;
+
+  class D {};
+  class D d;
+elaboratedTypeLoc(hasNamedTypeLoc(templateSpecializationTypeLoc()));
+  matches the `TypeLoc` of the variable declaration of `c`, but not `d`.
+
+ + Matcher<ElaboratedType>hasQualifierMatcher<NestedNameSpecifier> InnerMatcher
Matches ElaboratedTypes whose qualifier, a NestedNameSpecifier,
 matches InnerMatcher if the qualifier exists.
@@ -7794,7 +8178,26 @@ fieldDecl(hasInClassInitializer(anything()))
 
 
 Matcher<ForStmt>hasBodyMatcher<Stmt> InnerMatcher
-

+
Matches a 'for', 'while', 'do' statement or a function definition that has
+a given body. Note that in case of functions this matcher only matches the
+definition itself and not the other declarations of the same function.
+
+Given
+  for (;;) {}
+forStmt(hasBody(compoundStmt()))
+  matches 'for (;;) {}'
+with compoundStmt()
+  matching '{}'
+
+Given
+  void f();
+  void f() {}
+functionDecl(hasBody(compoundStmt()))
+  matches 'void f() {}'
+with compoundStmt()
+  matching '{}'
+  but does not match 'void f();'
+
Matcher<ForStmt>hasConditionMatcher<Expr> InnerMatcher @@ -7874,6 +8277,31 @@ Example matches x (matcher = expr(hasType(cxxRecordDecl(hasName("X")))))
+Matcher<FunctionDecl>forEachTemplateArgumentclang::ast_matchers::Matcher<TemplateArgument> InnerMatcher +
Matches classTemplateSpecialization, templateSpecializationType and
+functionDecl nodes where the template argument matches the inner matcher.
+This matcher may produce multiple matches.
+
+Given
+  template <typename T, unsigned N, unsigned M>
+  struct Matrix {};
+
+  constexpr unsigned R = 2;
+  Matrix<int, R * 2, R * 4> M;
+
+  template <typename T, typename U>
+  void f(T&& t, U&& u) {}
+
+  bool B = false;
+  f(R, B);
+templateSpecializationType(forEachTemplateArgument(isExpr(expr())))
+  matches twice, with expr() matching 'R * 2' and 'R * 4'
+functionDecl(forEachTemplateArgument(refersToType(builtinType())))
+  matches the specialization f<unsigned, bool> twice, for 'unsigned'
+  and 'bool'
+
+ + Matcher<FunctionDecl>hasAnyBodyMatcher<Stmt> InnerMatcher
Matches a function declaration that has a given body present in the AST.
 Note that this matcher matches all the declarations of a function whose
@@ -7944,7 +8372,26 @@ functionDecl(hasAnyTemplateArgument(refersToType(asString("int"))))
 
 
 Matcher<FunctionDecl>hasBodyMatcher<Stmt> InnerMatcher
-

+
Matches a 'for', 'while', 'do' statement or a function definition that has
+a given body. Note that in case of functions this matcher only matches the
+definition itself and not the other declarations of the same function.
+
+Given
+  for (;;) {}
+forStmt(hasBody(compoundStmt()))
+  matches 'for (;;) {}'
+with compoundStmt()
+  matching '{}'
+
+Given
+  void f();
+  void f() {}
+functionDecl(hasBody(compoundStmt()))
+  matches 'void f() {}'
+with compoundStmt()
+  matching '{}'
+  but does not match 'void f();'
+
Matcher<FunctionDecl>hasExplicitSpecifierMatcher<Expr> InnerMatcher @@ -7990,6 +8437,17 @@ matching y.
+Matcher<FunctionDecl>hasReturnTypeLocMatcher<TypeLoc> ReturnMatcher +
Matches a function declared with the specified return `TypeLoc`.
+
+Given
+  int f() { return 5; }
+  void g() {}
+functionDecl(hasReturnTypeLoc(loc(asString("int"))))
+  matches the declaration of `f`, but not `g`.
+
+ + Matcher<FunctionDecl>hasTemplateArgumentunsigned N, Matcher<TemplateArgument> InnerMatcher
Matches classTemplateSpecializations, templateSpecializationType and
 functionDecl where the n'th TemplateArgument matches the given InnerMatcher.
@@ -8083,8 +8541,6 @@ Examples matches the if statement
 Matcher<ImplicitCastExpr>hasImplicitDestinationTypeMatcher<QualType> InnerMatcher
 
Matches implicit casts whose destination type matches a given
 matcher.
-
-FIXME: Unit test this matcher
 
@@ -8171,30 +8627,49 @@ Usable as: Matcher<LambdaExpr>hasAnyCaptureMatcher<CXXThisExpr> InnerMatcher -
Matches any capture of 'this' in a lambda expression.
+Matcher<LambdaCapture>capturesVarMatcher<ValueDecl> InnerMatcher
+
Matches a `LambdaCapture` that refers to the specified `VarDecl`. The
+`VarDecl` can be a separate variable that is captured by value or
+reference, or a synthesized variable if the capture has an initializer.
 
 Given
-  struct foo {
-    void bar() {
-      auto f = [this](){};
-    }
+  void foo() {
+    int x;
+    auto f = [x](){};
+    auto g = [x = 1](){};
+  }
+In the matcher
+lambdaExpr(hasAnyCapture(lambdaCapture(capturesVar(hasName("x")))),
+capturesVar(hasName("x")) matches `x` and `x = 1`.
+
+ + +Matcher<LambdaExpr>forEachLambdaCaptureMatcher<LambdaCapture> InnerMatcher +
Matches each lambda capture in a lambda expression.
+
+Given
+  int main() {
+    int x, y;
+    float z;
+    auto f = [=]() { return x + y + z; };
   }
-lambdaExpr(hasAnyCapture(cxxThisExpr()))
-  matches [this](){};
+lambdaExpr(forEachLambdaCapture(
+    lambdaCapture(capturesVar(varDecl(hasType(isInteger()))))))
+will trigger two matches, binding for 'x' and 'y' respectively.
 
-Matcher<LambdaExpr>hasAnyCaptureMatcher<VarDecl> InnerMatcher -
Matches any capture of a lambda expression.
+Matcher<LambdaExpr>hasAnyCaptureMatcher<LambdaCapture> InnerMatcher
+
Matches any capture in a lambda expression.
 
 Given
   void foo() {
-    int x;
-    auto f = [x](){};
+    int t = 5;
+    auto f = [=](){ return t; };
   }
-lambdaExpr(hasAnyCapture(anything()))
-  matches [x](){};
+lambdaExpr(hasAnyCapture(lambdaCapture())) and
+lambdaExpr(hasAnyCapture(lambdaCapture(refersToVarDecl(hasName("t")))))
+  both match `[=](){ return t; }`.
 
@@ -8445,6 +8920,27 @@ match Base.
+Matcher<ObjCMessageExpr>calleeMatcher<Decl> InnerMatcher +
Matches 1) if the call expression's callee's declaration matches the
+given matcher; or 2) if the Obj-C message expression's callee's method
+declaration matches the given matcher.
+
+Example matches y.x() (matcher = callExpr(callee(
+                                   cxxMethodDecl(hasName("x")))))
+  class Y { public: void x(); };
+  void z() { Y y; y.x(); }
+
+Example 2. Matches [I foo] with
+objcMessageExpr(callee(objcMethodDecl(hasName("foo"))))
+
+  @interface I: NSObject
+  +(void)foo;
+  @end
+  ...
+  [I foo]
+
+ + Matcher<ObjCMessageExpr>hasAnyArgumentMatcher<Expr> InnerMatcher
Matches any argument of a call expression or a constructor call
 expression, or an ObjC-message-send expression.
@@ -8621,6 +9117,17 @@ Usable as: Matcher<PointerTypeLoc>hasPointeeLocMatcher<TypeLoc> PointeeMatcher
+
Matches pointer `TypeLoc`s that have a pointee `TypeLoc` matching
+`PointeeMatcher`.
+
+Given
+  int* x;
+pointerTypeLoc(hasPointeeLoc(loc(asString("int"))))
+  matches `int*`.
+
+ + Matcher<PointerType>pointeeMatcher<Type>
Narrows PointerType (and similar) matchers to those where the
 pointee matches a given matcher.
@@ -8732,6 +9239,18 @@ Example matches X &x and const X &y
 
+Matcher<QualifiedTypeLoc>hasUnqualifiedLocMatcher<TypeLoc> InnerMatcher +
Matches `QualifiedTypeLoc`s that have an unqualified `TypeLoc` matching
+`InnerMatcher`.
+
+Given
+  int* const x;
+  const int y;
+qualifiedTypeLoc(hasUnqualifiedLoc(pointerTypeLoc()))
+  matches the `TypeLoc` of the variable declaration of `x`, but not `y`.
+
+ + Matcher<RecordType>hasDeclarationMatcher<Decl> InnerMatcher
Matches a node if the declaration associated with that node
 matches the given matcher.
@@ -8766,6 +9285,18 @@ Usable as: Matcher<ReferenceTypeLoc>hasReferentLocMatcher<TypeLoc> ReferentMatcher
+
Matches reference `TypeLoc`s that have a referent `TypeLoc` matching
+`ReferentMatcher`.
+
+Given
+  int x = 3;
+  int& xx = x;
+referenceTypeLoc(hasReferentLoc(loc(asString("int"))))
+  matches `int&`.
+
+ + Matcher<ReferenceType>pointeeMatcher<Type>
Narrows PointerType (and similar) matchers to those where the
 pointee matches a given matcher.
@@ -9047,9 +9578,61 @@ Given
   struct X {};
   template<typename T> struct A {};
   A<X> a;
-classTemplateSpecializationDecl(hasAnyTemplateArgument(
-    refersToType(class(hasName("X")))))
-  matches the specialization A<X>
+classTemplateSpecializationDecl(hasAnyTemplateArgument(refersToType(
+  recordType(hasDeclaration(recordDecl(hasName("X")))))))
+matches the specialization of struct A generated by A<X>.
+
+ + +Matcher<TemplateSpecializationTypeLoc>hasAnyTemplateArgumentLocMatcher<TemplateArgumentLoc> InnerMatcher +
Matches template specialization `TypeLoc`s that have at least one
+`TemplateArgumentLoc` matching the given `InnerMatcher`.
+
+Given
+  template<typename T> class A {};
+  A<int> a;
+varDecl(hasTypeLoc(templateSpecializationTypeLoc(hasAnyTemplateArgumentLoc(
+  hasTypeLoc(loc(asString("int")))))))
+  matches `A<int> a`.
+
+ + +Matcher<TemplateSpecializationTypeLoc>hasTemplateArgumentLocunsigned Index, Matcher<TemplateArgumentLoc> InnerMatcher +
Matches template specialization `TypeLoc`s where the n'th
+`TemplateArgumentLoc` matches the given `InnerMatcher`.
+
+Given
+  template<typename T, typename U> class A {};
+  A<double, int> b;
+  A<int, double> c;
+varDecl(hasTypeLoc(templateSpecializationTypeLoc(hasTemplateArgumentLoc(0,
+  hasTypeLoc(loc(asString("double")))))))
+  matches `A<double, int> b`, but not `A<int, double> c`.
+
+ + +Matcher<TemplateSpecializationType>forEachTemplateArgumentclang::ast_matchers::Matcher<TemplateArgument> InnerMatcher +
Matches classTemplateSpecialization, templateSpecializationType and
+functionDecl nodes where the template argument matches the inner matcher.
+This matcher may produce multiple matches.
+
+Given
+  template <typename T, unsigned N, unsigned M>
+  struct Matrix {};
+
+  constexpr unsigned R = 2;
+  Matrix<int, R * 2, R * 4> M;
+
+  template <typename T, typename U>
+  void f(T&& t, U&& u) {}
+
+  bool B = false;
+  f(R, B);
+templateSpecializationType(forEachTemplateArgument(isExpr(expr())))
+  matches twice, with expr() matching 'R * 2' and 'R * 4'
+functionDecl(forEachTemplateArgument(refersToType(builtinType())))
+  matches the specialization f<unsigned, bool> twice, for 'unsigned'
+  and 'bool'
 
@@ -9332,16 +9915,6 @@ Usable as: Matcher<UsingDecl>hasAnyUsingShadowDeclMatcher<UsingShadowDecl> InnerMatcher -
Matches any using shadow declaration.
-
-Given
-  namespace X { void b(); }
-  using X::b;
-usingDecl(hasAnyUsingShadowDecl(hasName("b"))))
-  matches using X::b 
- - Matcher<UsingShadowDecl>hasTargetDeclMatcher<NamedDecl> InnerMatcher
Matches a using shadow declaration where the target declaration is
 matched by the given matcher.
@@ -9354,6 +9927,40 @@ usingDecl(hasAnyUsingShadowDecl(hasTargetDecl(functionDecl())))
   matches using X::b but not using X::a 
+Matcher<UsingType>hasUnderlyingTypeMatcher<Type> +
Matches DecltypeType or UsingType nodes to find the underlying type.
+
+Given
+  decltype(1) a = 1;
+  decltype(2.0) b = 2.0;
+decltypeType(hasUnderlyingType(isInteger()))
+  matches the type of "a"
+
+Usable as: Matcher<DecltypeType>, Matcher<UsingType>
+
+ + +Matcher<UsingType>throughUsingDeclMatcher<UsingShadowDecl> Inner +
Matches if a node refers to a declaration through a specific
+using shadow declaration.
+
+Examples:
+  namespace a { int f(); }
+  using a::f;
+  int x = f();
+declRefExpr(throughUsingDecl(anything()))
+  matches f
+
+  namespace a { class X{}; }
+  using a::X;
+  X x;
+typeLoc(loc(usingType(throughUsingDecl(anything()))))
+  matches X
+
+Usable as: Matcher<DeclRefExpr>, Matcher<UsingType>
+
+ + Matcher<ValueDecl>hasTypeMatcher<Decl> InnerMatcher
Overloaded to match the declaration of the expression's or value
 declaration's type.
@@ -9427,7 +10034,26 @@ variableArrayType(hasSizeExpr(ignoringImpCasts(declRefExpr(to(
 
 
 Matcher<WhileStmt>hasBodyMatcher<Stmt> InnerMatcher
-

+
Matches a 'for', 'while', 'do' statement or a function definition that has
+a given body. Note that in case of functions this matcher only matches the
+definition itself and not the other declarations of the same function.
+
+Given
+  for (;;) {}
+forStmt(hasBody(compoundStmt()))
+  matches 'for (;;) {}'
+with compoundStmt()
+  matching '{}'
+
+Given
+  void f();
+  void f() {}
+functionDecl(hasBody(compoundStmt()))
+  matches 'void f() {}'
+with compoundStmt()
+  matching '{}'
+  but does not match 'void f();'
+
Matcher<WhileStmt>hasConditionMatcher<Expr> InnerMatcher diff --git a/gnu/llvm/clang/docs/LibASTMatchersTutorial.rst b/gnu/llvm/clang/docs/LibASTMatchersTutorial.rst index 3f396dd39de..37c9f178fa8 100644 --- a/gnu/llvm/clang/docs/LibASTMatchersTutorial.rst +++ b/gnu/llvm/clang/docs/LibASTMatchersTutorial.rst @@ -399,7 +399,7 @@ in the callback. So we start with: .. code-block:: c++ - hasCondition(binaryOperator(hasOperatorName("<")) + hasCondition(binaryOperator(hasOperatorName("<"))) It makes sense to ensure that the left-hand side is a reference to a variable, and that the right-hand side has integer type. @@ -529,7 +529,7 @@ address, all we need to do is make sure neither ``ValueDecl`` (base class of } If execution reaches the end of ``LoopPrinter::run()``, we know that the -loop shell that looks like +loop shell looks like .. code-block:: c++ diff --git a/gnu/llvm/clang/docs/LibFormat.rst b/gnu/llvm/clang/docs/LibFormat.rst index 4ea84e658d1..833f768c54a 100644 --- a/gnu/llvm/clang/docs/LibFormat.rst +++ b/gnu/llvm/clang/docs/LibFormat.rst @@ -53,7 +53,7 @@ several style guides are hard-coded: FormatStyle getGoogleStyle(); /// Returns a format style complying with Chromium's style guide: - /// https://chromium.googlesource.com/chromium/src/+/master/styleguide/styleguide.md + /// https://chromium.googlesource.com/chromium/src/+/refs/heads/main/styleguide/styleguide.md FormatStyle getChromiumStyle(); /// Returns a format style complying with the GNU coding standards: diff --git a/gnu/llvm/clang/docs/MatrixTypes.rst b/gnu/llvm/clang/docs/MatrixTypes.rst index 616c88f8a47..2efebbfad93 100644 --- a/gnu/llvm/clang/docs/MatrixTypes.rst +++ b/gnu/llvm/clang/docs/MatrixTypes.rst @@ -208,7 +208,7 @@ Definitions: ``M2 __builtin_matrix_transpose(M1 matrix)`` **Remarks**: The return type is a cv-unqualified matrix type that has the same -element type as ``M1`` and has the the same number of rows as ``M1`` has columns and +element type as ``M1`` and has the same number of rows as ``M1`` has columns and the same number of columns as ``M1`` has rows. **Returns**: A matrix ``Res`` equivalent to the code below, where ``col`` refers to the diff --git a/gnu/llvm/clang/docs/MemorySanitizer.rst b/gnu/llvm/clang/docs/MemorySanitizer.rst index 3ba5ce5bed3..bcc6cc808e8 100644 --- a/gnu/llvm/clang/docs/MemorySanitizer.rst +++ b/gnu/llvm/clang/docs/MemorySanitizer.rst @@ -85,6 +85,15 @@ particular function. MemorySanitizer may still instrument such functions to avoid false positives. This attribute may not be supported by other compilers, so we suggest to use it together with ``__has_feature(memory_sanitizer)``. +``__attribute__((disable_sanitizer_instrumentation))`` +-------------------------------------------------------- + +The ``disable_sanitizer_instrumentation`` attribute can be applied to functions +to prevent all kinds of instrumentation. As a result, it may introduce false +positives and therefore should be used with care, and only if absolutely +required; for example for certain code that cannot tolerate any instrumentation +and resulting side-effects. This attribute overrides ``no_sanitize("memory")``. + Ignorelist ---------- @@ -153,16 +162,16 @@ not intermediate stores. Use-after-destruction detection =============================== -You can enable experimental use-after-destruction detection in MemorySanitizer. -After invocation of the destructor, the object will be considered no longer -readable, and using underlying memory will lead to error reports in runtime. +MemorySanitizer includes use-after-destruction detection. After invocation of +the destructor, the object will be considered no longer readable, and using +underlying memory will lead to error reports in runtime. Refer to the standard +for `lifetime `_ definition. -This feature is still experimental, in order to enable it at runtime you need -to: +This feature can be disabled with either: -#. Pass addition Clang option ``-fsanitize-memory-use-after-dtor`` during +#. Pass addition Clang option ``-fno-sanitize-memory-use-after-dtor`` during compilation. -#. Set environment variable `MSAN_OPTIONS=poison_in_dtor=1` before running +#. Set environment variable `MSAN_OPTIONS=poison_in_dtor=0` before running the program. Handling external code diff --git a/gnu/llvm/clang/docs/MisExpect.rst b/gnu/llvm/clang/docs/MisExpect.rst new file mode 100644 index 00000000000..29eb1269b89 --- /dev/null +++ b/gnu/llvm/clang/docs/MisExpect.rst @@ -0,0 +1,75 @@ +=================== +Misexpect +=================== +.. contents:: + +.. toctree:: + :maxdepth: 1 + +When developers use ``llvm.expect`` intrinsics, i.e., through use of +``__builtin_expect(...)``, they are trying to communicate how their code is +expected to behave at runtime to the optimizer. These annotations, however, can +be incorrect for a variety of reasons: changes to the code base invalidate them +silently, the developer mis-annotated them (e.g., using ``LIKELY`` instead of +``UNLIKELY``), or perhaps they assumed something incorrectly when they wrote +the annotation. Regardless of why, it is useful to detect these situations so +that the optimizer can make more useful decisions about the code. + +MisExpect diagnostics are intended to help developers identify and address +these situations, by comparing the branch weights added by the ``llvm.expect`` +intrinsic to those collected through profiling. Whenever these values are +mismatched, a diagnostic is surfaced to the user. Details on how the checks +operate in the LLVM backed can be found in LLVM's documentation. + +By default MisExpect checking is quite strict, because the use of the +``llvm.expect`` intrinsic is designed for specialized cases, where the outcome +of a condition is severely skewed. As a result, the optimizer can be extremely +aggressive, which can result in performance degradation if the outcome is less +predictable than the annotation suggests. Even when the annotation is correct +90% of the time, it may be beneficial to either remove the annotation or to use +a different intrinsic that can communicate the probability more directly. + +Because this may be too strict, MisExpect diagnostics are not enabled by +default, and support an additional flag to tolerate some deviation from the +exact thresholds. The ``-fdiagnostic-misexpect-tolerance=N`` accepts +deviations when comparing branch weights within ``N%`` of the expected values. +So passing ``-fdiagnostic-misexpect-tolerance=5`` will not report diagnostic messages +if the branch weight from the profile is within 5% of the weight added by +the ``llvm.expect`` intrinsic. + +MisExpect diagnostics are also available in the form of optimization remarks, +which can be serialized and processed through the ``opt-viewer.py`` +scripts in LLVM. + +.. option:: -Rpass=misexpect + + Enables optimization remarks for misexpect when profiling data conflicts with + use of ``llvm.expect`` intrinsics. + + +.. option:: -Wmisexpect + + Enables misexpect warnings when profiling data conflicts with use of + ``llvm.expect`` intrinsics. + +.. option:: -fdiagnostic-misexpect-tolerance=N + + Relaxes misexpect checking to tolerate profiling values within N% of the + expected branch weight. e.g., a value of ``N=5`` allows misexpect to check against + ``0.95 * Threshold`` + +LLVM supports 4 types of profile formats: Frontend, IR, CS-IR, and +Sampling. MisExpect Diagnostics are compatible with all Profiling formats. + ++----------------+--------------------------------------------------------------------------------------+ +| Profile Type | Description | ++================+======================================================================================+ +| Frontend | Profiling instrumentation added during compilation by the frontend, i.e. ``clang`` | ++----------------+--------------------------------------------------------------------------------------+ +| IR | Profiling instrumentation added during by the LLVM backend | ++----------------+--------------------------------------------------------------------------------------+ +| CS-IR | Context Sensitive IR based profiles | ++----------------+--------------------------------------------------------------------------------------+ +| Sampling | Profiles collected through sampling with external tools, such as ``perf`` on Linux | ++----------------+--------------------------------------------------------------------------------------+ + diff --git a/gnu/llvm/clang/docs/Modules.rst b/gnu/llvm/clang/docs/Modules.rst index 703ba86c68a..825d8722c4d 100644 --- a/gnu/llvm/clang/docs/Modules.rst +++ b/gnu/llvm/clang/docs/Modules.rst @@ -33,12 +33,12 @@ The ``#include`` mechanism provided by the C preprocessor is a very poor way to code into headers. * **Fragility**: ``#include`` directives are treated as textual - inclusion by the preprocessor, and are therefore subject to any - active macro definitions at the time of inclusion. If any of the - active macro definitions happens to collide with a name in the - library, it can break the library API or cause compilation failures - in the library header itself. For an extreme example, - ``#define std "The C++ Standard"`` and then include a standard + inclusion by the preprocessor, and are therefore subject to any + active macro definitions at the time of inclusion. If any of the + active macro definitions happens to collide with a name in the + library, it can break the library API or cause compilation failures + in the library header itself. For an extreme example, + ``#define std "The C++ Standard"`` and then include a standard library header: the result is a horrific cascade of failures in the C++ Standard Library's implementation. More subtle real-world problems occur when the headers for two different libraries interact @@ -102,6 +102,11 @@ Using Modules ============= To enable modules, pass the command-line flag ``-fmodules``. This will make any modules-enabled software libraries available as modules as well as introducing any modules-specific syntax. Additional `command-line parameters`_ are described in a separate section later. +Standard C++ Modules +-------------------- +.. note:: + Modules are adopted into C++20 Standard. And its semantic and command line interface are very different from the Clang C++ modules. See `StandardCPlusPlusModules `_ for details. + Objective-C Import declaration ------------------------------ Objective-C provides syntax for importing a module via an *@import declaration*, which imports the named module: @@ -158,7 +163,7 @@ Module maps are specified as separate files (each named ``module.modulemap``) al .. note:: To actually see any benefits from modules, one first has to introduce module maps for the underlying C standard library and the libraries and headers on which it depends. The section `Modularizing a Platform`_ describes the steps one must take to write these module maps. - + One can use module maps without modules to check the integrity of the use of header files. To do this, use the ``-fimplicit-module-maps`` option instead of the ``-fmodules`` option, or use ``-fmodule-map-file=`` option to explicitly specify the module map files to load. Compilation model @@ -390,7 +395,7 @@ For example, suppose: * ```` defines a macro ``getc`` (and exports its ``#define``) * ```` imports the ```` module and undefines the macro (and exports its ``#undef``) - + The ``#undef`` overrides the ``#define``, and a source file that imports both modules *in any order* will not see ``getc`` defined as a macro. Module Map Language @@ -447,7 +452,7 @@ As an example, the module map file for the C standard library might look a bit l // ...more headers follow... } -Here, the top-level module ``std`` encompasses the whole C standard library. It has a number of submodules containing different parts of the standard library: ``complex`` for complex numbers, ``ctype`` for character types, etc. Each submodule lists one of more headers that provide the contents for that submodule. Finally, the ``export *`` command specifies that anything included by that submodule will be automatically re-exported. +Here, the top-level module ``std`` encompasses the whole C standard library. It has a number of submodules containing different parts of the standard library: ``complex`` for complex numbers, ``ctype`` for character types, etc. Each submodule lists one of more headers that provide the contents for that submodule. Finally, the ``export *`` command specifies that anything included by that submodule will be automatically re-exported. Lexical structure ----------------- @@ -646,7 +651,7 @@ A header with the ``umbrella`` specifier is called an umbrella header. An umbrel .. note:: Any headers not included by the umbrella header should have - explicit ``header`` declarations. Use the + explicit ``header`` declarations. Use the ``-Wincomplete-umbrella`` warning option to ask Clang to complain about headers not covered by the umbrella header or the module map. @@ -691,7 +696,7 @@ An umbrella directory declaration specifies that all of the headers in the speci *umbrella-dir-declaration*: ``umbrella`` *string-literal* - + The *string-literal* refers to a directory. When the module is built, all of the header files in that directory (and its subdirectories) are included in the module. An *umbrella-dir-declaration* shall not refer to the same directory as the location of an umbrella *header-declaration*. In other words, only a single kind of umbrella can be specified for a given directory. @@ -719,7 +724,7 @@ A *submodule-declaration* that is an *inferred-submodule-declaration* describes *inferred-submodule-declaration*: ``explicit``:sub:`opt` ``framework``:sub:`opt` ``module`` '*' *attributes*:sub:`opt` '{' *inferred-submodule-member** '}' - + *inferred-submodule-member*: ``export`` '*' @@ -729,9 +734,9 @@ For each header included by the umbrella header or in the umbrella directory tha * Have the same name as the header (without the file extension) * Have the ``explicit`` specifier, if the *inferred-submodule-declaration* has the ``explicit`` specifier -* Have the ``framework`` specifier, if the +* Have the ``framework`` specifier, if the *inferred-submodule-declaration* has the ``framework`` specifier -* Have the attributes specified by the \ *inferred-submodule-declaration* +* Have the attributes specified by the \ *inferred-submodule-declaration* * Contain a single *header-declaration* naming that header * Contain a single *export-declaration* ``export *``, if the \ *inferred-submodule-declaration* contains the \ *inferred-submodule-member* ``export *`` @@ -914,11 +919,11 @@ Each *identifier* in the *config-macro-list* specifies the name of a macro. The A *config-macros-declaration* shall only be present on a top-level module, i.e., a module that is not nested within an enclosing module. -The ``exhaustive`` attribute specifies that the list of macros in the *config-macros-declaration* is exhaustive, meaning that no other macro definition is intended to have an effect on the API of that module. +The ``exhaustive`` attribute specifies that the list of macros in the *config-macros-declaration* is exhaustive, meaning that no other macro definition is intended to have an effect on the API of that module. .. note:: - The ``exhaustive`` attribute implies that any macro definitions + The ``exhaustive`` attribute implies that any macro definitions for macros not listed as configuration macros should be ignored completely when building the module. As an optimization, the compiler could reduce the number of unique module variants by not @@ -1062,7 +1067,7 @@ When writing a private module as part of a *framework*, it's recommended that: Modularizing a Platform ======================= -To get any benefit out of modules, one needs to introduce module maps for software libraries starting at the bottom of the stack. This typically means introducing a module map covering the operating system's headers and the C standard library headers (in ``/usr/include``, for a Unix system). +To get any benefit out of modules, one needs to introduce module maps for software libraries starting at the bottom of the stack. This typically means introducing a module map covering the operating system's headers and the C standard library headers (in ``/usr/include``, for a Unix system). The module maps will be written using the `module map language`_, which provides the tools necessary to describe the mapping between headers and modules. Because the set of headers differs from one system to the next, the module map will likely have to be somewhat customized for, e.g., a particular distribution and version of the operating system. Moreover, the system headers themselves may require some modification, if they exhibit any anti-patterns that break modules. Such common patterns are described below. diff --git a/gnu/llvm/clang/docs/OffloadingDesign.rst b/gnu/llvm/clang/docs/OffloadingDesign.rst new file mode 100644 index 00000000000..6d2c0da3128 --- /dev/null +++ b/gnu/llvm/clang/docs/OffloadingDesign.rst @@ -0,0 +1,472 @@ +============================= +Offloading Design & Internals +============================= + +.. contents:: + :local: + +Introduction +============ + +This document describes the Clang driver and code generation steps for creating +offloading applications. Clang supports offloading to various architectures +using programming models like CUDA, HIP, and OpenMP. The purpose of this +document is to illustrate the steps necessary to create an offloading +application using Clang. + +OpenMP Offloading +================= + +Clang supports OpenMP target offloading to several different architectures such +as NVPTX, AMDGPU, X86_64, Arm, and PowerPC. Offloading code is generated by +Clang and then executed using the ``libomptarget`` runtime and the associated +plugin for the target architecture, e.g. ``libomptarget.rtl.cuda``. This section +describes the steps necessary to create a functioning device image that can be +loaded by the OpenMP runtime. More information on the OpenMP runtimes can be +found at the `OpenMP documentation page `__. + +.. _Offloading Overview: + +Offloading Overview +------------------- + +The goal of offloading compilation is to create an executable device image that +can be run on the target device. OpenMP offloading creates executable images by +compiling the input file for both the host and the target device. The output +from the device phase then needs to be embedded into the host to create a fat +object. A special tool then needs to extract the device code from the fat +objects, run the device linking step, and embed the final image in a symbol the +host runtime library can use to register the library and access the symbols on +the device. + +Compilation Process +^^^^^^^^^^^^^^^^^^^ + +The compiler performs the following high-level actions to generate OpenMP +offloading code: + +* Compile the input file for the host to produce a bitcode file. Lower ``#pragma + omp target`` declarations to :ref:`offloading entries ` and create metadata to indicate which entries are on the device. +* Compile the input file for the target :ref:`device ` using + the :ref:`offloading entry ` metadata created + by the host. +* Link the OpenMP device runtime library and run the backend to create a device + object file. +* Run the backend on the host bitcode file and create a :ref:`fat object file + ` using the device object file. +* Pass the fat object file to the :ref:`linker wrapper tool ` + and extract the device objects. Run the device linking action on the extracted + objects. +* :ref:`Wrap ` the :ref:`device images ` + and :ref:`offload entries ` in a symbol that + can be accessed by the host. +* Add the :ref:`wrapped binary ` to the linker input and + run the host linking action. Link with ``libomptarget`` to register and + execute the images. + + .. _Generating Offloading Entries: + +Generating Offloading Entries +----------------------------- + +The first step in compilation is to generate offloading entries for the host. +This information is used to identify function kernels or global values that will +be provided by the device. Blocks contained in a ``#pragma omp target`` or +symbols inside a ``#pragma omp declare target`` directive will have offloading +entries generated. The following table shows the :ref:`offload entry structure +`. + + .. table:: __tgt_offload_entry Structure + :name: table-tgt_offload_entry_structure + + +---------+------------+------------------------------------------------------------------------+ + | Type | Identifier | Description | + +=========+============+========================================================================+ + | void* | addr | Address of global symbol within device image (function or global) | + +---------+------------+------------------------------------------------------------------------+ + | char* | name | Name of the symbol | + +---------+------------+------------------------------------------------------------------------+ + | size_t | size | Size of the entry info (0 if it is a function) | + +---------+------------+------------------------------------------------------------------------+ + | int32_t | flags | Flags associated with the entry (see :ref:`table-offload_entry_flags`) | + +---------+------------+------------------------------------------------------------------------+ + | int32_t | reserved | Reserved, to be used by the runtime library. | + +---------+------------+------------------------------------------------------------------------+ + +The address of the global symbol will be set to the device pointer value by the +runtime once the device image is loaded. The flags are set to indicate the +handling required for the offloading entry. If the offloading entry is an entry +to a target region it can have one of the following :ref:`entry flags +`. + + .. table:: Target Region Entry Flags + :name: table-offload_entry_flags + + +----------------------------------+-------+-----------------------------------------+ + | Name | Value | Description | + +==================================+=======+=========================================+ + | OMPTargetRegionEntryTargetRegion | 0x00 | Mark the entry as generic target region | + +----------------------------------+-------+-----------------------------------------+ + | OMPTargetRegionEntryCtor | 0x02 | Mark the entry as a global constructor | + +----------------------------------+-------+-----------------------------------------+ + | OMPTargetRegionEntryDtor | 0x04 | Mark the entry as a global destructor | + +----------------------------------+-------+-----------------------------------------+ + +If the offloading entry is a global variable, indicated by a non-zero size, it +will instead have one of the following :ref:`global +` flags. + + .. table:: Target Region Global + :name: table-offload_global_flags + + +-----------------------------+-------+---------------------------------------------------------------+ + | Name | Value | Description | + +=============================+=======+===============================================================+ + | OMPTargetGlobalVarEntryTo | 0x00 | Mark the entry as a 'to' attribute (w.r.t. the to clause) | + +-----------------------------+-------+---------------------------------------------------------------+ + | OMPTargetGlobalVarEntryLink | 0x01 | Mark the entry as a 'link' attribute (w.r.t. the link clause) | + +-----------------------------+-------+---------------------------------------------------------------+ + +The target offload entries are used by the runtime to access the device kernels +and globals that will be provided by the final device image. Each offloading +entry is set to use the ``omp_offloading_entries`` section. When the final +application is created the linker will provide the +``__start_omp_offloading_entries`` and ``__stop_omp_offloading_entries`` symbols +which are used to create the :ref:`final image `. + +This information is used by the device compilation stage to determine which +symbols need to be exported from the device. We use the ``omp_offload.info`` +metadata node to pass this information device compilation stage. + +Accessing Entries on the Device +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Accessing the entries in the device is done using the address field in the +:ref:`offload entry`. The runtime will set +the address to the pointer associated with the device image during runtime +initialization. This is used to call the corresponding kernel function when +entering a ``#pragma omp target`` region. For variables, the runtime maintains a +table mapping host pointers to device pointers. Global variables inside a +``#pragma omp target declare`` directive are first initialized to the host's +address. Once the device address is initialized we insert it into the table to +map the host address to the device address. + +Debugging Information +^^^^^^^^^^^^^^^^^^^^^ + +We generate structures to hold debugging information that is passed to +``libomptarget``. This allows the front-end to generate information the runtime +library uses for more informative error messages. This is done using the +standard :ref:`identifier structure ` used in +``libomp`` and ``libomptarget``. This is used to pass information and source +locations to the runtime. + + .. table:: ident_t Structure + :name: table-ident_t_structure + + +---------+------------+-----------------------------------------------------------------------------+ + | Type | Identifier | Description | + +=========+============+=============================================================================+ + | int32_t | reserved | Reserved, to be used by the runtime library. | + +---------+------------+-----------------------------------------------------------------------------+ + | int32_t | flags | Flags used to indicate some features, mostly unused. | + +---------+------------+-----------------------------------------------------------------------------+ + | int32_t | reserved | Reserved, to be used by the runtime library. | + +---------+------------+-----------------------------------------------------------------------------+ + | int32_t | reserved | Reserved, to be used by the runtime library. | + +---------+------------+-----------------------------------------------------------------------------+ + | char* | psource | Program source information, stored as ";filename;function;line;column;;\\0" | + +---------+------------+-----------------------------------------------------------------------------+ + +If debugging information is enabled, we will also create strings to indicate the +names and declarations of variables mapped in target regions. These have the +same format as the source location in the :ref:`identifier structure +`, but the function name is replaced with the variable +name. + +.. _Device Compilation: + +Offload Device Compilation +-------------------------- + +The input file is compiled for each active device toolchain. The device +compilation stage is performed differently from the host stage. Namely, we do +not generate any offloading entries. This is set by passing the +``-fopenmp-is-device`` flag to the front-end. We use the host bitcode to +determine which symbols to export from the device. The bitcode file is passed in +from the previous stage using the ``-fopenmp-host-ir-file-path`` flag. +Compilation is otherwise performed as it would be for any other target triple. + +When compiling for the OpenMP device, we set the visibility of all device +symbols to be ``protected`` by default. This improves performance and prevents a +class of errors where a symbol in the target device could preempt a host +library. + +The OpenMP runtime library is linked in during compilation to provide the +implementations for standard OpenMP functionality. For GPU targets this is done +by linking in a special bitcode library during compilation, (e.g. +``libomptarget-nvptx64-sm_70.bc``) using the ``-mlink-builtin-bitcode`` flag. +Other device libraries, such as CUDA's libdevice, are also linked this way. If +the target is a standard architecture with an existing ``libomp`` +implementation, that will be linked instead. Finally, device tools are used to +create a relocatable device object file that can be embedded in the host. + +.. _Creating Fat Objects: + +Creating Fat Objects +-------------------- + +A fat binary is a binary file that contains information intended for another +device. We create a fat object by embedding the output of the device compilation +stage into the host as a named section. The output from the device compilation +is passed to the host backend using the ``-fembed-offload-object`` flag. This +embeds the device image into the ``.llvm.offloading`` section using a special +binary format that behaves like a string map. This binary format is used to +bundle metadata about the image so the linker can associate the proper device +linking action with the image. Each device image will start with the magic bytes +``0x10FF10AD``. + +.. code-block:: llvm + + @llvm.embedded.object = private constant [1 x i8] c"\00", section ".llvm.offloading" + +The device code will then be placed in the corresponding section one the backend +is run on the host, creating a fat object. Using fat objects allows us to treat +offloading objects as standard host objects. The final object file should +contain the following :ref:`offloading sections `. We +will use this information when :ref:`Device Linking`. + + .. table:: Offloading Sections + :name: table-offloading_sections + + +----------------------------------+------------------------------------------------------------------------------+ + | Section | Description | + +==================================+==============================================================================+ + | omp_offloading_entries | Offloading entry information (see :ref:`table-tgt_offload_entry_structure`) | + +----------------------------------+------------------------------------------------------------------------------+ + | .llvm.offloading | Embedded device object file for the target device and architecture | + +----------------------------------+------------------------------------------------------------------------------+ + +.. _Device Linking: + +Linking Target Device Code +-------------------------- + +Objects containing :ref:`table-offloading_sections` require special handling to +create an executable device image. This is done using a Clang tool, see +:doc:`ClangLinkerWrapper` for more information. This tool works as a wrapper +over the host linking job. It scans the input object files for the offloading +section ``.llvm.offloading``. The device files stored in this section are then +extracted and passed to the appropriate linking job. The linked device image is +then :ref:`wrapped ` to create the symbols used to load +the device image and link it with the host. + +The linker wrapper tool supports linking bitcode files through link time +optimization (LTO). This is used whenever the object files embedded in the host +contain LLVM bitcode. Bitcode will be embedded for architectures that do not +support a relocatable object format, such as AMDGPU or SPIR-V, or if the user +requested it using the ``-foffload-lto`` flag. + +.. _Device Binary Wrapping: + +Device Binary Wrapping +---------------------- + +Various structures and functions are used to create the information necessary to +offload code on the device. We use the :ref:`linked device executable ` with the corresponding offloading entries to create the symbols +necessary to load and execute the device image. + +Structure Types +^^^^^^^^^^^^^^^ + +Several different structures are used to store offloading information. The +:ref:`device image structure ` stores a single +linked device image and its associated offloading entries. The offloading +entries are stored using the ``__start_omp_offloading_entries`` and +``__stop_omp_offloading_entries`` symbols generated by the linker using the +:ref:`table-tgt_offload_entry_structure`. + + .. table:: __tgt_device_image Structure + :name: table-device_image_structure + + +----------------------+--------------+----------------------------------------+ + | Type | Identifier | Description | + +======================+==============+========================================+ + | void* | ImageStart | Pointer to the target code start | + +----------------------+--------------+----------------------------------------+ + | void* | ImageEnd | Pointer to the target code end | + +----------------------+--------------+----------------------------------------+ + | __tgt_offload_entry* | EntriesBegin | Begin of table with all target entries | + +----------------------+--------------+----------------------------------------+ + | __tgt_offload_entry* | EntriesEnd | End of table (non inclusive) | + +----------------------+--------------+----------------------------------------+ + +The target :ref:`target binary descriptor ` is +used to store all binary images and offloading entries in an array. + + .. table:: __tgt_bin_desc Structure + :name: table-target_binary_descriptor + + +----------------------+------------------+------------------------------------------+ + | Type | Identifier | Description | + +======================+==================+==========================================+ + | int32_t | NumDeviceImages | Number of device types supported | + +----------------------+------------------+------------------------------------------+ + | __tgt_device_image* | DeviceImages | Array of device images (1 per dev. type) | + +----------------------+------------------+------------------------------------------+ + | __tgt_offload_entry* | HostEntriesBegin | Begin of table with all host entries | + +----------------------+------------------+------------------------------------------+ + | __tgt_offload_entry* | HostEntriesEnd | End of table (non inclusive) | + +----------------------+------------------+------------------------------------------+ + +Global Variables +---------------- + +:ref:`table-global_variables` lists various global variables, along with their +type and their explicit ELF sections, which are used to store device images and +related symbols. + + .. table:: Global Variables + :name: table-global_variables + + +--------------------------------+---------------------+-------------------------+---------------------------------------------------------+ + | Variable | Type | ELF Section | Description | + +================================+=====================+=========================+=========================================================+ + | __start_omp_offloading_entries | __tgt_offload_entry | .omp_offloading_entries | Begin symbol for the offload entries table. | + +--------------------------------+---------------------+-------------------------+---------------------------------------------------------+ + | __stop_omp_offloading_entries | __tgt_offload_entry | .omp_offloading_entries | End symbol for the offload entries table. | + +--------------------------------+---------------------+-------------------------+---------------------------------------------------------+ + | __dummy.omp_offloading.entry | __tgt_offload_entry | .omp_offloading_entries | Dummy zero-sized object in the offload entries | + | | | | section to force linker to define begin/end | + | | | | symbols defined above. | + +--------------------------------+---------------------+-------------------------+---------------------------------------------------------+ + | .omp_offloading.device_image | __tgt_device_image | .omp_offloading_entries | ELF device code object of the first image. | + +--------------------------------+---------------------+-------------------------+---------------------------------------------------------+ + | .omp_offloading.device_image.N | __tgt_device_image | .omp_offloading_entries | ELF device code object of the (N+1)th image. | + +--------------------------------+---------------------+-------------------------+---------------------------------------------------------+ + | .omp_offloading.device_images | __tgt_device_image | .omp_offloading_entries | Array of images. | + +--------------------------------+---------------------+-------------------------+---------------------------------------------------------+ + | .omp_offloading.descriptor | __tgt_bin_desc | .omp_offloading_entries | Binary descriptor object (see :ref:`binary_descriptor`) | + +--------------------------------+---------------------+-------------------------+---------------------------------------------------------+ + +.. _binary_descriptor: + +Binary Descriptor for Device Images +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +This object is passed to the offloading runtime at program startup and it +describes all device images available in the executable or shared library. It +is defined as follows: + +.. code-block:: c + + __attribute__((visibility("hidden"))) + extern __tgt_offload_entry *__start_omp_offloading_entries; + __attribute__((visibility("hidden"))) + extern __tgt_offload_entry *__stop_omp_offloading_entries; + static const char Image0[] = { }; + ... + static const char ImageN[] = { }; + static const __tgt_device_image Images[] = { + { + Image0, /*ImageStart*/ + Image0 + sizeof(Image0), /*ImageEnd*/ + __start_omp_offloading_entries, /*EntriesBegin*/ + __stop_omp_offloading_entries /*EntriesEnd*/ + }, + ... + { + ImageN, /*ImageStart*/ + ImageN + sizeof(ImageN), /*ImageEnd*/ + __start_omp_offloading_entries, /*EntriesBegin*/ + __stop_omp_offloading_entries /*EntriesEnd*/ + } + }; + static const __tgt_bin_desc BinDesc = { + sizeof(Images) / sizeof(Images[0]), /*NumDeviceImages*/ + Images, /*DeviceImages*/ + __start_omp_offloading_entries, /*HostEntriesBegin*/ + __stop_omp_offloading_entries /*HostEntriesEnd*/ + }; + + +Global Constructor and Destructor +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The global constructor (``.omp_offloading.descriptor_reg()``) registers the +device images with the runtime by calling the ``__tgt_register_lib()`` runtime +function. The constructor is explicitly defined in ``.text.startup`` section and +is run once when the program starts. Similarly, the global destructor +(``.omp_offloading.descriptor_unreg()``) calls ``__tgt_unregister_lib()`` for +the destructor and is also defined in ``.text.startup`` section and run when the +program exits. + +Offloading Example +------------------ + +This section contains a simple example of generating offloading code using +OpenMP offloading. We will use a simple ``ZAXPY`` BLAS routine. + +.. code-block:: c++ + + #include + + using complex = std::complex; + + void zaxpy(complex *X, complex *Y, complex D, std::size_t N) { + #pragma omp target teams distribute parallel for + for (std::size_t i = 0; i < N; ++i) + Y[i] = D * X[i] + Y[i]; + } + + int main() { + const std::size_t N = 1024; + complex X[N], Y[N], D; + #pragma omp target data map(to:X[0 : N]) map(tofrom:Y[0 : N]) + zaxpy(X, Y, D, N); + } + +This code is compiled using the following Clang flags. + +.. code-block:: console + + $ clang++ -fopenmp -fopenmp-targets=nvptx64 -O3 zaxpy.cpp -c + +The output section in the object file can be seen using the ``readelf`` utility. +The ``.llvm.offloading`` section has the ``SHF_EXCLUDE`` flag so it will be +removed from the final executable or shared library by the linker. + +.. code-block:: text + + $ llvm-readelf -WS zaxpy.o + Section Headers: + [Nr] Name Type Address Off Size ES Flg Lk Inf Al + [11] omp_offloading_entries PROGBITS 0000000000000000 0001f0 000040 00 A 0 0 1 + [12] .llvm.offloading PROGBITS 0000000000000000 000260 030950 00 E 0 0 8 + + +Compiling this file again will invoke the ``clang-linker-wrapper`` utility to +extract and link the device code stored at the section named +``.llvm.offloading`` and then use entries stored in +the section named ``omp_offloading_entries`` to create the symbols necessary for +``libomptarget`` to register the device image and call the entry function. + +.. code-block:: console + + $ clang++ -fopenmp -fopenmp-targets=nvptx64 zaxpy.o -o zaxpy + $ ./zaxpy + +We can see the steps created by clang to generate the offloading code using the +``-ccc-print-phases`` option in Clang. This matches the description in +:ref:`Offloading Overview`. + +.. code-block:: console + + $ clang++ -fopenmp -fopenmp-targets=nvptx64 -ccc-print-phases zaxpy.cpp + # "x86_64-unknown-linux-gnu" - "clang", inputs: ["zaxpy.cpp"], output: "/tmp/zaxpy-host.bc" + # "nvptx64-nvidia-cuda" - "clang", inputs: ["zaxpy.cpp", "/tmp/zaxpy-e6a41b.bc"], output: "/tmp/zaxpy-07f434.s" + # "nvptx64-nvidia-cuda" - "NVPTX::Assembler", inputs: ["/tmp/zaxpy-07f434.s"], output: "/tmp/zaxpy-0af7b7.o" + # "x86_64-unknown-linux-gnu" - "clang", inputs: ["/tmp/zaxpy-e6a41b.bc", "/tmp/zaxpy-0af7b7.o"], output: "/tmp/zaxpy-416cad.o" + # "x86_64-unknown-linux-gnu" - "Offload::Linker", inputs: ["/tmp/zaxpy-416cad.o"], output: "a.out" diff --git a/gnu/llvm/clang/docs/OpenCLSupport.rst b/gnu/llvm/clang/docs/OpenCLSupport.rst index 00657985521..8b68aa92711 100644 --- a/gnu/llvm/clang/docs/OpenCLSupport.rst +++ b/gnu/llvm/clang/docs/OpenCLSupport.rst @@ -17,16 +17,27 @@ OpenCL Support ================== -Clang has complete support of OpenCL C versions from 1.0 to 2.0. +Clang has complete support of OpenCL C versions from 1.0 to 3.0. +Support for OpenCL 3.0 is in experimental phase (:ref:`OpenCL 3.0 `). Clang also supports :ref:`the C++ for OpenCL kernel language `. -There is an ongoing work to support :ref:`OpenCL 3.0 `. +There are also other :ref:`new and experimental features ` +available. -There are also other :ref:`new and experimental features ` available. +Details about usage of clang for OpenCL can be found in :doc:`UsersManual`. -For general issues and bugs with OpenCL in clang refer to `Bugzilla -`__. +Missing features or with limited support +======================================== + +- For general issues and bugs with OpenCL in clang refer to `the GitHub issue + list + `__. + +- Command-line flag :option:`-cl-ext` (used to override extensions/ + features supported by a target) is missing support of some functionality i.e. that is + implemented fully through libraries (see :ref:`library-based features and + extensions `). Internals Manual ================ @@ -67,31 +78,6 @@ All the options in this section are frontend-only and therefore if used with regular clang driver they require frontend forwarding, e.g. ``-cc1`` or ``-Xclang``. -.. _opencl_cl_ext: - -.. option:: -cl-ext - -Disables support of OpenCL extensions. All OpenCL targets provide a list -of extensions that they support. Clang allows to amend this using the ``-cl-ext`` -flag with a comma-separated list of extensions prefixed with ``'+'`` or ``'-'``. -The syntax: ``-cl-ext=<(['-'|'+'][,])+>``, where extensions -can be either one of `the OpenCL published extensions -`_ -or any vendor extension. Alternatively, ``'all'`` can be used to enable -or disable all known extensions. - -Example disabling double support for the 64-bit SPIR target: - - .. code-block:: console - - $ clang -cc1 -triple spir64-unknown-unknown -cl-ext=-cl_khr_fp64 test.cl - -Enabling all extensions except double support in R600 AMD GPU can be done using: - - .. code-block:: console - - $ clang -cc1 -triple r600-unknown-unknown -cl-ext=-all,+cl_khr_fp16 test.cl - .. _opencl_finclude_default_header: .. option:: -finclude-default-header @@ -127,7 +113,7 @@ To enable modules for OpenCL: .. code-block:: console - $ clang -target spir-unknown-unknown -c -emit-llvm -Xclang -finclude-default-header -fmodules -fimplicit-module-maps -fm odules-cache-path= test.cl + $ clang -target spir-unknown-unknown -c -emit-llvm -Xclang -finclude-default-header -fmodules -fimplicit-module-maps -fmodules-cache-path= test.cl Another way to circumvent long parsing latency for the OpenCL builtin declarations is to use mechanism enabled by :ref:`-fdeclare-opencl-builtins @@ -148,7 +134,7 @@ if full functionality is required. **Example of Use**: .. code-block:: console - + $ clang -Xclang -fdeclare-opencl-builtins test.cl .. _opencl_fake_address_space_map: @@ -237,22 +223,26 @@ indicating the presence of the extension should be added to clang. The default flow for adding a new extension into the frontend is to modify `OpenCLExtensions.def -`_ +`__, +containing the list of all extensions and optional features supported by +the frontend. This will add the macro automatically and also add a field in the target options ``clang::TargetOptions::OpenCLFeaturesMap`` to control the exposure of the new extension during the compilation. -Note that by default targets like `SPIR` or `X86` expose all the OpenCL +Note that by default targets like `SPIR-V`, `SPIR` or `X86` expose all the OpenCL extensions. For all other targets the configuration has to be made explicitly. Note that the target extension support performed by clang can be overridden -with :ref:`-cl-ext ` command-line flags. +with :option:`-cl-ext` command-line flags. + +.. _opencl_ext_libs: **Library functionality** If an extension adds functionality that does not modify standard language -parsing it should not require modifying anything other than header files or +parsing it should not require modifying anything other than header files and ``OpenCLBuiltins.td`` detailed in :ref:`OpenCL builtins `. Most commonly such extensions add functionality via libraries (by adding non-native types or functions) parsed regularly. Similar to other languages this @@ -263,7 +253,9 @@ for more details refer to :ref:`the section on the OpenCL Header `. The macros indicating the presence of such extensions can be added in the standard header files conditioned on target specific predefined macros or/and language version -predefined macros. +predefined macros (see `feature/extension preprocessor macros defined in +opencl-c-base.h +`__). **Pragmas** @@ -319,24 +311,32 @@ specified in the Clang's source code. C++ for OpenCL Implementation Status ==================================== -Clang implements language version 1.0 published in `the official +Clang implements language versions 1.0 and 2021 published in `the official release of C++ for OpenCL Documentation -`_. +`_. Limited support of experimental C++ libraries is described in the :ref:`experimental features `. -Bugzilla bugs for this functionality are typically prefixed +GitHub issues for this functionality are typically prefixed with '[C++4OpenCL]' - click `here -`__ +`__ to view the full bug list. Missing features or with limited support ---------------------------------------- -- IR generation for global destructors is incomplete (See: +- Support of C++ for OpenCL 2021 is currently in experimental phase. Refer to + :ref:`OpenCL 3.0 status ` for details of common missing + functionality from OpenCL 3.0. + +- IR generation for non-trivial global destructors is incomplete (See: `PR48047 `_). +- Support of `destrutors with non-default address spaces + `_ + is incomplete (See: `D109609 `_). + .. _opencl_300: OpenCL C 3.0 Usage @@ -345,15 +345,16 @@ OpenCL C 3.0 Usage OpenCL C 3.0 language standard makes most OpenCL C 2.0 features optional. Optional functionality in OpenCL C 3.0 is indicated with the presence of feature-test macros (list of feature-test macros is `here `__). -Command-line flag :ref:`-cl-ext ` can be used to override features supported by a target. +Command-line flag :option:`-cl-ext` can be used to override features supported by a target. For cases when there is an associated extension for a specific feature (fp64 and 3d image writes) user should specify both (extension and feature) in command-line flag: .. code-block:: console - $ clang -cc1 -cl-std=CL3.0 -cl-ext=+cl_khr_fp64,+__opencl_c_fp64 ... - $ clang -cc1 -cl-std=CL3.0 -cl-ext=-cl_khr_fp64,-__opencl_c_fp64 ... + $ clang -cl-std=CL3.0 -cl-ext=+cl_khr_fp64,+__opencl_c_fp64 ... + $ clang -cl-std=CL3.0 -cl-ext=-cl_khr_fp64,-__opencl_c_fp64 ... + OpenCL C 3.0 Implementation Status @@ -362,43 +363,43 @@ OpenCL C 3.0 Implementation Status The following table provides an overview of features in OpenCL C 3.0 and their implementation status. -+------------------------------+-------------------------+-----------------------------------------+----------------------+----------------------------------------------------------------------------------------------+ -| Category | Feature | Status | Reviews | -+==============================+=========================+=========================================+======================+==============================================================================================+ -| Command line interface | New value for ``-cl-std`` flag | :good:`done` | https://reviews.llvm.org/D88300 | -+------------------------------+-------------------------+-----------------------------------------+----------------------+----------------------------------------------------------------------------------------------+ -| Predefined macros | New version macro | :good:`done` | https://reviews.llvm.org/D88300 | -+------------------------------+-------------------------+-----------------------------------------+----------------------+----------------------------------------------------------------------------------------------+ -| Predefined macros | Feature macros | :good:`done` | https://reviews.llvm.org/D95776 | -+------------------------------+-------------------------+-----------------------------------------+----------------------+----------------------------------------------------------------------------------------------+ -| Feature optionality | Generic address space | :good:`done` | https://reviews.llvm.org/D95778 and https://reviews.llvm.org/D103401 | -+------------------------------+-------------------------+-----------------------------------------+----------------------+----------------------------------------------------------------------------------------------+ -| Feature optionality | Builtin function overloads with generic address space | :good:`done` | https://reviews.llvm.org/D105526 | -+------------------------------+-------------------------+-----------------------------------------+----------------------+----------------------------------------------------------------------------------------------+ -| Feature optionality | Program scope variables in global memory | :good:`done` | https://reviews.llvm.org/D103191 | -+------------------------------+-------------------------+-----------------------------------------+----------------------+----------------------------------------------------------------------------------------------+ -| Feature optionality | 3D image writes including builtin functions | :part:`worked on` | https://reviews.llvm.org/D106260 (frontend) | -+------------------------------+-------------------------+-----------------------------------------+----------------------+----------------------------------------------------------------------------------------------+ -| Feature optionality | read_write images including builtin functions | :part:`worked on` | https://reviews.llvm.org/D104915 (frontend) and https://reviews.llvm.org/D107539 (functions) | -+------------------------------+-------------------------+-----------------------------------------+----------------------+----------------------------------------------------------------------------------------------+ -| Feature optionality | C11 atomics memory scopes, ordering and builtin function | :good:`done` | https://reviews.llvm.org/D106111 | -+------------------------------+-------------------------+-----------------------------------------+----------------------+----------------------------------------------------------------------------------------------+ -| Feature optionality | Blocks and Device-side kernel enqueue including builtin functions | :none:`unclaimed` | | -+------------------------------+-------------------------+-----------------------------------------+----------------------+----------------------------------------------------------------------------------------------+ -| Feature optionality | Pipes including builtin functions | :part:`worked on` | https://reviews.llvm.org/D107154 (frontend) and https://reviews.llvm.org/D105858 (functions) | -+------------------------------+-------------------------+-----------------------------------------+----------------------+----------------------------------------------------------------------------------------------+ -| Feature optionality | Work group collective builtin functions | :part:`worked on` | https://reviews.llvm.org/D105858 | -+------------------------------+-------------------------+-----------------------------------------+----------------------+----------------------------------------------------------------------------------------------+ -| Feature optionality | Image types and builtin functions | :good:`done` | https://reviews.llvm.org/D103911 (frontend) and https://reviews.llvm.org/D107539 (functions) | -+------------------------------+-------------------------+-----------------------------------------+----------------------+----------------------------------------------------------------------------------------------+ -| Feature optionality | Double precision floating point type | :good:`done` | https://reviews.llvm.org/D96524 | -+------------------------------+-------------------------+-----------------------------------------+----------------------+----------------------------------------------------------------------------------------------+ -| New functionality | RGBA vector components | :good:`done` | https://reviews.llvm.org/D99969 | -+------------------------------+-------------------------+-----------------------------------------+----------------------+----------------------------------------------------------------------------------------------+ -| New functionality | Subgroup functions | :part:`worked on` | https://reviews.llvm.org/D105858 | -+------------------------------+-------------------------+-----------------------------------------+----------------------+----------------------------------------------------------------------------------------------+ -| New functionality | Atomic mem scopes: subgroup, all devices including functions | :part:`worked on` | https://reviews.llvm.org/D103241 | -+------------------------------+-------------------------+-----------------------------------------+----------------------+----------------------------------------------------------------------------------------------+ ++------------------------------+-------------------------+-----------------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------------------+ +| Category | Feature | Status | Reviews | ++==============================+=========================+=========================================+======================+================================================================================================================================+ +| Command line interface | New value for ``-cl-std`` flag | :good:`done` | https://reviews.llvm.org/D88300 | ++------------------------------+-------------------------+-----------------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------------------+ +| Predefined macros | New version macro | :good:`done` | https://reviews.llvm.org/D88300 | ++------------------------------+-------------------------+-----------------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------------------+ +| Predefined macros | Feature macros | :good:`done` | https://reviews.llvm.org/D95776 | ++------------------------------+-------------------------+-----------------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------------------+ +| Feature optionality | Generic address space | :good:`done` | https://reviews.llvm.org/D95778 and https://reviews.llvm.org/D103401 | ++------------------------------+-------------------------+-----------------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------------------+ +| Feature optionality | Builtin function overloads with generic address space | :good:`done` | https://reviews.llvm.org/D105526, https://reviews.llvm.org/D107769 | ++------------------------------+-------------------------+-----------------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------------------+ +| Feature optionality | Program scope variables in global memory | :good:`done` | https://reviews.llvm.org/D103191 | ++------------------------------+-------------------------+-----------------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------------------+ +| Feature optionality | 3D image writes including builtin functions | :good:`done` | https://reviews.llvm.org/D106260 (frontend) | ++------------------------------+-------------------------+-----------------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------------------+ +| Feature optionality | read_write images including builtin functions | :good:`done` | https://reviews.llvm.org/D104915 (frontend) and https://reviews.llvm.org/D107539, https://reviews.llvm.org/D117899 (functions) | ++------------------------------+-------------------------+-----------------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------------------+ +| Feature optionality | C11 atomics memory scopes, ordering and builtin function | :good:`done` | https://reviews.llvm.org/D106111, https://reviews.llvm.org/D119420 | ++------------------------------+-------------------------+-----------------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------------------+ +| Feature optionality | Blocks and Device-side kernel enqueue including builtin functions | :good:`done` | https://reviews.llvm.org/D115640, https://reviews.llvm.org/D118605 | ++------------------------------+-------------------------+-----------------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------------------+ +| Feature optionality | Pipes including builtin functions | :good:`done` | https://reviews.llvm.org/D107154 (frontend) and https://reviews.llvm.org/D105858 (functions) | ++------------------------------+-------------------------+-----------------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------------------+ +| Feature optionality | Work group collective builtin functions | :good:`done` | https://reviews.llvm.org/D105858 | ++------------------------------+-------------------------+-----------------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------------------+ +| Feature optionality | Image types and builtin functions | :good:`done` | https://reviews.llvm.org/D103911 (frontend) and https://reviews.llvm.org/D107539 (functions) | ++------------------------------+-------------------------+-----------------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------------------+ +| Feature optionality | Double precision floating point type | :good:`done` | https://reviews.llvm.org/D96524 | ++------------------------------+-------------------------+-----------------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------------------+ +| New functionality | RGBA vector components | :good:`done` | https://reviews.llvm.org/D99969 | ++------------------------------+-------------------------+-----------------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------------------+ +| New functionality | Subgroup functions | :good:`done` | https://reviews.llvm.org/D105858, https://reviews.llvm.org/D118999 | ++------------------------------+-------------------------+-----------------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------------------+ +| New functionality | Atomic mem scopes: subgroup, all devices including functions | :good:`done` | https://reviews.llvm.org/D103241 | ++------------------------------+-------------------------+-----------------------------------------+----------------------+--------------------------------------------------------------------------------------------------------------------------------+ .. _opencl_experimenal: @@ -407,9 +408,9 @@ Experimental features Clang provides the following new WIP features for the developers to experiment and provide early feedback or contribute with further improvements. -Feel free to contact us on `cfe-dev -`_ or via `Bugzilla -`__. +Feel free to contact us on `the Discourse forums (Clang Frontend category) +`_ or file `a GitHub issue +`_. .. _opencl_experimental_cxxlibs: @@ -458,3 +459,7 @@ The possible clang invocation to compile the example is as follows: Note that `type_traits` is a header only library and therefore no extra linking step against the standard libraries is required. See full example in `Compiler Explorer `_. + +More OpenCL specific C++ library implementations built on top of libcxx +are available in `libclcxx `_ +project. diff --git a/gnu/llvm/clang/docs/OpenMPSupport.rst b/gnu/llvm/clang/docs/OpenMPSupport.rst index 88d3107c21e..16cb50afa1a 100644 --- a/gnu/llvm/clang/docs/OpenMPSupport.rst +++ b/gnu/llvm/clang/docs/OpenMPSupport.rst @@ -95,8 +95,6 @@ Features not supported or with limited support for Cuda devices - Nested parallelism: inner parallel regions are executed sequentially. -- Static linking of libraries containing device code is not supported yet. - - Automatic translation of math functions in target regions to device-specific math functions is not implemented yet. @@ -112,118 +110,119 @@ OpenMP 5.0 Implementation Details ================================= The following table provides a quick overview over various OpenMP 5.0 features -and their implementation status. Please contact *openmp-dev* at -*lists.llvm.org* for more information or if you want to help with the +and their implementation status. Please post on the +`Discourse forums (Runtimes - OpenMP category)`_ for more +information or if you want to help with the implementation. +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ |Category | Feature | Status | Reviews | +==============================+==============================================================+==========================+=======================================================================+ -| loop extension | support != in the canonical loop form | :good:`done` | D54441 | +| loop | support != in the canonical loop form | :good:`done` | D54441 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| loop extension | #pragma omp loop (directive) | :part:`worked on` | | +| loop | #pragma omp loop (directive) | :part:`worked on` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| loop extension | collapse imperfectly nested loop | :good:`done` | | +| loop | collapse imperfectly nested loop | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| loop extension | collapse non-rectangular nested loop | :good:`done` | | +| loop | collapse non-rectangular nested loop | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| loop extension | C++ range-base for loop | :good:`done` | | +| loop | C++ range-base for loop | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| loop extension | clause: if for SIMD directives | :good:`done` | | +| loop | clause: if for SIMD directives | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| loop extension | inclusive scan extension (matching C++17 PSTL) | :good:`done` | | +| loop | inclusive scan (matching C++17 PSTL) | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| memory mangagement | memory allocators | :good:`done` | r341687,r357929 | +| memory management | memory allocators | :good:`done` | r341687,r357929 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| memory mangagement | allocate directive and allocate clause | :good:`done` | r355614,r335952 | +| memory management | allocate directive and allocate clause | :good:`done` | r355614,r335952 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ | OMPD | OMPD interfaces | :part:`not upstream` | https://github.com/OpenMPToolsInterface/LLVM-openmp/tree/ompd-tests | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ | OMPT | OMPT interfaces | :part:`mostly done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| thread affinity extension | thread affinity extension | :good:`done` | | +| thread affinity | thread affinity | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| task extension | taskloop reduction | :good:`done` | | +| task | taskloop reduction | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| task extension | task affinity | :part:`not upstream` | | +| task | task affinity | :part:`not upstream` | https://github.com/jklinkenberg/openmp/tree/task-affinity | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| task extension | clause: depend on the taskwait construct | :part:`worked on` | | +| task | clause: depend on the taskwait construct | :part:`mostly done` | D113540 (regular codegen only) | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| task extension | depend objects and detachable tasks | :good:`done` | | +| task | depend objects and detachable tasks | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| task extension | mutexinoutset dependence-type for tasks | :good:`done` | D53380,D57576 | +| task | mutexinoutset dependence-type for tasks | :good:`done` | D53380,D57576 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| task extension | combined taskloop constructs | :good:`done` | | +| task | combined taskloop constructs | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| task extension | master taskloop | :good:`done` | | +| task | master taskloop | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| task extension | parallel master taskloop | :good:`done` | | +| task | parallel master taskloop | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| task extension | master taskloop simd | :good:`done` | | +| task | master taskloop simd | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| task extension | parallel master taskloop simd | :good:`done` | | +| task | parallel master taskloop simd | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| SIMD extension | atomic and simd constructs inside SIMD code | :good:`done` | | +| SIMD | atomic and simd constructs inside SIMD code | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| SIMD extension | SIMD nontemporal | :good:`done` | | +| SIMD | SIMD nontemporal | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | infer target functions from initializers | :part:`worked on` | | +| device | infer target functions from initializers | :part:`worked on` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | infer target variables from initializers | :part:`worked on` | | +| device | infer target variables from initializers | :part:`worked on` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | OMP_TARGET_OFFLOAD environment variable | :good:`done` | D50522 | +| device | OMP_TARGET_OFFLOAD environment variable | :good:`done` | D50522 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | support full 'defaultmap' functionality | :good:`done` | D69204 | +| device | support full 'defaultmap' functionality | :good:`done` | D69204 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | device specific functions | :good:`done` | | +| device | device specific functions | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | clause: device_type | :good:`done` | | +| device | clause: device_type | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | clause: extended device | :good:`done` | | +| device | clause: extended device | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | clause: uses_allocators clause | :good:`done` | | +| device | clause: uses_allocators clause | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | clause: in_reduction | :part:`worked on` | r308768 | +| device | clause: in_reduction | :part:`worked on` | r308768 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | omp_get_device_num() | :part:`worked on` | D54342 | +| device | omp_get_device_num() | :part:`worked on` | D54342 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | structure mapping of references | :none:`unclaimed` | | +| device | structure mapping of references | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | nested target declare | :good:`done` | D51378 | +| device | nested target declare | :good:`done` | D51378 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | implicitly map 'this' (this[:1]) | :good:`done` | D55982 | +| device | implicitly map 'this' (this[:1]) | :good:`done` | D55982 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | allow access to the reference count (omp_target_is_present) | :good:`done` | | +| device | allow access to the reference count (omp_target_is_present) | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | requires directive | :part:`partial` | | +| device | requires directive | :part:`partial` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | clause: unified_shared_memory | :good:`done` | D52625,D52359 | +| device | clause: unified_shared_memory | :good:`done` | D52625,D52359 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | clause: unified_address | :part:`partial` | | +| device | clause: unified_address | :part:`partial` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | clause: reverse_offload | :none:`unclaimed parts` | D52780 | +| device | clause: reverse_offload | :none:`unclaimed parts` | D52780 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | clause: atomic_default_mem_order | :good:`done` | D53513 | +| device | clause: atomic_default_mem_order | :good:`done` | D53513 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | clause: dynamic_allocators | :part:`unclaimed parts` | D53079 | +| device | clause: dynamic_allocators | :part:`unclaimed parts` | D53079 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | user-defined mappers | :part:`worked on` | D56326,D58638,D58523,D58074,D60972,D59474 | +| device | user-defined mappers | :part:`worked on` | D56326,D58638,D58523,D58074,D60972,D59474 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | mapping lambda expression | :good:`done` | D51107 | +| device | mapping lambda expression | :good:`done` | D51107 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | clause: use_device_addr for target data | :good:`done` | | +| device | clause: use_device_addr for target data | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | support close modifier on map clause | :good:`done` | D55719,D55892 | +| device | support close modifier on map clause | :good:`done` | D55719,D55892 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | teams construct on the host device | :part:`done` | r371553 | +| device | teams construct on the host device | :part:`done` | r371553 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | support non-contiguous array sections for target update | :good:`done` | | +| device | support non-contiguous array sections for target update | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | pointer attachment | :none:`unclaimed` | | +| device | pointer attachment | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | map clause reordering based on map types | :none:`unclaimed` | | +| device | map clause reordering based on map types | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| atomic extension | hints for the atomic construct | :good:`done` | D51233 | +| atomic | hints for the atomic construct | :good:`done` | D51233 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ | base language | C11 support | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ @@ -231,25 +230,25 @@ implementation. +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ | base language | lambda support | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| misc extension | array shaping | :good:`done` | D74144 | +| misc | array shaping | :good:`done` | D74144 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| misc extension | library shutdown (omp_pause_resource[_all]) | :none:`unclaimed parts` | D55078 | +| misc | library shutdown (omp_pause_resource[_all]) | :none:`unclaimed parts` | D55078 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| misc extension | metadirectives | :part:`worked on` | | +| misc | metadirectives | :part:`worked on` | D91944 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| misc extension | conditional modifier for lastprivate clause | :good:`done` | | +| misc | conditional modifier for lastprivate clause | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| misc extension | iterator and multidependences | :good:`done` | | +| misc | iterator and multidependences | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| misc extension | depobj directive and depobj dependency kind | :good:`done` | | +| misc | depobj directive and depobj dependency kind | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| misc extension | user-defined function variants | :part:`worked on` | D67294, D64095, D71847, D71830 | +| misc | user-defined function variants | :part:`worked on` | D67294, D64095, D71847, D71830, D109635 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| misc extension | pointer/reference to pointer based array reductions | :none:`unclaimed` | | +| misc | pointer/reference to pointer based array reductions | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| misc extension | prevent new type definitions in clauses | :good:`done` | | +| misc | prevent new type definitions in clauses | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| memory model extension | memory model update (seq_cst, acq_rel, release, acquire,...) | :good:`done` | | +| memory model | memory model update (seq_cst, acq_rel, release, acquire,...) | :good:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ @@ -258,91 +257,93 @@ OpenMP 5.1 Implementation Details The following table provides a quick overview over various OpenMP 5.1 features and their implementation status, as defined in the technical report 8 (TR8). -Please contact *openmp-dev* at *lists.llvm.org* for more information or if you -want to help with the implementation. +Please post on the +`Discourse forums (Runtimes - OpenMP category)`_ for more +information or if you want to help with the +implementation. +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ |Category | Feature | Status | Reviews | +==============================+==============================================================+==========================+=======================================================================+ -| atomic extension | 'compare' clause on atomic construct | :good:`worked on` | | +| atomic | 'compare' clause on atomic construct | :good:`done` | D120290, D120007, D118632, D120200, D116261, D118547, D116637 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| atomic extension | 'fail' clause on atomic construct | :none:`unclaimed` | | +| atomic | 'fail' clause on atomic construct | :part:`worked on` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ | base language | C++ attribute specifier syntax | :good:`done` | D105648 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | 'present' map type modifier | :good:`done` | D83061, D83062, D84422 | +| device | 'present' map type modifier | :good:`done` | D83061, D83062, D84422 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | 'present' motion modifier | :good:`done` | D84711, D84712 | +| device | 'present' motion modifier | :good:`done` | D84711, D84712 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | 'present' in defaultmap clause | :good:`done` | D92427 | +| device | 'present' in defaultmap clause | :good:`done` | D92427 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | map clause reordering reordering based on 'present' modifier | :none:`unclaimed` | | +| device | map clause reordering reordering based on 'present' modifier | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | device-specific environment variables | :none:`unclaimed` | | +| device | device-specific environment variables | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | omp_target_is_accessible routine | :none:`unclaimed` | | +| device | omp_target_is_accessible routine | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | omp_get_mapped_ptr routine | :none:`unclaimed` | | +| device | omp_get_mapped_ptr routine | :none:`done` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | new async target memory copy routines | :none:`unclaimed` | | +| device | new async target memory copy routines | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | thread_limit clause on target construct | :none:`unclaimed` | | +| device | thread_limit clause on target construct | :none:`worked on` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | has_device_addr clause on target construct | :none:`unclaimed` | | +| device | has_device_addr clause on target construct | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | iterators in map clause or motion clauses | :none:`unclaimed` | | +| device | iterators in map clause or motion clauses | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | indirect clause on declare target directive | :none:`unclaimed` | | +| device | indirect clause on declare target directive | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | allow virtual functions calls for mapped object on device | :none:`unclaimed` | | +| device | allow virtual functions calls for mapped object on device | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | interop construct | :part:`partial` | parsing/sema done: D98558, D98834, D98815 | +| device | interop construct | :part:`partial` | parsing/sema done: D98558, D98834, D98815 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| device extension | assorted routines for querying interoperable properties | :none:`unclaimed` | | +| device | assorted routines for querying interoperable properties | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| loop extension | Loop tiling transformation | :good:`done` | D76342 | +| loop | Loop tiling transformation | :good:`done` | D76342 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| loop extension | Loop unrolling transformation | :none:`worked on` | | +| loop | Loop unrolling transformation | :good:`done` | D99459 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| loop extension | 'reproducible'/'unconstrained' modifiers in 'order' clause | :none:`unclaimed` | | +| loop | 'reproducible'/'unconstrained' modifiers in 'order' clause | :part:`partial` | D127855 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| memory management | alignment extensions for allocate directive and clause | :part:`worked on` | | +| memory management | alignment for allocate directive and clause | :part:`worked on` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ | memory management | new memory management routines | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ | memory management | changes to omp_alloctrait_key enum | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| memory model extension | seq_cst clause on flush construct | :none:`unclaimed` | | +| memory model | seq_cst clause on flush construct | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| misc extension | 'omp_all_memory' keyword and use in 'depend' clause | :none:`unclaimed` | | +| misc | 'omp_all_memory' keyword and use in 'depend' clause | :good:`done` | D125828, D126321 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| misc extension | error directive | :none:`unclaimed` | | +| misc | error directive | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| misc extension | scope construct | :none:`unclaimed` | | +| misc | scope construct | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| misc extension | routines for controlling and querying team regions | :none:`unclaimed` | | +| misc | routines for controlling and querying team regions | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| misc extension | changes to ompt_scope_endpoint_t enum | :none:`unclaimed` | | +| misc | changes to ompt_scope_endpoint_t enum | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| misc extension | omp_display_env routine | :none:`unclaimed` | | +| misc | omp_display_env routine | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| misc extension | extended OMP_PLACES syntax | :none:`unclaimed` | | +| misc | extended OMP_PLACES syntax | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| misc extension | OMP_NUM_TEAMS and OMP_TEAMS_THREAD_LIMIT env vars | :none:`unclaimed` | | +| misc | OMP_NUM_TEAMS and OMP_TEAMS_THREAD_LIMIT env vars | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| misc extension | 'target_device' selector in context specifier | :none:`unclaimed` | | +| misc | 'target_device' selector in context specifier | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| misc extension | begin/end declare variant | :good:`done` | D71179 | +| misc | begin/end declare variant | :good:`done` | D71179 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| misc extension | dispatch construct and function variant argument adjustment | :part:`worked on` | D99537, D99679 | +| misc | dispatch construct and function variant argument adjustment | :part:`worked on` | D99537, D99679 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| misc extension | assume and assumes directives | :part:`worked on` | | +| misc | assume and assumes directives | :part:`worked on` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| misc extension | nothing directive | :none:`unclaimed` | | +| misc | nothing directive | :part:`worked on` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| misc extension | masked construct and related combined constructs | :part:`worked on` | D99995, D100514 | +| misc | masked construct and related combined constructs | :part:`worked on` | D99995, D100514 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| misc extension | default(firstprivate) & default(private) | :part:`partial` | firstprivate done: D75591 | +| misc | default(firstprivate) & default(private) | :part:`partial` | firstprivate done: D75591 | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ | other | deprecating master construct | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ @@ -354,9 +355,31 @@ want to help with the implementation. +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ | OMPT | new 'emi' callbacks for external monitoring interfaces | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| task extension | 'strict' modifier for taskloop construct | :none:`unclaimed` | | +| task | 'strict' modifier for taskloop construct | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| task extension | inoutset in depend clause | :none:`unclaimed` | | +| task | inoutset in depend clause | :none:`unclaimed` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ -| task extension | nowait clause on taskwait | :none:`unclaimed` | | +| task | nowait clause on taskwait | :part:`worked on` | | +------------------------------+--------------------------------------------------------------+--------------------------+-----------------------------------------------------------------------+ + +OpenMP Extensions +================= + +The following table provides a quick overview over various OpenMP +extensions and their implementation status. These extensions are not +currently defined by any standard, so links to associated LLVM +documentation are provided. As these extensions mature, they will be +considered for standardization. Please post on the +`Discourse forums (Runtimes - OpenMP category)`_ to provide feedback. + ++------------------------------+-----------------------------------------------------------------------------------+--------------------------+--------------------------------------------------------+ +|Category | Feature | Status | Reviews | ++==============================+===================================================================================+==========================+========================================================+ +| atomic extension | `'atomic' strictly nested within 'teams' | :good:`prototyped` | D126323 | +| | `_ | | | ++------------------------------+-----------------------------------------------------------------------------------+--------------------------+--------------------------------------------------------+ +| device extension | `'ompx_hold' map type modifier | :good:`prototyped` | D106509, D106510 | +| | `_ | | | ++------------------------------+-----------------------------------------------------------------------------------+--------------------------+--------------------------------------------------------+ + +.. _Discourse forums (Runtimes - OpenMP category): https://discourse.llvm.org/c/runtimes/openmp/35 diff --git a/gnu/llvm/clang/docs/RAVFrontendAction.rst b/gnu/llvm/clang/docs/RAVFrontendAction.rst index f6c46668fba..2e387b4b339 100644 --- a/gnu/llvm/clang/docs/RAVFrontendAction.rst +++ b/gnu/llvm/clang/docs/RAVFrontendAction.rst @@ -208,7 +208,7 @@ following CMakeLists.txt to link it: add_clang_executable(find-class-decls FindClassDecls.cpp) - target_link_libraries(find-class-decls + target_link_libraries(find-class-decls PRIVATE clangAST clangBasic @@ -224,4 +224,3 @@ declarations of a class n::m::C it found: $ ./bin/find-class-decls "namespace n { namespace m { class C {}; } }" Found declaration at 1:29 - diff --git a/gnu/llvm/clang/docs/ReleaseNotes.rst b/gnu/llvm/clang/docs/ReleaseNotes.rst index f0f303efa36..8d67ff90446 100644 --- a/gnu/llvm/clang/docs/ReleaseNotes.rst +++ b/gnu/llvm/clang/docs/ReleaseNotes.rst @@ -1,6 +1,6 @@ -======================================== -Clang 13.0.0 (In-Progress) Release Notes -======================================== +=========================================== +Clang |release| |ReleaseNotesTitle| +=========================================== .. contents:: :local: @@ -8,465 +8,1180 @@ Clang 13.0.0 (In-Progress) Release Notes Written by the `LLVM Team `_ -.. warning:: +.. only:: PreRelease - These are in-progress notes for the upcoming Clang 13 release. - Release notes for previous releases can be found on - `the Download Page `_. + .. warning:: + These are in-progress notes for the upcoming Clang |version| release. + Release notes for previous releases can be found on + `the Releases Page `_. Introduction ============ This document contains the release notes for the Clang C/C++/Objective-C -frontend, part of the LLVM Compiler Infrastructure, release 13.0.0. Here we +frontend, part of the LLVM Compiler Infrastructure, release |release|. Here we describe the status of Clang in some detail, including major improvements from the previous release and new feature work. For the general LLVM release notes, see `the LLVM -documentation `_. All LLVM -releases may be downloaded from the `LLVM releases web -site `_. +documentation `_. For the libc++ release notes, +see `this page `_. All LLVM releases +may be downloaded from the `LLVM releases web site `_. For more information about Clang or LLVM, including information about the latest release, please see the `Clang Web Site `_ or the `LLVM Web Site `_. -Note that if you are reading this file from a Git checkout or the -main Clang web page, this document applies to the *next* release, not -the current one. To see the release notes for a specific release, please -see the `releases page `_. +Potentially Breaking Changes +============================ +These changes are ones which we think may surprise users when upgrading to +Clang |release| because of the opportunity they pose for disruption to existing +code bases. + +- Clang's default C++/ObjC++ standard is now ``gnu++17`` instead of ``gnu++14``. + This means Clang will by default accept code using features from C++17 and + conforming GNU extensions. Projects incompatible with C++17 can add + ``-std=gnu++14`` to their build settings to restore the previous behaviour. + +- The ``-fexperimental-new-pass-manager`` and ``-fno-legacy-pass-manager`` + flags have been removed. These flags have been silently ignored since Clang 15. + +- Clang's resource directory path previously included the full clang version. + It now includes only the major version. The new resource directory is + ``$prefix/lib/clang/$CLANG_MAJOR_VERSION`` and can be queried using + ``clang -print-resource-dir``, just like before. + +- The ``-Wimplicit-function-declaration`` and ``-Wimplicit-int`` warnings + now default to an error in C99, C11, and C17. As of C2x, + support for implicit function declarations and implicit int has been removed, + and the warning options will have no effect. Specifying ``-Wimplicit-int`` in + C89 mode will now issue warnings instead of being a noop. + + **NOTE**: We recommend that projects using configure scripts verify that the + results do not change before/after setting + ``-Werror=implicit-function-declarations`` or ``-Wimplicit-int`` to avoid + incompatibility with Clang 16. + +- ``-Wincompatible-function-pointer-types`` now defaults to an error in all C + language modes. It may be downgraded to a warning with + ``-Wno-error=incompatible-function-pointer-types`` or disabled entirely with + ``-Wno-incompatible-function-pointer-types``. + + **NOTE:** We recommend that projects using configure scripts verify that the + results do not change before/after setting + ``-Werror=incompatible-function-pointer-types`` to avoid incompatibility with + Clang 16. -What's New in Clang 13.0.0? -=========================== - -Some of the major new features and improvements to Clang are listed -here. Generic improvements to Clang as a whole or to its underlying -infrastructure are described first, followed by language-specific -sections with improvements to Clang's support for those languages. + .. code-block:: c -Major New Features ------------------- + void func(const int *i); + void other(void) { + void (*fp)(int *) = func; // Previously a warning, now a downgradable error. + } -- Guaranteed tail calls are now supported with statement attributes - ``[[clang::musttail]]`` in C++ and ``__attribute__((musttail))`` in C. The - attribute is applied to a return statement (not a function declaration), - and an error is emitted if a tail call cannot be guaranteed, for example if - the function signatures of caller and callee are not compatible. Guaranteed - tail calls enable a class of algorithms that would otherwise use an - arbitrary amount of stack space. +- To match GCC, ``__ppc64__`` is no longer defined on PowerPC64 targets. Use + ``__powerpc64__`` instead. -Improvements to Clang's diagnostics -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +- ``-p`` is rejected for all targets which are not AIX or OpenBSD. ``-p`` led + to an ``-Wunused-command-line-argument`` warning in previous releases. -- ... +C/C++ Language Potentially Breaking Changes +------------------------------------------- -Non-comprehensive list of changes in this release -------------------------------------------------- +- Clang now disallows types whose sizes aren't a multiple of their alignments + to be used as the element type of arrays. -- The default value of _MSC_VER was raised from 1911 to 1914. MSVC 19.14 has the - support to overaligned objects on x86_32 which is required for some LLVM - passes. + .. code-block:: c -New Compiler Flags ------------------- + typedef char int8_a16 __attribute__((aligned(16))); + int8_a16 array[4]; // Now diagnosed as the element size not being a multiple of the array alignment. -- ``-Wreserved-identifier`` emits warning when user code uses reserved - identifiers. +- When compiling for Windows in MSVC compatibility mode (for example by using + clang-cl), the compiler will now propagate dllimport/export declspecs in + explicit specializations of class template member functions (`#54717 + `_): -- ``Wunused-but-set-parameter`` and ``-Wunused-but-set-variable`` emit warnings - when a parameter or a variable is set but not used. + .. code-block:: c++ -- ``-fstack-usage`` generates an extra .su file per input source file. The .su - file contains frame size information for each function defined in the source - file. + template struct __declspec(dllexport) S { + void f(); + }; + template<> void S::f() {} // clang-cl will now dllexport this. -- ``-Wnull-pointer-subtraction`` emits warning when user code may have - undefined behaviour due to subtraction involving a null pointer. + This matches what MSVC does, so it improves compatibility, but it can also + cause errors for code which clang-cl would previously accept, for example: -Deprecated Compiler Flags -------------------------- + .. code-block:: c++ -- ... + template struct __declspec(dllexport) S { + void f(); + }; + template<> void S::f() = delete; // Error: cannot delete dllexport function. -Modified Compiler Flags ------------------------ + .. code-block:: c++ -- -Wshadow now also checks for shadowed structured bindings -- ``-B `` (when ```` is a directory) was overloaded to additionally - detect GCC installations under ```` (``lib{,32,64}/gcc{,-cross}/$triple``). - This behavior was incompatible with GCC, caused interop issues with - ``--gcc-toolchain``, and was thus dropped. Specify ``--gcc-toolchain=`` - instead. ``-B``'s other GCC-compatible semantics are preserved: - ``$prefix/$triple-$file`` and ``$prefix$file`` are searched for executables, - libraries, includes, and data files used by the compiler. -- ``-Wextra`` now also implies ``-Wnull-pointer-subtraction.`` + template struct __declspec(dllimport) S { + void f(); + }; + template<> void S::f() {}; // Error: cannot define dllimport function. -Removed Compiler Flags -------------------------- + These errors also match MSVC's behavior. -- The clang-cl ``/fallback`` flag, which made clang-cl invoke Microsoft Visual - C++ on files it couldn't compile itself, has been removed. +- Clang now diagnoses indirection of ``void *`` in C++ mode as a warning which + defaults to an error. This is compatible with ISO C++, GCC, ICC, and MSVC. This + is also now a SFINAE error so constraint checking and SFINAE checking can be + compatible with other compilers. It is expected that this will be upgraded to + an error-only diagnostic in the next Clang release. -- ``-Wreturn-std-move-in-c++11``, which checked whether an entity is affected by - `CWG1579 `_ to become implicitly movable, has been - removed. + .. code-block:: c++ -New Pragmas in Clang --------------------- + void func(void *p) { + *p; // Now diagnosed as a warning-as-error. + } -- ... +- Clang now diagnoses use of a bit-field as an instruction operand in Microsoft + style inline asm blocks as an error. Previously, a bit-field operand yielded + the address of the allocation unit the bit-field was stored within; reads or + writes therefore had the potential to read or write nearby bit-fields. + (`#57791 `_) -Attribute Changes in Clang --------------------------- + .. code-block:: c++ -- ... + typedef struct S { + unsigned bf:1; + } S; + void f(S s) { + __asm { + mov eax, s.bf // Now diagnosed as an error. + mov s.bf, eax // Now diagnosed as an error. + } + } + +- Clang now diagnoses if structs/unions with the same name are different in + different used modules. Behavior in C and Objective-C language modes now is + the same as in C++. + +C++ Specific Potentially Breaking Changes +----------------------------------------- +- Clang now prohibits non-inline externally-visible definitions in C++ + standard header units as per ``[module.import/6]``. In Clang 15, + these definitions were allowed. Note that such definitions are ODR + violations if the header is included more than once. + +- Clang will now correctly diagnose as ill-formed a constant expression where an + enum without a fixed underlying type is set to a value outside the range of + the enumeration's values. -- Added support for C++11-style ``[[]]`` attributes on using-declarations, as a - clang extension. + .. code-block:: c++ -Windows Support ---------------- + enum E { Zero, One, Two, Three, Four }; + constexpr E Val1 = (E)3; // Ok + constexpr E Val2 = (E)7; // Ok + constexpr E Val3 = (E)8; // Now diagnosed as out of the range [0, 7] + constexpr E Val4 = (E)-1; // Now diagnosed as out of the range [0, 7] -- Fixed reading ``long double`` arguments with ``va_arg`` on x86_64 MinGW - targets. + Due to the extended period of time this bug was present in major C++ + implementations (including Clang), this error has the ability to be + downgraded into a warning (via: ``-Wno-error=enum-constexpr-conversion``) to + provide a transition period for users. This diagnostic is expected to turn + into an error-only diagnostic in the next Clang release. + (`#50055 `_) -C Language Changes in Clang ---------------------------- +- As a side effect of implementing DR692/DR1395/DR1432, Clang now rejects some + overloaded function templates as ambiguous when one of the candidates has a + trailing parameter pack. -- ... + .. code-block:: c++ -C++ Language Changes in Clang ------------------------------ + template void g(T, T = T()); + template void g(T, U...); + void h() { + // This is rejected due to ambiguity between the pack and the + // default argument. Only parameters with arguments are considered during + // partial ordering of function templates. + g(42); + } -- The oldest supported GNU libstdc++ is now 4.8.3 (released 2014-05-22). - Clang workarounds for bugs in earlier versions have been removed. +ABI Changes in This Version +--------------------------- +- GCC doesn't pack non-POD members in packed structs unless the packed + attribute is also specified on the member. Clang historically did perform + such packing. Clang now matches the gcc behavior + (except on Darwin, PS4 and AIX). + You can switch back to the old ABI behavior with the flag: + ``-fclang-abi-compat=15.0``. +- GCC allows POD types to have defaulted special members. Clang historically + classified such types as non-POD (for the purposes of Itanium ABI). Clang now + matches the gcc behavior (except on Darwin, PS4, AIX and z/OS). You can switch + back to the old ABI behavior with the flag: ``-fclang-abi-compat=15.0``. + +What's New in Clang |release|? +============================== +Some of the major new features and improvements to Clang are listed +here. Generic improvements to Clang as a whole or to its underlying +infrastructure are described first, followed by language-specific +sections with improvements to Clang's support for those languages. -- ... +C++ Language Changes +-------------------- C++20 Feature Support ^^^^^^^^^^^^^^^^^^^^^ -... + +Newly implemented papers: + +- Implemented `P0848: Conditionally Trivial Special Member Functions `_. + Note: The handling of deleted functions is not yet compliant, as Clang + does not implement `DR1496 `_ + and `DR1734 `_. + +- Implemented `P1091R3 `_ and `P1381R1 `_ to + support capturing structured bindings in lambdas (`#52720 `_, + `#54300 `_, + `#54301 `_, + `#49430 `_). + +- Implemented `P2468R2: The Equality Operator You Are Looking For `_. + +- Implemented `P2113R0: Proposed resolution for 2019 comment CA 112 `_ + ([temp.func.order]p6.2.1 is not implemented, matching GCC). + +- Implemented `P0634R3: Down with typename! `_, + which removes the requirement for the ``typename`` keyword in certain contexts. + +- Implemented `P0857R0: Fixing small-ish functionality gaps in constraints `_, + which specifies constrained lambdas and constrained template *template-parameter*\s. + +- Implemented `P0960R3 `_ + and `P1975R0 `_, + which allow parenthesized aggregate-initialization. + +Notable Bug Fixes to C++20 Features: + +- Clang now correctly delays the instantiation of function constraints until + the time of checking, which should now allow the libstdc++ ranges implementation + to work for at least trivial examples. + (`#44178 `_) + +- Consider explicitly defaulted constexpr/consteval special member function + template instantiation to be constexpr/consteval even though a call to such + a function cannot appear in a constant expression. + (C++14 [dcl.constexpr]p6 (CWG DR647/CWG DR1358)) + +- Correctly defer dependent immediate function invocations until template instantiation. + (`#55601 `_) + +- Correctly set expression evaluation context as 'immediate function context' in + consteval functions. + (`#51182 `_) + +- Skip rebuilding lambda expressions in arguments of immediate invocations. + (`#56183 `_, + `#51695 `_, + `#50455 `_, + `#54872 `_, + `#54587 `_) + +- Clang implements DR2621, correcting a defect in ``using enum`` handling. The + name is found via ordinary lookup so typedefs are found. + +- Implemented CWG2635 as a Defect Report, which prohibits structured bindings from being constrained. + +- When using header modules, inclusion of a private header and violations of + the `use-declaration rules + `_ are now + diagnosed even when the includer is a textual header. This change can be + temporarily reversed with ``-Xclang + -fno-modules-validate-textual-header-includes``, but this flag will be + removed in a future Clang release. C++2b Feature Support ^^^^^^^^^^^^^^^^^^^^^ -... +- Implemented `P2324R2: Support label at end of compound statement `_. +- Implemented `P1169R4: static operator() `_ and `P2589R1: static operator[] `_. +- Implemented `P2513R3: char8_t Compatibility and Portability Fix `_. + This change was applied to C++20 as a Defect Report. +- Implemented `P2647R1: Permitting static constexpr variables in constexpr functions `_. +- Implemented `CWG2640: Allow more characters in an n-char sequence `_. + +Resolutions to C++ Defect Reports +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +- Implemented `DR692 `_, `DR1395 `_, + and `DR1432 `_. The fix for DR1432 is speculative since the + issue is still open and has no proposed resolution at this time. A speculative fix + for DR1432 is needed to prevent regressions that would otherwise occur due to DR692. +- Implemented `DR2358 `_, which allows init captures in lambdas in default arguments. +- Implemented `DR2654 `_ which undeprecates + all compound assignments operations on volatile qualified variables. +- Implemented `DR2631 `_. Invalid ``consteval`` calls in default arguments and default + member initializers are diagnosed when and if the default is used. + This changes the value of ``std::source_location::current()`` + used in default parameters calls compared to previous versions of Clang. + (`#56379 `_) + +C Language Changes +------------------ +- Adjusted ``-Wformat`` warnings according to `WG14 N2562 `_. + Clang will now consider default argument promotions in ``printf``, and remove + unnecessary warnings. Especially ``int`` argument with specifier ``%hhd`` and + ``%hd``. + +C2x Feature Support +^^^^^^^^^^^^^^^^^^^ +- Implemented `WG14 N2662 `_, + so the ``[[maybe_unused]]`` attribute may be applied to a label to silence an + ``-Wunused-label`` warning. +- Implemented `WG14 N2508 `_, + so labels can placed everywhere inside a compound statement. +- Implemented `WG14 N2927 `_, + the Not-so-magic ``typeof`` operator. Also implemented + `WG14 N2930 `_, + renaming ``remove_quals``, so the ``typeof_unqual`` operator is also + supported. Both of these operators are supported only in C2x mode. The + ``typeof`` operator specifies the type of the given parenthesized expression + operand or type name, including all qualifiers. The ``typeof_unqual`` + operator is similar to ``typeof`` except that all qualifiers are removed, + including atomic type qualification and type attributes which behave like a + qualifier, such as an address space attribute. -Objective-C Language Changes in Clang -------------------------------------- + .. code-block:: c -OpenCL Kernel Language Changes in Clang ---------------------------------------- + __attribute__((address_space(1))) const _Atomic int Val; + typeof(Val) OtherVal; // type is '__attribute__((address_space(1))) const _Atomic int' + typeof_unqual(Val) OtherValUnqual; // type is 'int' +- Implemented `WG14 N3042 `_, + Introduce the nullptr constant. This introduces a new type ``nullptr_t``, + declared in ```` which represents the type of the null pointer named + constant, ``nullptr``. This constant is implicitly convertible to any pointer + type and represents a type-safe null value. -Command-line interface changes: + Note, there are some known incompatibilities with this same feature in C++. + The following examples were discovered during implementation and are subject + to change depending on how national body comments are resolved by WG14 (C + status is based on standard requirements, not necessarily implementation + behavior): -- All builtin types, macros and function declarations are now added by default - without any command-line flags. A flag is provided ``-cl-no-stdinc`` to - suppress the default declarations non-native to the compiler. + .. code-block:: c -- Clang now compiles using OpenCL C version 1.2 by default if no version is - specified explicitly from the command line. + nullptr_t null_val; + (nullptr_t)nullptr; // Rejected in C, accepted in C++, Clang accepts + (void)(1 ? nullptr : 0); // Rejected in C, accepted in C++, Clang rejects + (void)(1 ? null_val : 0); // Rejected in C, accepted in C++, Clang rejects + bool b1 = nullptr; // Accepted in C, rejected in C++, Clang rejects + b1 = null_val; // Accepted in C, rejected in C++, Clang rejects + null_val = 0; // Rejected in C, accepted in C++, Clang rejects -- Clang now supports ``.clcpp`` file extension for sources written in - C++ for OpenCL. + void func(nullptr_t); + func(0); // Rejected in C, accepted in C++, Clang rejects -- Clang now accepts ``-cl-std=clc++1.0`` that sets C++ for OpenCL to - the version 1.0 explicitly. +- Implemented `WG14 N2975 `_, + Relax requirements for va_start. In C2x mode, functions can now be declared + fully variadic and the ``va_start`` macro no longer requires passing a second + argument (though it accepts a second argument for backwards compatibility). + If a second argument is passed, it is neither expanded nor evaluated in C2x + mode. -Misc common changes: + .. code-block:: c -- Added ``NULL`` definition in internal headers for standards prior to the - version 2.0. + void func(...) { // Invalid in C17 and earlier, valid in C2x and later. + va_list list; + va_start(list); // Invalid in C17 and earlier, valid in C2x and later. + va_end(list); + } -- Simplified use of pragma in extensions for ``double``, images, atomics, - subgroups, Arm dot product extension. There are less cases where extension - pragma is now required by clang to compile kernel sources. +- Diagnose type definitions in the ``type`` argument of ``__builtin_offsetof`` + as a conforming C extension according to + `WG14 N2350 `_. + Also documents the builtin appropriately. Note, a type definition in C++ + continues to be rejected. -- Added missing ``as_size``/``as_ptrdiff``/``as_intptr``/``as_uintptr_t`` - operators to internal headers. +OpenCL Kernel Language Changes +------------------------------ -- Added new builtin function for ndrange, ``cl_khr_subgroup_extended_types``, - ``cl_khr_subgroup_non_uniform_vote``, ``cl_khr_subgroup_ballot``, - ``cl_khr_subgroup_non_uniform_arithmetic``, ``cl_khr_subgroup_shuffle``, - ``cl_khr_subgroup_shuffle_relative``, ``cl_khr_subgroup_clustered_reduce`` - into the default Tablegen-based header. +- Improved diagnostics for C++ templates used in kernel arguments. +- Removed redundant pragma for the ``arm-integer-dot-product`` extension. +- Improved support of enqueued block for AMDGPU. +- Added ``nounwind`` attribute implicitly to all functions. +- Improved builtin functions support: -- Added online documentation for Tablegen-based header, OpenCL 3.0 support, - new clang extensions. + * Allow disabling default header-based feature/extension support by passing ``-D__undef_``. + * Fixed conditional definition of the depth image and ``read_write image3d`` builtins. -- Fixed OpenCL C language version and SPIR address space reporting in DWARF. +Non-comprehensive list of changes in this release +------------------------------------------------- +- It's now possible to set the crash diagnostics directory through + the environment variable ``CLANG_CRASH_DIAGNOSTICS_DIR``. + The ``-fcrash-diagnostics-dir`` flag takes precedence. + +- Unicode support has been updated to support Unicode 15.0. + New unicode codepoints are supported as appropriate in diagnostics, + C and C++ identifiers, and escape sequences. + +- In identifiers, Clang allows a restricted set of additional mathematical symbols + as an extension. These symbols correspond to a proposed Unicode + `Mathematical notation profile for default identifiers + `_. + (`#54732 `_) + +- Clang now supports loading multiple configuration files. The files from + default configuration paths are loaded first, unless ``--no-default-config`` + option is used. All files explicitly specified using ``--config=`` option + are loaded afterwards. + +- When loading default configuration files, clang now unconditionally uses + the real target triple (respecting options such as ``--target=`` and ``-m32``) + rather than the executable prefix. The respective configuration files are + also loaded when clang is called via an executable without a prefix (e.g. + plain ``clang``). + +- Default configuration paths were partially changed. Clang now attempts to load + ``-.cfg`` first, and falls back to loading both + ``.cfg`` and ``.cfg`` if the former is not found. `Triple` + is the target triple and `driver` first tries the canonical name + for the driver (respecting ``--driver-mode=``), and then the name found + in the executable. + +- If the environment variable ``SOURCE_DATE_EPOCH`` is set, it specifies a UNIX + timestamp to be used in replacement of the current date and time in + the ``__DATE__``, ``__TIME__``, and ``__TIMESTAMP__`` macros. See + ``_. + +- Clang now supports ``__has_constexpr_builtin`` function-like macro that + evaluates to 1 if the builtin is supported and can be constant evaluated. + It can be used to writing conditionally constexpr code that uses builtins. + +- The time profiler (using ``-ftime-trace`` option) now traces various constant + evaluation events. + +- Clang can now generate a PCH when using ``-fdelayed-template-parsing`` for + code with templates containing loop hint pragmas, OpenMP pragmas, and + ``#pragma unused``. -New extensions: +New Compiler Flags +------------------ -- ``cl_khr_integer_dot_product`` for dedicated support of dot product. +- Implemented ``-fcoro-aligned-allocation`` flag. This flag implements + Option 2 of P2014R0 aligned allocation of coroutine frames + (`P2014R0 `_). + With this flag, the coroutines will try to lookup aligned allocation + function all the time. The compiler will emit an error if it fails to + find aligned allocation function. So if the user code implemented self + defined allocation function for coroutines, the existing code will be + broken. A little divergence with P2014R0 is that clang will lookup + ``::operator new(size_­t, std::aligned_val_t, nothrow_­t)`` if there is + ``get_­return_­object_­on_­allocation_­failure``. We feel this is more consistent + with the intention. + +- Added ``--no-default-config`` to disable automatically loading configuration + files using default paths. + +- Added the new level, ``3``, to the ``-fstrict-flex-arrays=`` flag. The new + level is the strict, standards-conforming mode for flexible array members. It + recognizes only incomplete arrays as flexible array members (which is how the + feature is defined by the C standard). -- ``cl_khr_extended_bit_ops`` for dedicated support of extra binary operations. + .. code-block:: c -- ``__cl_clang_bitfields`` for use of bit-fields in the kernel code. + struct foo { + int a; + int b[]; // Flexible array member. + }; -- ``__cl_clang_non_portable_kernel_param_types`` for relaxing some restrictions - to types of kernel parameters. + struct bar { + int a; + int b[0]; // NOT a flexible array member. + }; -OpenCL C 3.0 related changes: +- Added ``-fmodule-output`` to enable the one-phase compilation model for + standard C++ modules. See + `Standard C++ Modules `_ + for more information. -- Added parsing support for the optionality of generic address space, images - (including 3d writes and ``read_write`` access qualifier), pipes, program - scope variables, double-precision floating-point support. +- Added ``-Rpass-analysis=stack-frame-layout`` which will emit new diagnostic + information about the layout of stack frames through the remarks + infrastructure. Since it uses remarks the diagnostic information is available + both on the CLI, and in a machine readable format. -- Added optionality support for builtin functions (in ``opencl-c.h`` header) - for generic address space, C11 atomics. +Deprecated Compiler Flags +------------------------- +- ``-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang`` + has been deprecated. The flag will be removed in Clang 18. + ``-ftrivial-auto-var-init=zero`` is now available unconditionally, to be + compatible with GCC. +- ``-fcoroutines-ts`` has been deprecated. The flag will be removed in Clang 17. + Please use ``-std=c++20`` or higher to use standard C++ coroutines instead. +- ``-fmodules-ts`` has been deprecated. The flag will be removed in Clang 17. + Please use ``-std=c++20`` or higher to use standard C++ modules instead. -- Added ``memory_scope_all_devices`` enum for the atomics in internal headers. +Modified Compiler Flags +----------------------- +- Clang now permits specifying ``--config=`` multiple times, to load multiple + configuration files. -- Enabled use of ``.rgba`` vector components. +- The option ``-rtlib=platform`` can now be used for all targets to override + a different option value (either one set earlier on the command line, or a + built-in hardcoded default). (Previously the MSVC and Darwin targets didn't + allow this parameter combination.) -C++ for OpenCL related changes: +Removed Compiler Flags +------------------------- +- Clang now no longer supports ``-cc1 -fconcepts-ts``. This flag has been deprecated + and encouraged use of ``-std=c++20`` since Clang 10, so we're now removing it. -- Added ``__remove_address_space`` metaprogramming utility in internal headers - to allow removing address spaces from types. +Attribute Changes in Clang +-------------------------- +- Added support for ``__attribute__((guard(nocf)))`` and C++-style + ``[[clang::guard(nocf)]]``, which is equivalent to ``__declspec(guard(nocf))`` + when using the MSVC environment. This is to support enabling Windows Control + Flow Guard checks with the ability to disable them for specific functions when + using the MinGW environment. This attribute is only available for Windows + targets. -- Improved overloads resolution logic for constructors wrt address spaces. +- Introduced a new function attribute ``__attribute__((nouwtable))`` to suppress + LLVM IR ``uwtable`` function attribute. + +- Updated the value returned by ``__has_c_attribute(nodiscard)`` to ``202003L`` + based on the final date specified by the C2x committee draft. We already + supported the ability to specify a message in the attribute, so there were no + changes to the attribute behavior. + +- Updated the value returned by ``__has_c_attribute(fallthrough)`` to ``201910L`` + based on the final date specified by the C2x committee draft. We previously + used ``201904L`` (the date the proposal was seen by the committee) by mistake. + There were no other changes to the attribute behavior. + +- Introduced a new record declaration attribute ``__attribute__((enforce_read_only_placement))`` + to support analysis of instances of a given type focused on read-only program + memory placement. It emits a warning if something in the code provably prevents + an instance from a read-only memory placement. + +- Introduced new attribute ``__attribute__((target_version("cpu_features")))`` + and expanded the functionality of the existing attribute + ``__attribute__((target_clones("cpu_features1","cpu_features2",...)))`` to + support Function Multi Versioning on AArch64 target. It detects at runtime + which function versions are supported by CPU and calls the one with highest + priority. Refer to `clang attributes + `_ for + more details. -- Improved diagnostics of OpenCL specific types and address space qualified - types in ``reinterpret_cast`` and template functions. +Improvements to Clang's diagnostics +----------------------------------- +- Disabled a FIX-IT suggested for a case of bad conversion in system headers. + +- Clang will now check compile-time determinable string literals as format strings. + (`#55805 `_) + +- ``-Wformat`` now recognizes ``%b`` for the ``printf``/``scanf`` family of + functions and ``%B`` for the ``printf`` family of functions. + (`#56885 `_) + +- Introduced ``-Wsingle-bit-bitfield-constant-conversion``, grouped under + ``-Wbitfield-constant-conversion``, which diagnoses implicit truncation when + ``1`` is assigned to a 1-bit signed integer bitfield. To reduce + potential false positives, this diagnostic will not diagnose use of the + ``true`` macro (from ````) in C language mode despite the macro + being defined to expand to ``1``. (`#53253 `_) + +- Clang will now print more information about failed static assertions. In + particular, simple static assertion expressions are evaluated to their + compile-time value and printed out if the assertion fails. + +- Diagnostics about uninitialized ``constexpr`` variables have been improved + to mention the missing constant initializer. + +- Correctly diagnose a future keyword if it exists as a keyword in the higher + language version and specifies in which version it will be a keyword. This + supports both C and C++. + +- ``no_sanitize("...")`` on a global variable for known but not relevant + sanitizers is now just a warning. It now says that this will be ignored + instead of incorrectly saying no_sanitize only applies to functions and + methods. + +- No longer mention ``reinterpet_cast`` in the invalid constant expression + diagnostic note when in C mode. + +- Clang will now give a more suitale diagnostic for declaration of block + scope identifiers that have external/internal linkage that has an initializer. + (`#57478 `_) + +- A new analysis pass will helps preserve sugar when combining deductions, in an + order agnostic way. This will be in effect when deducing template arguments, + when deducing function return type from multiple return statements, for the + conditional operator, and for most binary operations. Type sugar is combined + in a way that strips the sugar which is different between terms, and preserves + those which are common. -- Fixed ``NULL`` macro in internal headers to be compatible with C++. +- Correctly diagnose the use of an integer literal without a suffix whose + underlying type is ``long long`` or ``unsigned long long`` as an extension in + C89 mode . Clang previously only diagnosed if the literal had an explicit + ``LL`` suffix. + +- Clang now correctly diagnoses index that refers past the last possible element + of FAM-like arrays. + +- Clang now correctly emits a warning when dereferencing a void pointer in C mode. + (`#53631 `_) + +- Clang will now diagnose an overload set where a candidate has a constraint that + refers to an expression with a previous error as nothing viable, so that it + doesn't generate strange cascading errors, particularly in cases where a + subsuming constraint fails, which would result in a less-specific overload to + be selected. + +- Add a fix-it hint for the ``-Wdefaulted-function-deleted`` warning to + explicitly delete the function. + +- Fixed an accidental duplicate diagnostic involving the declaration of a + function definition without a prototype which is preceded by a static + declaration of the function with a prototype. + (`#58181 `_) + +- Copy-elided initialization of lock scopes is now handled differently in + ``-Wthread-safety-analysis``: annotations on the move constructor are no + longer taken into account, in favor of annotations on the function returning + the lock scope by value. This could result in new warnings if code depended + on the previous undocumented behavior. As a side effect of this change, + constructor calls outside of initializer expressions are no longer ignored, + which can result in new warnings (or make existing warnings disappear). + +- The wording of diagnostics regarding arithmetic on fixed-sized arrays and + pointers is improved to include the type of the array and whether it's cast + to another type. This should improve comprehension for why an index is + out-of-bounds. + +- Clang now correctly points to the problematic parameter for the ``-Wnonnull`` + warning. (`#58273 `_) + +- Introduced ``-Wcast-function-type-strict`` and + ``-Wincompatible-function-pointer-types-strict`` to warn about function type + mismatches in casts and assignments that may result in runtime indirect call + `Control-Flow Integrity (CFI) + `_ failures. The + ``-Wcast-function-type-strict`` diagnostic is grouped under + ``-Wcast-function-type`` as it identifies a more strict set of potentially + problematic function type casts. + +- Clang will now disambiguate NTTP types when printing diagnostic that contain NTTP types. + (`#57562 `_) + +- Better error recovery for pack expansion of expressions. + (`#58673 `_) -- Fixed use of ``half`` type. +- Better diagnostics when the user has missed ``auto`` in a declaration. + (`#49129 `_) -ABI Changes in Clang --------------------- +- Clang now diagnoses use of invalid or reserved module names in a module + export declaration. Both are diagnosed as an error, but the diagnostic is + suppressed for use of reserved names in a system header. -OpenMP Support in Clang ------------------------ +- ``-Winteger-overflow`` will diagnose overflow in more cases. + (`#58944 `_) + +- Clang has an internal limit of 2GB of preprocessed source code per + compilation, including source reachable through imported AST files such as + PCH or modules. When Clang hits this limit, it now produces notes mentioning + which header and source files are consuming large amounts of this space. + ``#pragma clang __debug sloc_usage`` can also be used to request this report. -- Support for loop transformation directives from OpenMP 5.1 have been added. - ``#pragma omp unroll`` is a standardized alternative to ``#pragma unroll`` - (or ``#pragma clang loop unroll(enable)``) but also allows composition with - other OpenMP loop associated constructs as in +- Clang no longer permits the keyword 'bool' in a concept declaration as a + concepts-ts compatibility extension. - .. code-block:: c +- Clang now diagnoses overflow undefined behavior in a constant expression while + evaluating a compound assignment with remainder as operand. + +- Add ``-Wreturn-local-addr``, a GCC alias for ``-Wreturn-stack-address``. - #pragma omp parallel for - #pragma omp unroll partial(4) - for (int i = 0; i < n; ++i) +- Clang now suppresses ``-Wlogical-op-parentheses`` on ``(x && a || b)`` and ``(a || b && x)`` + only when ``x`` is a string literal. - ``#pragma omp tile`` applies tiling to a perfect loop nest using a - user-defined tile size. +- Clang will now reject the GNU extension address of label in coroutines explicitly. + (`#56436 `_) - .. code-block:: c +- Clang now automatically adds ``[[clang::lifetimebound]]`` to the parameters of + ``std::move, std::forward`` et al, this enables Clang to diagnose more cases + where the returned reference outlives the object. + +- Fix clang not properly diagnosing the failing subexpression when chained + binary operators are used in a ``static_assert`` expression. - #pragma omp tile sizes(8,8) - for (int i = 0; i < m; ++i) - for (int j = 0; j < n; ++j) +- ``-Wtautological-compare`` missed warnings for tautological comparisons + involving a negative integer literal. + (`#42918 `_) -- ... +- ``-Wcomma`` is no longer emitted for void returning functions. + (`#57151 `_) -CUDA Support in Clang ---------------------- +Bug Fixes in This Version +------------------------- -- ... +- Fix crash when attempting to perform parenthesized initialization of an + aggregate with a base class with only non-public constructors. + (`#62296 `_) +- Fix crash when handling nested immediate invocations in initializers of global + variables. + (`#58207 `_) +- Fix crash when passing a braced initializer list to a parentehsized aggregate + initialization expression. + (`#63008 `_). -X86 Support in Clang --------------------- +Bug Fixes to Compiler Builtins +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- ... +- ``stdatomic.h`` will use the internal declarations when targeting pre-C++-23 + on Windows platforms as the MSVC support requires newer C++ standard. -Internal API Changes --------------------- +- Correct ``_Static_assert`` to accept the same set of extended integer + constant expressions as is accpted in other contexts that accept them. + (`#57687 `_) -These are major API changes that have happened since the 12.0.0 release of -Clang. If upgrading an external codebase that uses Clang as a library, -this section should help get you past the largest hurdles of upgrading. +- Fix crashes caused when builtin C++ language extension type traits were + instantiated by templates with an unexpected number of arguments. + (`#57008 `_) -- ... +- Fix ``__builtin_assume_aligned`` crash when the 1st arg is array type. + (`#57169 `_) -Build System Changes --------------------- +- Fixes to builtin template emulation of regular templates. + (`#42102 `_, + `#51928 `_) -These are major changes to the build system that have happened since the 12.0.0 -release of Clang. Users of the build system should adjust accordingly. +- Fix incorrect handling of inline builtins with asm labels. -- The option ``LIBCLANG_INCLUDE_CLANG_TOOLS_EXTRA`` no longer exists. There were - two releases with that flag forced off, and no uses were added that forced it - on. The recommended replacement is clangd. +- The builtin type trait ``__is_aggregate`` now returns ``true`` for arrays of incomplete + types in accordance with the suggested fix for `LWG3823 `_ -- ... +Bug Fixes to Attribute Support +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +- Fixes an accepts-invalid bug in C when using a ``_Noreturn`` function + specifier on something other than a function declaration. + (`#56800 `_) -AST Matchers ------------- +- No longer assert/miscompile when trying to make a vectorized ``_BitInt`` type + using the ``ext_vector_type`` attribute (the ``vector_size`` attribute was + already properly diagnosing this case). -- ... +- Invalid destructor names are no longer accepted on template classes. + (`#56772 `_) -clang-format ------------- +- Improve compile-times with large dynamic array allocations with trivial + constructors. + (`#56774 `_) -- Option ``SpacesInLineCommentPrefix`` has been added to control the - number of spaces in a line comments prefix. +- Fix a crash when a ``btf_type_tag`` attribute is applied to the pointee of + a function pointer. -- Option ``SortIncludes`` has been updated from a ``bool`` to an - ``enum`` with backwards compatibility. In addition to the previous - ``true``/``false`` states (now ``CaseSensitive``/``Never``), a third - state has been added (``CaseInsensitive``) which causes an alphabetical sort - with case used as a tie-breaker. +- In C mode, when ``e1`` has ``__attribute__((noreturn))`` but ``e2`` doesn't, + ``(c ? e1 : e2)`` is no longer considered noreturn, fixing a miscompilation. + (`#59792 `_) - .. code-block:: c++ +- GNU attributes being applied prior to standard attributes would be handled + improperly, which was corrected to match the behaviour exhibited by GCC. + (`#58229 `_) - // Never (previously false) - #include "B/A.h" - #include "A/B.h" - #include "a/b.h" - #include "A/b.h" - #include "B/a.h" +- Fix issue using __attribute__((format)) on non-variadic functions that expect + more than one formatted argument. - // CaseSensitive (previously true) - #include "A/B.h" - #include "A/b.h" - #include "B/A.h" - #include "B/a.h" - #include "a/b.h" +- Clang will now no longer treat a C 'overloadable' function without a prototype as + a variadic function with the attribute. This should make further diagnostics more + clear. - // CaseInsensitive - #include "A/B.h" - #include "A/b.h" - #include "a/b.h" - #include "B/A.h" - #include "B/a.h" +Bug Fixes to C++ Support +^^^^^^^^^^^^^^^^^^^^^^^^ +- No longer issue a pre-C++2b compatibility warning in ``-pedantic`` mode + regading overloaded `operator[]` with more than one parmeter or for static + lambdas. (`#61582 `_) -- ``BasedOnStyle: InheritParentConfig`` allows to use the ``.clang-format`` of - the parent directories to overwrite only parts of it. +- Address the thread identification problems in coroutines. + (`#47177 `_, + `#47179 `_) -- Option ``IndentAccessModifiers`` has been added to be able to give access - modifiers their own indentation level inside records. +- Reject non-type template arguments formed by casting a non-zero integer + to a pointer in pre-C++17 modes, instead of treating them as null + pointers. -- Option ``PPIndentWidth`` has been added to be able to configure pre-processor - indentation independent from regular code. +- Fix template arguments of pointer and reference not taking the type as + part of their identity. + (`#47136 `_) -- Option ``ShortNamespaceLines`` has been added to give better control - over ``FixNamespaceComments`` when determining a namespace length. +- Fix handling of unexpanded packs in template argument expressions. + (`#58679 `_) -- Support for Whitesmiths has been improved, with fixes for ``namespace`` blocks - and ``case`` blocks and labels. +- Fix bug with ``using enum`` that could lead to enumerators being treated as if + they were part of an overload set. + (`#58067 `_, + `#59014 `_, + `#54746 `_) -- Option ``EmptyLineAfterAccessModifier`` has been added to remove, force or keep - new lines after access modifiers. +- Fix bug where constant evaluation treated a pointer to member that points to + a weak member as never being null. Such comparisons are now treated as + non-constant. -- Checks for newlines in option ``EmptyLineBeforeAccessModifier`` are now based - on the formatted new lines and not on the new lines in the file. (Fixes - https://llvm.org/PR41870.) +- Fix issue that the standard C++ modules importer will call global + constructor/destructor for the global variables in the importing modules. + (`#59765 `_) -- Option ``SpacesInAngles`` has been improved, it now accepts ``Leave`` value - that allows to keep spaces where they are already present. +- Reject in-class defaulting of previously declared comparison operators. + (`#51227 `_) -- Option ``AllowShortIfStatementsOnASingleLine`` has been improved, it now - accepts ``AllIfsAndElse`` value that allows to put "else if" and "else" short - statements on a single line. (Fixes https://llvm.org/PR50019.) +- Do not hide templated base members introduced via using-decl in derived class + (useful specially for constrained members). (`#50886 `_) -- Option ``BreakInheritanceList`` gets a new style, ``AfterComma``. It breaks - only after the commas that separate the base-specifiers. +- Fix default member initializers sometimes being ignored when performing + parenthesized aggregate initialization of templated types. + (`#62266 `_) +- Fix overly aggressive lifetime checks for parenthesized aggregate + initialization. + (`#61567 `_) -- Option ``LambdaBodyIndentation`` has been added to control how the body of a - lambda is indented. The default ``Signature`` value indents the body one level - relative to whatever indentation the signature has. ``OuterScope`` lets you - change that so that the lambda body is indented one level relative to the scope - containing the lambda, regardless of where the lambda signature was placed. +Concepts Specific Fixes: -- Option ``IfMacros`` has been added. This lets you define macros that get - formatted like conditionals much like ``ForEachMacros`` get styled like - foreach loops. +- Class member variables are now in scope when parsing a ``requires`` clause. + (`#55216 `_) -- ``git-clang-format`` no longer formats changes to symbolic links. (Fixes - https://llvm.org/PR46992.) +- Required parameter pack to be provided at the end of the concept parameter list. + (`#48182 `_) -- Makes ``PointerAligment: Right`` working with ``AlignConsecutiveDeclarations``. - (Fixes https://llvm.org/PR27353) +- Correctly handle access-checks in requires expression. (`#53364 `_, + `#53334 `_) -- Option ``AlignArrayOfStructure`` has been added to allow for ordering array-like - initializers. +- Fixed an issue with concept requirement evaluation, where we incorrectly allowed implicit + conversions to bool for a requirement. (`#54524 `_) -- Support for formatting JSON file (\*.json) has been added to clang-format. +- Fix a crash when emitting a concept-related diagnostic. + (`#57415 `_) -libclang --------- +- Fix a crash when trying to form a recovery expression on a call inside a + constraint, which re-evaluated the same constraint. + (`#53213 `_, + `#45736 `_) -- Make libclang SONAME independent from LLVM version. It will be updated only when - needed. Defined in CLANG_SONAME (clang/tools/libclang/CMakeLists.txt). - `More details `_ +- Fix an issue when performing constraints partial ordering on non-template + functions. (`#56154 `_) -Static Analyzer ---------------- +- Fix a number of recursively-instantiated constraint issues, which would possibly + result in a stack overflow. + (`#44304 `_, + `#50891 `_) + +- Finished implementing C++ DR2565, which results in a requirement becoming + not satisfied in the event of an instantiation failures in a requires expression's + parameter list. We previously handled this correctly in a constraint evaluation + context, but not in a requires clause evaluated as a boolean. + +Consteval Specific Fixes: + +- Fix a crash when generating code coverage information for an + ``if consteval`` statement. + (`#57377 `_) + +- Fixed a crash-on-valid with consteval evaluation of a list-initialized + constructor for a temporary object. + (`#55871 `_) + +- Fixes an assert crash caused by looking up missing vtable information on ``consteval`` + virtual functions. (`#55065 `_) + +Bug Fixes to AST Handling +^^^^^^^^^^^^^^^^^^^^^^^^^ +- A SubstTemplateTypeParmType can now represent the pack index for a + substitution from an expanded pack. + (`#56099 `_) -.. 2407eb08a574 [analyzer] Update static analyzer to be support sarif-html +- The template arguments of a variable template being accessed as a + member will now be represented in the AST. -- Add a new analyzer output type, ``sarif-html``, that outputs both HTML and - Sarif files. +Miscellaneous Bug Fixes +^^^^^^^^^^^^^^^^^^^^^^^ +- Clang configuration files are now read through the virtual file system + rather than the physical one, if these are different. -.. 90377308de6c [analyzer] Support allocClassWithName in OSObjectCStyleCast checker +- Fix an issue where -frewrite-includes generated line control directives with + incorrect line numbers in some cases when a header file used an end of line + character sequence that differed from the primary source file. + (`#59736 `_) -- Add support for ``allocClassWithName`` in OSObjectCStyleCast checker. +- Clang 14 predeclared some builtin POSIX library functions in ``gnu2x`` mode, + and Clang 15 accidentally stopped predeclaring those functions in that + language mode. Clang 16 now predeclares those functions again. + (`#56607 `_) -.. cad9b7f708e2b2d19d7890494980c5e427d6d4ea: Print time taken to analyze each function +- Fix the bug of inserting the ``ZeroInitializationFixit`` before the template + argument list of ``VarTemplateSpecializationDecl``. +- Fix the bug where Clang emits constrained float intrinsics when specifying + ``-ffp-model=strict -ffp-model=fast``. -- The option ``-analyzer-display-progress`` now also outputs analysis time for - each function. +Miscellaneous Clang Crashes Fixed +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +- Fix a crash when evaluating a multi-dimensional array's array filler + expression is element-dependent. + (`#50601 `_) -.. 9e02f58780ab8734e5d27a0138bd477d18ae64a1 [analyzer] Highlight arrows for currently selected event +- Fix an assert that triggers a crash during template name lookup when a type is + incomplete but was not also a TagType. + (`#57387 `_) -- For bug reports in HTML format, arrows are now highlighted for the currently - selected event. +- Fix a crash when attempting to default a virtual constexpr non-special member + function in a derived class. + (`#57431 `_) -.. Deep Majumder's GSoC'21 -.. 80068ca6232b [analyzer] Fix for faulty namespace test in SmartPtrModelling -.. d825309352b4 [analyzer] Handle std::make_unique -.. 0cd98bef1b6f [analyzer] Handle std::swap for std::unique_ptr -.. 13fe78212fe7 [analyzer] Handle << operator for std::unique_ptr -.. 48688257c52d [analyzer] Model comparision methods of std::unique_ptr -.. f8d3f47e1fd0 [analyzer] Updated comments to reflect D85817 -.. 21daada95079 [analyzer] Fix static_cast on pointer-to-member handling +- Fix ``-Wpre-c++17-compat`` crashing Clang when compiling C++20 code which + contains deduced template specializations. + (`#57369 `_, + `#57643 `_, + `#57793 `_) -- While still in alpha, ``alpha.cplusplus.SmartPtr`` received numerous - improvements and nears production quality. +- Fix a crash upon stray coloncolon token in C2x mode. -.. 21daada95079 [analyzer] Fix static_cast on pointer-to-member handling -.. 170c67d5b8cc [analyzer] Use the MacroExpansionContext for macro expansions in plists -.. 02b51e5316cd [analyzer][solver] Redesign constraint ranges data structure -.. 3085bda2b348 [analyzer][solver] Fix infeasible constraints (PR49642) -.. 015c39882ebc [Analyzer] Infer 0 value when the divisible is 0 (bug fix) -.. 90377308de6c [analyzer] Support allocClassWithName in OSObjectCStyleCast checker -.. df64f471d1e2 [analyzer] DynamicSize: Store the dynamic size -.. e273918038a7 [analyzer] Track leaking object through stores -.. 61ae2db2d7a9 [analyzer] Adjust the reported variable name in retain count checker -.. 50f17e9d3139 [analyzer] RetainCountChecker: Disable reference counting for OSMetaClass. +- Fix assert that triggers a crash during some types of list initialization that + generate a CXXTemporaryObjectExpr instead of a InitListExpr. + (`#58302 `_, + `#58753 `_, + `#59100 `_) -- Various fixes and improvements, including modeling of casts (such as - ``std::bit_cast<>``), constraint solving, explaining bug-causing variable - values, macro expansion notes, modeling the size of dynamic objects and the - modeling and reporting of Objective C/C++ retain count related bugs. These - should reduce false positives and make the remaining reports more readable. +- Fix a crash where we attempt to define a deleted destructor. + (`#57516 `_) -.. _release-notes-ubsan: +- Fix an issue that triggers a crash if we instantiate a hidden friend functions. + (`#54457 `_) -Undefined Behavior Sanitizer (UBSan) ------------------------------------- +- Fix an issue that makes Clang crash on lambda template parameters. + (`#57960 `_) -Core Analysis Improvements -========================== +- Fixed a crash in C++20 mode in Clang and Clangd when compile source + with compilation errors. + (`#53628 `_) -- ... +- Fix sanity check when value initializing an empty union so that it takes into + account anonymous structs which is a GNU extension. + (`#58800 `_) -New Issues Found -================ -- ... +Target Specific Changes +----------------------- + +X86 Support +^^^^^^^^^^^ +- Support ``-mindirect-branch-cs-prefix`` for call and jmp to indirect thunk. +- Fix 32-bit ``__fastcall`` and ``__vectorcall`` ABI mismatch with MSVC. +- Add ISA of ``AMX-FP16`` which support ``_tile_dpfp16ps``. +- Switch ``AVX512-BF16`` intrinsics types from ``short`` to ``__bf16``. +- Add support for ``PREFETCHI`` instructions. +- Support ISA of ``CMPCCXADD``. + * Support intrinsic of ``_cmpccxadd_epi32``. + * Support intrinsic of ``_cmpccxadd_epi64``. +- Add support for ``RAO-INT`` instructions. + * Support intrinsic of ``_aadd_i32/64`` + * Support intrinsic of ``_aand_i32/64`` + * Support intrinsic of ``_aor_i32/64`` + * Support intrinsic of ``_axor_i32/64`` +- Support ISA of ``AVX-IFMA``. + * Support intrinsic of ``_mm(256)_madd52hi_avx_epu64``. + * Support intrinsic of ``_mm(256)_madd52lo_avx_epu64``. +- Support ISA of ``AVX-VNNI-INT8``. + * Support intrinsic of ``_mm(256)_dpbssd(s)_epi32``. + * Support intrinsic of ``_mm(256)_dpbsud(s)_epi32``. + * Support intrinsic of ``_mm(256)_dpbuud(s)_epi32``. +- Support ISA of ``AVX-NE-CONVERT``. + * Support intrinsic of ``_mm(256)_bcstnebf16_ps``. + * Support intrinsic of ``_mm(256)_bcstnesh_ps``. + * Support intrinsic of ``_mm(256)_cvtneebf16_ps``. + * Support intrinsic of ``_mm(256)_cvtneeph_ps``. + * Support intrinsic of ``_mm(256)_cvtneobf16_ps``. + * Support intrinsic of ``_mm(256)_cvtneoph_ps``. + * Support intrinsic of ``_mm(256)_cvtneps_avx_pbh``. +- ``-march=raptorlake``, ``-march=meteorlake`` and ``-march=emeraldrapids`` are now supported. +- ``-march=sierraforest``, ``-march=graniterapids`` and ``-march=grandridge`` are now supported. +- Lift _BitInt() supported max width from 128 to 8388608. +- Support intrinsics of ``_mm(256)_reduce_(add|mul|or|and)_epi8/16``. +- Support intrinsics of ``_mm(256)_reduce_(max|min)_ep[i|u]8/16``. + +Arm and AArch64 Support +^^^^^^^^^^^^^^^^^^^^^^^ +- The target(..) function attributes for AArch64 now accept: + * ``"arch="`` strings, that specify the architecture for a function as per the ``-march`` option. + * ``"cpu="`` strings, that specify the cpu for a function as per the ``-mcpu`` option. + * ``"tune="`` strings, that specify the tune cpu for a function as per ``-mtune``. + * ``"+"``, ``"+no"`` enables/disables the specific feature, for compatibility with GCC target attributes. + * ``""``, ``"no-"`` enabled/disables the specific feature, for backward compatibility with previous releases. +- ``-march`` values for targeting armv2, armv2A, armv3 and armv3M have been removed. + Their presence gave the impression that Clang can correctly generate code for + them, which it cannot. +- Support has been added for the following processors (-mcpu identifiers in parenthesis): + * Arm Cortex-A715 (cortex-a715). + * Arm Cortex-X3 (cortex-x3). + * Arm Neoverse V2 (neoverse-v2) +- Strict floating point has been enabled for AArch64, which means that + ``-ftrapping-math``, ``-frounding-math``, ``-ffp-model=strict``, and + ``-ffp-exception-behaviour=`` are now accepted. -Python Binding Changes +Windows Support +^^^^^^^^^^^^^^^ +- For the MinGW driver, added the options ``-mguard=none``, ``-mguard=cf`` and + ``-mguard=cf-nochecks`` (equivalent to ``/guard:cf-``, ``/guard:cf`` and + ``/guard:cf,nochecks`` in clang-cl) for enabling Control Flow Guard checks + and generation of address-taken function table. +- Switched from SHA1 to BLAKE3 for PDB type hashing / ``-gcodeview-ghash`` +- Fixed code generation with emulated TLS, when the emulated TLS is enabled + by default (with downstream patches; no upstream configurations default + to this configuration, but some mingw downstreams change the default + in this way). +- Improved detection of MinGW cross sysroots for finding sysroots provided + by Linux distributions such as Fedora. Also improved such setups by + avoiding to include ``/usr/include`` among the include paths when cross + compiling with a cross sysroot based in ``/usr``. +- Fix incorrect alignment attribute on the this parameter of certain + non-complete destructors when using the Microsoft ABI. + `Issue 60465 `_. + +LoongArch Support +^^^^^^^^^^^^^^^^^ +- Clang now supports LoongArch. Along with the backend, clang is able to build a + large corpus of Linux applications. Test-suite 100% pass. +- Support basic option ``-march=`` which is used to select the target + architecture, i.e. the basic set of ISA modules to be enabled. Possible values + are ``loongarch64`` and ``la464``. +- Support basic option ``-mabi=`` which is used to select the base ABI type. + Possible values are ``lp64d``, ``lp64f``, ``lp64s``, ``ilp32d``, ``ilp32f`` + and ``ilp32s``. +- Support extended options: ``-msoft-float``, ``-msingle-float``, ``-mdouble-float`` and ``mfpu=``. + See `LoongArch toolchain conventions `_. + +RISC-V Support +^^^^^^^^^^^^^^ +- ``sifive-7-rv32`` and ``sifive-7-rv64`` are no longer supported for ``-mcpu``. + Use ``sifive-e76``, ``sifive-s76``, or ``sifive-u74`` instead. +- Native detections via ``-mcpu=native`` and ``-mtune=native`` are supported. +- Fix interaction of ``-mcpu`` and ``-march``, RISC-V backend will take the + architecture extension union of ``-mcpu`` and ``-march`` before, and now will + take architecture extensions from ``-march`` if both are given. +- An ABI mismatch between GCC and Clang that related to the + sign/zero-extension of integer scalars was fixed. +- An overall simplification of the RISC-V Vector intrinsics are done. The + simplification is based on + `riscv-non-isa/rvv-intrinsic-doc#186 `_. +- Intrinsics of `vcompress` and `vmerge` have been adjusted to have interfaces + be aligned among `vvm`, `vxm` intrinsics. The adjustment is base on + `riscv-non-isa/rvv-intrinsic-doc#185 `_. +- All RISC-V Vector intrinsics now share a `__riscv_` prefix, based on the + naming convention defined by + `riscv-non-isa/riscv-c-api-doc#31 `_. +- Note that the RISC-V Vector C intrinsics are still under development. The RVV + C Intrinsic Task Group is working towards a ratified v1.0. +- The rvv-intrinsic-doc provides `compatible headers `_ for transition from the previous implemented version to the current (v0.11) version. +- Clang now supports `v0.11 RVV intrinsics `_. + +CUDA/HIP Language Changes in Clang +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +- Allow the use of ``__noinline__`` as a keyword (instead of ``__attribute__((noinline))``) + in lambda declarations. + +CUDA Support +^^^^^^^^^^^^ +- Clang now supports CUDA SDK up to 11.8 +- Added support for targeting sm_{87,89,90} GPUs. + +AIX Support +^^^^^^^^^^^ +* When using ``-shared``, the clang driver now invokes llvm-nm to create an + export list if the user doesn't specify one via linker flag or pass an + alternative export control option. +* Driver work done for ``-pg`` to link with the right paths and files. + +- Improved support for `-bcdtors:mbr` and `-bcdtors:csect` linker flags + when linking with -fprofile-generate. + +- Enabled LTO support. Requires AIX 7.2 TL5 SP3 or newer, or AIX 7.3. LTO + support is implemented with the `libLTO.so` plugin. To specify a + different plugin, use the linker option `-bplugin:`. + To pass options to the plugin, use the linker option `-bplugin_opt: