From 616b7f15c0a3120a35de87cf7a6260bda641c38a Mon Sep 17 00:00:00 2001
From: xtcyclist <7731943+xtcyclist@users.noreply.github.com>
Date: Thu, 15 Dec 2022 21:06:55 +0800
Subject: [PATCH] amend comments.

---
 src/common/expression/AttributeExpression.cpp | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/src/common/expression/AttributeExpression.cpp b/src/common/expression/AttributeExpression.cpp
index a6e3ad3f1fe..db68851542a 100644
--- a/src/common/expression/AttributeExpression.cpp
+++ b/src/common/expression/AttributeExpression.cpp
@@ -24,9 +24,8 @@ const Value &AttributeExpression::eval(ExpressionContext &ctx) {
       return lvalue.getMap().at(rvalue.getStr());
     case Value::Type::VERTEX: {
       /*
-       * WARNING(Xuntao): this entire case shall be removed, in theory.
-       * Vertices shall not be evaluated as AttributeExpressions, since
-       * there shall always be a tag specified in the format of:
+       * WARNING(Xuntao): Vertices shall not be evaluated as AttributeExpressions,
+       * since there shall always be a tag specified in the format of:
        * var.tag.property. Due to design flaws, however, we have to keep
        * this case segment.
        */
@@ -35,7 +34,7 @@ const Value &AttributeExpression::eval(ExpressionContext &ctx) {
         return result_;
       }
       /*
-       * WARNING(Xuntao): the following code snippet is a dedicated to address the legacy
+       * WARNING(Xuntao): the following code snippet is dedicated to address the legacy
        * problem of treating LabelTagProperty expressions as Attribute expressions.
        * This snippet is necessary to allow users to write var.tag.prop in
        * ListComprehensionExpression without making structural changes to the implementation.