Merge branch 'main' into dev/peefy/feat_query_tool

Author: Peefy

.github/ISSUE_TEMPLATE.md

@@ -0,0 +1,41 @@
+name: "CLA Assistant"
+on:
+  issue_comment:
+    types: [created]
+  pull_request_target:
+    types: [opened,closed,synchronize]
+
+jobs:
+  CLAssistant:
+    runs-on: ubuntu-latest
+    steps:
+      - name: "CLA Assistant"
+        if: (github.event.comment.body == 'recheck' || github.event.comment.body == 'I have read the CLA Document and I hereby sign the CLA') || github.event_name == 'pull_request_target'
+        # Beta Release
+        uses: cla-assistant/[email protected]
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          # the below token should have repo scope and must be manually added by you in the repository's secret
+          PERSONAL_ACCESS_TOKEN : ${{ secrets.KUSIONSTACK_BOT_TOKEN }}
+        with:
+          path-to-document: 'https://github.com/KusionStack/.github/blob/main/CLA.md' # e.g. a CLA or a DCO document
+
+          # branch should not be protected
+          lock-pullrequest-aftermerge: True
+          path-to-signatures: 'signatures/version1/cla.json'
+          remote-organization-name: KusionStack
+          remote-repository-name: cla.db
+          branch: 'main'
+          allowlist: 'test'
+
+          #below are the optional inputs - If the optional inputs are not given, then default values will be taken
+          #remote-organization-name: enter the remote organization name where the signatures should be stored (Default is storing the signatures in the same repository)
+          #remote-repository-name:  enter the  remote repository name where the signatures should be stored (Default is storing the signatures in the same repository)
+          #create-file-commit-message: 'For example: Creating file for storing CLA Signatures'
+          #signed-commit-message: 'For example: $contributorName has signed the CLA in #$pullRequestNo'
+          #custom-notsigned-prcomment: 'pull request comment with Introductory message to ask new contributors to sign'
+          #custom-pr-sign-comment: 'The signature to be committed in order to sign the CLA'
+          #custom-allsigned-prcomment: 'pull request comment when all contributors has signed, defaults to **CLA Assistant Lite bot** All Contributors have signed the CLA.'
+          #lock-pullrequest-aftermerge: false - if you don't want this bot to automatically lock the pull request after merging (default - true)
+          #use-dco-flag: true - If you are using DCO instead of CLA
+  

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,5 +1,5 @@
 name: KCLVM-actions
-on: [push]
+on: ["push", "pull_request"]
 jobs:
   test-unit:
     name: Test
@@ -35,5 +35,10 @@ jobs:
           components: clippy, rustfmt
       - name: Rust unit test
         working-directory: ./kclvm
-        run: make test
+        run: make codecov-lcov
         shell: bash
+      - name: Coveralls upload
+        uses: coverallsapp/github-action@master
+        with:
+          github-token: ${{ secrets.GITHUB_TOKEN }}
+          path-to-lcov: ./kclvm/.kclvm/lcov.info

.github/workflows/cla.yml

@@ -74,13 +74,14 @@ lark_parser.pickle
 /scripts/docker/kclvm-builder-centos7/crates.io-index
 /scripts/docker/kclvm-builder-ubuntu/crates.io-index
 *.tar.gz
+
+# KCLVM cache and temp output
+.kclvm
+*.dylib
+*.so
+*.dll
+*.lock
+*.ll
+*.ll.lock
 _a.out.*
 _a.out_*.*
-# KCLVM cache
-.kclvm
-__main__.dylib
-__main__.so
-__main__.dll
-__main__.lock
-__main__.ll
-__main__.ll.lock

.github/workflows/github-actions.yaml

