| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[clang][Interp] Pass ASTContext to toAPValue() Not yet needed, but we need to ASTContext in a later patch when we start computing proper values for the APValue offset. | 1 年前 | |
[clang][AST] RecursiveASTVisitor should visit owned TagDecl of friend type. A FriendDecl node can have a friend record type that owns a RecordDecl object. This object is different than the one got from TypeSourceInfo object of the FriendDecl. When building a ParentMapContext this owned tag decaration has to be encountered to have the parent set for it. Reviewed By: sammccall Differential Revision: https://reviews.llvm.org/D131685 | 3 年前 | |
[AST] Add dump() method to TypeLoc (#65484) The ability to dump AST nodes is important to ad-hoc debugging, and the fact this doesn't work with TypeLoc nodes is an obvious missing feature in e.g. clang-query ( set output dump simply does nothing). Having TypeLoc::dump(), and enabling DynTypedNode::dump() for such nodes seems like a clear win. It looks like this: `` int main(int argc, char **argv); FunctionProtoTypeLoc <test.cc:3:1, col:31> 'int (int, char **)' cdecl |-ParmVarDecl 0x30071a8 <col:10, col:14> col:14 argc 'int' | -BuiltinTypeLoc <col:10> 'int' |-ParmVarDecl 0x3007250 <col:20, col:27> col:27 argv 'char **' | -PointerTypeLoc <col:20, col:26> 'char **' | -PointerTypeLoc <col:20, col:25> 'char *' | -BuiltinTypeLoc <col:20> 'char' -BuiltinTypeLoc <col:1> 'int' `` It dumps the lexically nested tree of type locs. This often looks similar to how types are dumped, but unlike types we don't look at desugaring e.g. typedefs, as their underlying types are not lexically spelled here. --- Less clear is exactly when to include these nodes in existing text AST dumps rooted at (TranslationUnit)Decls. These already omit supported nodes sometimes, e.g. NestedNameSpecifiers are often mentioned but not recursively dumped. TypeLocs are a more extreme case: they're ~always more verbose than the current AST dump. So this patch punts on that, TypeLocs are only ever printed recursively as part of a TypeLoc::dump() call. It would also be nice to be able to invoke clang to dump a typeloc somehow, like clang -cc1 -ast-dump. But I don't know exactly what the best verison of that is, so this patch doesn't do it. --- There are similar (less critical!) nodes: TemplateArgumentLoc etc, these also don't have dump() functions today and are obvious extensions. I suspect that we should add these, and Loc nodes should dump each other (e.g. the ElaboratedTypeLoc vector<int>::iterator should dump the NestedNameSpecifierLoc vector<int>::, which dumps the TemplateSpecializationTypeLoc vector<int>::` etc). Maybe this generalizes further to a "full syntactic dump" mode, where even Decls and Stmts would print the TypeLocs they lexically contain. But this may be more complex than useful. --- While here, ConceptReference JSON dumping must be implemented. It's not totally clear to me why this implementation wasn't required before but is now... | 2 年前 | |
Consider aggregate bases when checking if an InitListExpr is constant (#80519) This code was correct as written prior to C++17, which allowed bases to appear in the initializer list. This was observable by creating non-constant aggregate initialization at file scope in a compound literal, but since that behavior will change soon if we implement support for dynamic initialization, I also added a unit test for isConstantInitializer. This fixes at least one part of issue #80510 . --------- Co-authored-by: Aaron Ballman <aaron@aaronballman.com> | 2 年前 | |
Rename APIs in unittests/AST/Language.h in preparation to share them Summary: Declaring these helpers in the ast_matcher namespace in the clangAST unit test seems inappropriate -- neither these helpers, nor clangAST have anything to do with AST matchers. Therefore, I moved these helpers to the clang namespace. Declaring another typedef called "ArgVector" is not a good idea -- we already have both "ArgVector", "ArgsVector", and "ArgList". I expanded it into the underlying type. Declaring another enum called "Language" is not a good idea because we arleady have the "clang::Language" enum. I renamed it to "TestLanguage". Similarly, I renamed "getBasicRunOptionsForLanguage" to "getCommandLineArgsForTesting" to explain the semantics better (what are "run options"?) and not repeat types in the function name ("ForLanguage"). Reviewers: shafik, rengolin, sammccall Reviewed By: sammccall Subscribers: gribozavr2, sammccall, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D80786 | 5 年前 | |
[clang][ASTImporter] Add import of 'DependentSizedExtVectorType' Add import of 'DependentSizedExtVectorType'. Reviewed By: balazske Differential Revision: https://reviews.llvm.org/D157238 | 2 年前 | |
[clang][ASTImporter] Improve import of variable template specializations. (#78284) Code of VisitVarTemplateSpecializationDecl was rewritten based on code of VisitVarDecl. Additional changes (in structural equivalence) were made to make tests pass. | 2 年前 | |
[clang][NFC] Trim license header comments to 81 characters (#82919) clang-format would format these headers poorly by splitting it into multiple lines. | 2 年前 | |
[clang][ASTImporter] Add import of a few type related nodes Add import of type-related nodes: - bitIntType - constantMatrixType - dependentAddressSpaceType - dependentBitIntType - dependentSizedMatrixType - dependentVectorType - objcTypeParamDecl - objcTypeParamType - pipeType - vectorType Reviewed By: balazske Differential Revision: https://reviews.llvm.org/D158948 | 2 年前 | |
[clang][ASTImporter] Fix import of anonymous enums if multiple are present (#99281) After changes in PR #87144 and #93923 regressions appeared in some cases. The problem was that if multiple anonymous enums are present in a class and are imported as new the import of the second enum can fail because it is detected as different from the first and causes ODR error. Now in case of enums without name an existing similar enum is searched, if not found the enum is imported. ODR error is not detected. This may be incorrect if non-matching structures are imported, but this is the less important case (import of matching classes is more important to work). | 1 年前 | |
Bump googletest to 1.10.0 | 5 年前 | |
[clang] Refactor AST printing tests to share more infrastructure Differential Revision: https://reviews.llvm.org/D105457 | 4 年前 | |
[Clang] Fix AST dump for {CXXDefaultArgExpr, CXXDefaultInitExpr} (#88269) This PR fix a AST dump issue since https://github.com/llvm/llvm-project/pull/80001 When Clang dumps CXXDefaultArgExpr/CXXDefaultInitExpr, there has no recursively dump the complete CXXDefaultArgExpr/CXXDefaultInitExpr. Since this PR, Clang will recursively dump a CXXDefaultArgExpr/CXXDefaultInitExpr node, even if the node has no rewritten init. *Consider*: struct A { int arr[1]; }; struct B { const A &a = A{{0}}; }; void test() { B b{}; } *Before*: `` -FunctionDecl <line:9:1, line:11:1> line:9:6 test 'void ()' -CompoundStmt <col:13, line:11:1> -DeclStmt <line:10:3, col:8> -VarDecl <col:3, col:7> col:5 b 'B' listinit -InitListExpr <col:6, col:7> 'B' -CXXDefaultInitExpr <col:7> 'const A' lvalue has rewritten init -ExprWithCleanups <line:6:16, col:21> 'const A' lvalue *After*: -FunctionDecl 0x15a9455a8 <line:9:1, line:11:1> line:9:6 test 'void ()' -CompoundStmt 0x15a945850 <col:13, line:11:1> -DeclStmt 0x15a945838 <line:10:3, col:8> -VarDecl 0x15a945708 <col:3, col:7> col:5 b 'B' listinit -InitListExpr 0x15a9457b0 <col:6, col:7> 'B' -CXXDefaultInitExpr 0x15a9457f8 <col:7> 'const A' lvalue has rewritten init -ExprWithCleanups 0x15a945568 <line:6:16, col:21> 'const A' lvalue -MaterializeTemporaryExpr 0x15a945500 <col:16, col:21> 'const A' lvalue extended by Field 0x15a945160 'a' 'const A &' -ImplicitCastExpr 0x15a9454e8 <col:16, col:21> 'const A' <NoOp> -CXXFunctionalCastExpr 0x15a9454c0 <col:16, col:21> 'A' functional cast to A <NoOp> -InitListExpr 0x15a9452c0 <col:17, col:21> 'A' -InitListExpr 0x15a945308 <col:18, col:20> 'int[1]' -IntegerLiteral 0x15a945210 <col:19> 'int' 0 `` --------- Signed-off-by: yronglin <yronglin777@gmail.com> | 2 年前 | |
[AST] Support ConceptReference in DynTypedNode, add dump(). The dump() is not actually included recursively in any other nodes' dump, as this is too verbose (similar to NNS) but useful in its own right. It's unfortunate to not have the actual tests yet, but the DynTypedNode tests are matcher-based and adding matchers is a larger task than DynTypedNode support (but can't be done first). (I've got a clangd change stacked on this that uses DynTypedNode and dump(), and both work. I'll send a change for matchers next). Differential Revision: https://reviews.llvm.org/D159300 | 2 年前 | |
Reland "[clang-repl] Implement partial translation units and error recovery." Original commit message: [clang-repl] Implement partial translation units and error recovery. https://reviews.llvm.org/D96033 contained a discussion regarding efficient modeling of error recovery. @rjmccall has outlined the key ideas: Conceptually, we can split the translation unit into a sequence of partial translation units (PTUs). Every declaration will be associated with a unique PTU that owns it. The first key insight here is that the owning PTU isn't always the "active" (most recent) PTU, and it isn't always the PTU that the declaration "comes from". A new declaration (that isn't a redeclaration or specialization of anything) does belong to the active PTU. A template specialization, however, belongs to the most recent PTU of all the declarations in its signature - mostly that means that it can be pulled into a more recent PTU by its template arguments. The second key insight is that processing a PTU might extend an earlier PTU. Rolling back the later PTU shouldn't throw that extension away. For example, if the second PTU defines a template, and the third PTU requires that template to be instantiated at float, that template specialization is still part of the second PTU. Similarly, if the fifth PTU uses an inline function belonging to the fourth, that definition still belongs to the fourth. When we go to emit code in a new PTU, we map each declaration we have to emit back to its owning PTU and emit it in a new module for just the extensions to that PTU. We keep track of all the modules we've emitted for a PTU so that we can unload them all if we decide to roll it back. Most declarations/definitions will only refer to entities from the same or earlier PTUs. However, it is possible (primarily by defining a previously-declared entity, but also through templates or ADL) for an entity that belongs to one PTU to refer to something from a later PTU. We will have to keep track of this and prevent unwinding to later PTU when we recognize it. Fortunately, this should be very rare; and crucially, we don't have to do the bookkeeping for this if we've only got one PTU, e.g. in normal compilation. Otherwise, PTUs after the first just need to record enough metadata to be able to revert any changes they've made to declarations belonging to earlier PTUs, e.g. to redeclaration chains or template specialization lists. It should even eventually be possible for PTUs to provide their own slab allocators which can be thrown away as part of rolling back the PTU. We can maintain a notion of the active allocator and allocate things like Stmt/Expr nodes in it, temporarily changing it to the appropriate PTU whenever we go to do something like instantiate a function template. More care will be required when allocating declarations and types, though. We would want the PTU to be efficiently recoverable from a Decl; I'm not sure how best to do that. An easy option that would cover most declarations would be to make multiple TranslationUnitDecls and parent the declarations appropriately, but I don't think that's good enough for things like member function templates, since an instantiation of that would still be parented by its original class. Maybe we can work this into the DC chain somehow, like how lexical DCs are. We add a different kind of translation unit TU_Incremental which is a complete translation unit that we might nonetheless incrementally extend later. Because it is complete (and we might want to generate code for it), we do perform template instantiation, but because it might be extended later, we don't warn if it declares or uses undefined internal-linkage symbols. This patch teaches clang-repl how to recover from errors by disconnecting the most recent PTU and update the primary PTU lookup tables. For instance: ./clang-repl clang-repl> int i = 12; error; In file included from <<< inputs >>>:1: input_line_0:1:13: error: C++ requires a type specifier for all declarations int i = 12; error; ^ error: Parsing failed. clang-repl> int i = 13; extern "C" int printf(const char*,...); clang-repl> auto r1 = printf("i=%d\n", i); i=13 clang-repl> quit Differential revision: https://reviews.llvm.org/D104918 | 4 年前 | |
[clang] Enable C++11-style attributes in all language modes This also ignores and deprecates the -fdouble-square-bracket-attributes command line flag, which seems to not be used anywhere. At least a code search exclusively found mentions of it in documentation: https://sourcegraph.com/search?q=context:global+-fdouble-square-bracket-attributes+-file:clang/*+-file:test/Sema/*+-file:test/Parser/*+-file:test/AST/*+-file:test/Preprocessor/*+-file:test/Misc/*+archived:yes&patternType=standard&sm=0&groupBy=repo RFC: https://discourse.llvm.org/t/rfc-enable-c-11-c2x-attributes-in-all-standard-modes-as-an-extension-and-remove-fdouble-square-bracket-attributes This enables [[]] attributes in all C and C++ language modes without warning by default. -Wc++-extensions does warn. GCC has enabled this extension in all C modes since GCC 10. Reviewed By: aaron.ballman, MaskRay Spies: #clang-vendors, beanz, JDevlieghere, Michael137, MaskRay, sstefan1, jplehr, cfe-commits, lldb-commits, dmgreen, jdoerfert, wenlei, wlei Differential Revision: https://reviews.llvm.org/D151683 | 2 年前 | |
Revert "[clang] fix broken canonicalization of DeducedTemplateSpecializationType (#95202)" This reverts commit 2e1ad93961a3f444659c5d02d800e3144acccdb4. Reverting #95202 in the 19.x branch Fixes #106182 The change in #95202 causes code to crash and there is no good way to backport a fix for that as there are ABI-impacting changes at play. Instead we revert #95202 in the 19x branch, fixing the regression and preserving the 18.x behavior (which is GCC's behavior) https://github.com/llvm/llvm-project/pull/106335#discussion_r1735174841 | 1 年前 | |
[clang] Use std::size instead of llvm::array_lengthof LLVM contains a helpful function for getting the size of a C-style array: llvm::array_lengthof. This is useful prior to C++17, but not as helpful for C++17 or later: std::size already has support for C-style arrays. Change call sites to use std::size instead. Leave the few call sites that use a locally defined array_lengthof that are meant to test previous bugs with NTTPs in clang analyzer and SemaTemplate. Differential Revision: https://reviews.llvm.org/D133520 | 3 年前 | |
[Clang][Comments] Support for parsing headers in Doxygen \par commands (#91100) ### Background Doxygen's \par command ([link](https://www.doxygen.nl/manual/commands.html#cmdpar)) has an optional argument, which denotes the header of the paragraph started by a given \par command. In short, the paragraph command can be used with a heading, or without one. The code block below shows both forms and how the current version of LLVM/Clang parses this code: `` $ cat test.cpp /// \par User defined paragraph: /// Contents of the paragraph. /// /// \par /// New paragraph under the same heading. /// /// \par /// A second paragraph. class A {}; $ clang++ -cc1 -ast-dump -fcolor-diagnostics -std=c++20 test.cpp -CXXRecordDecl 0x1530f3a78 <test.cpp:11:1, col:10> col:7 class A definition |-FullComment 0x1530fea38 <line:2:4, line:9:23> | |-ParagraphComment 0x1530fe7e0 <line:2:4> | | -TextComment 0x1530fe7b8 <col:4> Text=" " | |-BlockCommandComment 0x1530fe800 <col:5, line:3:30> Name="par" | | -ParagraphComment 0x1530fe878 <line:2:9, line:3:30> | | |-TextComment 0x1530fe828 <line:2:9, col:32> Text=" User defined paragraph:" | | -TextComment 0x1530fe848 <line:3:4, col:30> Text=" Contents of the paragraph." | |-ParagraphComment 0x1530fe8c0 <line:5:4> | | -TextComment 0x1530fe898 <col:4> Text=" " | |-BlockCommandComment 0x1530fe8e0 <col:5, line:6:41> Name="par" | | -ParagraphComment 0x1530fe930 <col:4, col:41> | | -TextComment 0x1530fe908 <col:4, col:41> Text=" New paragraph under the same heading." | |-ParagraphComment 0x1530fe978 <line:8:4> | | -TextComment 0x1530fe950 <col:4> Text=" " | -BlockCommandComment 0x1530fe998 <col:5, line:9:23> Name="par" | -ParagraphComment 0x1530fe9e8 <col:4, col:23> | -TextComment 0x1530fe9c0 <col:4, col:23> Text=" A second paragraph." -CXXRecordDecl 0x1530f3bb0 <line:11:1, col:7> col:7 implicit class A ` As we can see above, the optional paragraph heading ("User defined paragraph") is not an argument of the \par BlockCommandComment, but instead a child TextComment. For documentation generators like [hdoc](https://hdoc.io/), it would be ideal if we could parse Doxygen documentation comments with these semantics in mind. Currently that's not possible. ### Change This change parses \par command according to how Doxygen parses them, making an optional header available as a an argument if it is present. In addition: - AST unit tests are defined to test this functionality when an argument is present, isn't present, with additional spacing, etc. - TableGen is updated with an IsParCommand to support this functionality - lit` tests are updated where needed | 1 年前 | |
[clang] NFC: test for undefined behaviour in RawComment::getFormattedText() This diff adds testcase for the issue fixed in https://reviews.llvm.org/D77468 but regression test was not added in the diff. On Clang 9 it caused crash in cland during code completion. Test Plan: check-clang-unit Differential Revision: https://reviews.llvm.org/D103722 | 4 年前 | |
[AST] Print the separator "," for template arguments in ConceptReference::print (#91750) | 2 年前 | |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636 | 7 年前 | |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636 | 7 年前 | |
| 2 年前 | ||
Revert "[Clang][Comments] Attach comments to decl even if preproc directives are in between (#88367)" This reverts commit 9f04d75b2bd8ba83863db74ebe1a5c08cfc5815c. There was post-commit feedback on the direction this PR took. | 1 年前 | |
[clang] Perform implicit lvalue-to-rvalue cast with new interpreter The EvaluateAsRValue() documentation mentions that an implicit lvalue-to-rvalue cast is being performed if the result is an lvalue. However, that was not being done if the new constant interpreter was in use. Just always do it. Differential Revision: https://reviews.llvm.org/D132136 | 3 年前 | |
ArrayRef'ized CompilerInvocation::CreateFromArgs Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66797 llvm-svn: 370122 | 6 年前 | |
[clang] Avoid 'raw_string_ostream::str' (NFC) Since raw_string_ostream doesn't own the string buffer, it is desirable (in terms of memory safety) for users to directly reference the string buffer rather than use raw_string_ostream::str(). Work towards TODO comment to remove raw_string_ostream::str(). | 1 年前 | |
[clang] Refactor AST printing tests to share more infrastructure Differential Revision: https://reviews.llvm.org/D105457 | 4 年前 | |
[randstruct] Automatically randomize a structure of function pointers Strutures of function pointers are a good surface area for attacks. We should therefore randomize them unless explicitly told not to. Reviewed By: aaron.ballman, MaskRay Differential Revision: https://reviews.llvm.org/D123544 | 4 年前 | |
[clang] Add ObjCProtocolLoc to represent protocol references Add ObjCProtocolLoc which behaves like TypeLoc but for ObjCProtocolDecl references. RecursiveASTVisitor now synthesizes ObjCProtocolLoc during traversal and the ObjCProtocolLoc can be stored in a DynTypedNode. In a follow up patch, I'll update clangd to make use of this to properly support protocol references for hover + goto definition. Differential Revision: https://reviews.llvm.org/D119363 | 4 年前 | |
[Clang] Create opaque type for AArch64 SVE2p1/SME2 svcount_t. This patch adds the builtin type __SVCount_t to Clang, which is an opaque scalable type defined in the SME2 C and C++ Language Extensions. The type maps to the target("aarch64.svcount") LLVM IR type. Reviewed By: paulwalker-arm Differential Revision: https://reviews.llvm.org/D136864 | 3 年前 | |
Add a concept AST node. This patch adds a concept AST node ( ConceptLoc) and uses it at the corresponding places. There are three objects that might have constraints via concepts: TypeConstraint, ConceptSpecializationExpr and AutoTypeLoc. The first two inherit from ConceptReference while the latter has the information about a possible constraint directly stored in AutoTypeLocInfo. It would be nice if the concept information would be stored the same way in all three cases. Moreover the current structure makes it difficult to deal with these concepts. For example in Clangd accessing the locations of constraints of a AutoTypeLoc can only be done with quite ugly hacks. So we think that it makes sense to create a new AST node for such concepts. In details we propose the following: - Rename ConceptReference to ConceptLoc (or something else what is approriate) and make it the new AST node. - TypeConstraint and ConceptSpecializationExpr do not longer inherit from ConceptReference but store a pointer to a ConceptLoc. - AutoTypeLoc stores a pointer to ConceptLoc instead of storing the concept info in AutoTypeLocInfo. This patch implements a first version of this idea which compiles and where the existing tests pass. To make this patch as small as possible we keep the existing member functions to access concept data. Later these can be replaced by directly calling the corresponding functions of the ConceptLocs. Differential Revision: https://reviews.llvm.org/D155858 | 2 年前 | |
Disambiguate type names when printing NTTP types When printing NTTP template types, ensure that type name of the NTTP is printed. Fixes #57562 Differential Revision: https://reviews.llvm.org/D134453 | 3 年前 | |
[StructuralEquivalence] improve NTTP and CXXDependentScopeMemberExpr comparison (#95190) improve ASTStructuralEquivalenceTest: 1. compare the depth and index of NTTP 2. provide comparison of CXXDependentScopeMemberExpr to StmtCompare. Co-authored-by: huqizhi <836744285@qq.com> | 2 年前 | |
[clang] Preserve Qualifiers and type sugar in TemplateNames (#93433) This patch improves the preservation of qualifiers and loss of type sugar in TemplateNames. This problem is analogous to https://reviews.llvm.org/D112374 and this patch takes a very similar approach to that patch, except the impact here is much lesser. When a TemplateName was written bare, without qualifications, we wouldn't produce a QualifiedTemplate which could be used to disambiguate it from a Canonical TemplateName. This had effects in the TemplateName printer, which had workarounds to deal with this, and wouldn't print the TemplateName as-written in most situations. There are also some related fixes to help preserve this type sugar along the way into diagnostics, so that this patch can be properly tested. - Fix dropping the template keyword. - Fix type deduction to preserve sugar in TST TemplateNames. | 2 年前 | |
[clang-cl] Fix value of __FUNCTION__ in MSVC mode. (#84014) Predefined macro FUNCTION in clang is not returning the same string than MS for templated functions. See https://godbolt.org/z/q3EKn5zq4 For the same test case MSVC is returning: function: TestClass::TestClass function: TestStruct::TestStruct function: TestEnum::TestEnum The initial work for this was in the reverted patch (https://github.com/llvm/llvm-project/pull/66120). This patch solves the issues raised in the reverted patch. | 2 年前 | |
Fix compile error in UnresolvedSetTest.cpp, hopefully the last one This test is failing to compile when LLVM_ENABLE_MODULES=ON due to NamedDecl being multiply defined. Fix this by avoiding declaring our own NamedDecl in the test and instead cast a struct of appropriate size and alignment to NamedDecl. | 2 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 5 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 6 年前 | ||
| 1 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 |