@@ -0,0 +1,19 @@
+# About this Guide
+
+This guide is intended to help document how `KCLVM` (the KCL compiler) works, and to help new contributors get involved in KCLVM development.
+
+This guide consists of **4** parts:
+
+1. **Building and Testing `KCLVM`**: Contains information that should be useful no matter how you are contributing, about building, testing, debugging, profiling, etc.
+2. **Contributing to `KCLVM`**: Contains information that should be useful no matter how you are contributing, about procedures for contribution, using git and Github, etc.
+3. **`KCLVM` Architecture**: Contains an introduction to the architecture of the compiler and a detailed introduction to each compilation process.
+4. **Appendices**: There are a few of these with different information, including a glossary.
+
+The Guide itself is of course open-source as well, and the sources can be found at the [GitHub repository](https://github.com/KusionStack/KCLVM/tree/main/docs/dev_guide). If you find any mistakes in the guide, please file an issue about it. Even better, open a Github Pull Request (PR) with a correction!
+
+If you do contribute to the guide, please see the corresponding subsection on writing documentation in this guide.
+
+## Other Documentations
+
+* [KCL Documents](https://kusionstack.io/docs/reference/lang/lang/tour)
+* [KCL Examples](https://github.com/KusionStack/examples)

.gitignore

@@ -0,0 +1,167 @@
+# Quick Start
+
+This documentation is *NOT* intended to be comprehensive; it is meant to be a quick guide for the most useful things. For more information, see the develop guide in its entirety.
+
+## Asking Questions
+
+Before asking a question, make sure you have:
+
+- Searched open and closed:
+  - [KCLVM GitHub Issues](https://github.com/KusionStack/KCLVM/issues?utf8=%E2%9C%93&q=is%3Aissue)
+
+- Read the documentations:
+  - [KCLVM Documents](https://kusionstack.io/docs/reference/lang/lang/tour)
+  - [KCLVM Readme](https://github.com/KusionStack/KCLVM)
+
+If you have any questions about `KCLVM`, you are welcome to ask your questions in [KCLVM Github Issues](https://github.com/KusionStack/KCLVM/issues). When you ask a question, please describe the details as clearly as possible so that others in the KCLVM community can understand, and you *MUST* be polite and avoid personal attack and avoid not objective comparison with other projects.
+
+## Cloning and Building `KCLVM`
+
+### System Requirements
+
+The following hardware is recommended.
+
+- 10GB+ of free disk space.
+- 4GB+ RAM
+- 2+ cores
+
+### Dependencies
+
+#### Docker
+
+- `docker`
+
+In the top level of the `KusionStack/KCLVM` repo and run:
+
+```sh
+make sh-in-docker
+```
+
+Using a docker image is our recommended way, of course, you can also configure your local development environment according to the following content.
+
+#### macOS and OS X
+
+- `git`
+- `Python 3.7+`
+- `Rust 1.60+`
+- `LLVM 12`
+
+You'll need LLVM installed and `llvm-config` in your `PATH`. Just download from [LLVM 12](https://releases.llvm.org/download.html) or install `llvm@12` using `brew`.
+
+```sh
+brew install llvm@12
+```
+
+Add the LLVM installation location to `LLVM_SYS_120_PREFIX` and the `$PATH`.
+
+```
+export LLVM_SYS_120_PREFIX=<your LLVM 12 install location>
+export PATH=<your LLVM 12 install location>/bin:$PATH
+```
+
+#### Linux
+
+- `git`
+- `Rust 1.60+`
+- `Python3 Building Dependencies`
+- `LLVM 12`
+
+For UNIX based systems, you can run:
+
+```
+yum groupinstall -y "Development Tools"
+yum install -y gcc patch libffi-devel python-devel zlib-devel bzip2-devel ncurses-devel sqlite-devel 
+yum install -y libpcap-devel xz-devel readline-devel tk-devel gdbm-devel db4-deve
+yum -y install yum-utils
+yum-builddep -y python3
+yum install -y zlib* 
+yum install -y openssl-devel
+yum install -y glibc-static
+
+# clang-12 & llvm-12
+RUN yum -y install clang
+RUN clang --version
+RUN yum -y install llvm-devel
+RUN yum -y install libffi-devel
+RUN ln -s /usr/lib64/libtinfo.so.6 /usr/lib64/libtinfo.so
+```
+
+On Debian, Ubuntu, and other apt based systems, you can run:
+
+```
+apt-get update
+
+apt-get install -y git wget curl
+apt-get install -y make gcc patch 
+apt-get install -y python-dev libffi-dev
+apt-get install -y zlib1g-dev ncurses-dev build-essential libncurses5-dev libgdbm-dev libnss3-dev libssl-dev libreadline-dev libffi-dev
+
+# clang-12 & llvm-12
+RUN apt-get install -y clang-12 lld-12
+RUN ln -sf /usr/bin/clang-12   /usr/bin/clang
+RUN ln -sf /usr/bin/wasm-ld-12 /usr/bin/wasm-ld
+```
+
+#### Windows
+
+- `git`
+- `Rust 1.60+`
+- `Python 3.7+`
+- `LLVM 12`
+
+Please add the LLVM installation location to `LLVM_SYS_120_PREFIX` and the `$PATH`.
+
+### Cloning
+
+You can just do a normal git clone:
+
+```sh
+git clone https://github.com/KusionStack/KCLVM.git
+cd KCLVM
+```
+
+### Building
+
+In the top level of the `KusionStack/KCLVM` repo and run:
+
+```sh
+./run.sh -a build
+```
+
+### Testing
+
+In the top level of the `KusionStack/KCLVM` repo and run:
+
+```
+./run.sh -a test
+```
+
+See the chapters on building and testing for more details.
+
+## Contributor Procedures
+
+### Create an Issue
+
+Every change should be accompanied by a dedicated tracking issue for that change. The main text of this issue should describe the change being made, with a focus on what users must do to fix their code. The issue should be approachable and practical; it may make sense to direct users to some other issue for the full details. The issue also serves as a place where users can comment with questions or other concerns.
+
+When you open an issue on the `KusionStack/KCLVM` repo, you need to to choose an issue template on this [page](https://github.com/KusionStack/KCLVM/issues/new/choose), you can choose a template according to different situations and fill in the corresponding content, and you also need to select appropriate labels for your issue to help classify and identify.
+
+### Create a PR
+
+When you open a PR on the `KusionStack/KCLVM` repo, you need to assign reviewers in the [KCL Dev Team](https://github.com/orgs/KusionStack/teams/kcl-dev) list, and reviewers are the persons that will approve the PR to be tested and merged.
+
+Please note that all code changes in the KCLVM project require corresponding comments and tests. For more code and test writing details, please see the chapters on code of conduct and testing.
+
+Besides, all PRs need to have corresponding issues tracking, and need to add appropriate labels and milestone information.
+
+#### Bug Fixes or "Normal" Code Changes
+
+For most PRs, no special procedures are needed. You can just open an issue and a PR, and it will be reviewed, approved, and merged. This includes most bug fixes, refactorings, and other user-invisible changes.
+
+Also, note that it is perfectly acceptable to open WIP PRs or GitHub Draft PRs. Some people prefer to do this so they can get feedback along the way or share their code with a collaborator. Others do this so they can utilize the CI to build and test their PR (e.g. if you are developing on a laptop).
+
+#### New Features
+
+In order to implement a new feature, usually you will need to go through [the KEP process](https://github.com/KusionStack/KEP) to propose a design, have discussions, etc.
+
+After a feature is approved to be added, a tracking issue is created on the `KusionStack/KCLVM` repo, which tracks the progress towards the implementation of the feature, any bugs reported, and eventually stabilization. The feature then can be implemented.

docs/dev_guide/1.about_this_guide.md

@@ -0,0 +1 @@
+graft kclvm

docs/dev_guide/2.quick_start.md

@@ -2493,6 +2493,9 @@ def walk_AugAssignStmt(self, t: ast.AugAssignStmt):
     def walk_ListIfItemExpr(self, t: ast.ListIfItemExpr):
         self.expr_or_any_type(t.if_cond)
         or_else_type = self.expr_or_any_type(t.orelse)
+        # `orelse` node maybe a list unpack node, use its item type instead.
+        if isinstance(or_else_type, objpkg.KCLListTypeObject):
+            or_else_type = or_else_type.item_type
         exprs_type = sup(self.exprs(t.exprs))
         return sup([or_else_type, exprs_type])
 

internal/MANIFEST.in

@@ -1,4 +1,4 @@
-wheel==0.34.2 
+wheel==0.34.2
 twine==3.2.0
 pyyaml==5.4
 pytest-xdist==2.2.1

internal/__init__.py

@@ -286,7 +286,10 @@ def walk_IfStmt(self, t: ast.IfStmt):
         self.print(Indentation.Dedent)
         if t.elif_cond:
             for cond, body in zip(t.elif_cond, t.elif_body):
+                # Nested if statements need to be considered,
+                # so `elif` needs to be preceded by the current indentation.
                 self.print(
+                    Indentation.Fill,
                     ast.TokenValue.ELIF,
                     WHITESPACE,
                     cond,
@@ -297,15 +300,17 @@ def walk_IfStmt(self, t: ast.IfStmt):
                 self.stmts(body)
                 self.print(Indentation.Dedent)
         if t.else_body:
+            # Nested if statements need to be considered,
+            # so `else` needs to be preceded by the current indentation.
             self.print(
+                Indentation.Fill,
                 ast.TokenValue.ELSE,
                 ast.TokenValue.COLON,
                 NEWLINE,
                 Indentation.Indent,
             )
             self.stmts(t.else_body)
             self.print(Indentation.Dedent)
-        self.print(NEWLINE)
 
     def walk_ImportStmt(self, t: ast.ImportStmt):
         """ast.AST: ImportStmt
@@ -645,6 +650,7 @@ def walk_UnaryExpr(self, t: ast.UnaryExpr):
         assert isinstance(t, ast.UnaryExpr)
         self.print(
             ast.OPERATOR_VALUE_MAP[t.op],
+            WHITESPACE if t.op == ast.UnaryOp.Not else "",
             t.operand,
         )
 
@@ -1119,7 +1125,9 @@ def walk_JoinedString(self, t: ast.JoinedString):
                     ast.TokenValue.RIGHT_BRACE,
                 )
             elif isinstance(value, ast.StringLit):
-                self.write(value.raw_value or '{}'.format(value.value.replace('"', '\\"')))
+                self.write(
+                    value.raw_value or "{}".format(value.value.replace('"', '\\"'))
+                )
             elif isinstance(value, ast.Expr):
                 self.expr(value)
             else: