基于 LLVM 自制编译器(2)——解析器、抽象语法树
概述
本章,我们将基于词法分析器,为 Kaleidoscope 构建一个完整的解析器(Parser)。通过解析器,我们可以定义并构造抽象语法树(Abstract Syntax Tree,AST)。
本章,我们将基于词法分析器,为 Kaleidoscope 构建一个完整的解析器(Parser)。通过解析器,我们可以定义并构造抽象语法树(Abstract Syntax Tree,AST)。
本教程我们将从零开始设计一门玩具版编程语言——Kaleidoscope。Kaleidoscope
支持函数定义、条件语句、数学运算等。在教程的各个章节中,我们将对
Kaleidoscope 的语言特性进行扩展,支持 if/then/else
语句、for
循环、自定义操作符、JIT 编译、调试信息等。
前一篇文章我们介绍了词法分析器生成器 lex,本文我们来介绍语法/语义分析器生成器 yacc。
在编译过程中,词法分析器的主要作用是将代码文件的文本内容 token 化(又称扫描),token 化后再通过语法分析器进行语法分析,构造语法树,从而完成后续的一系列操作。
作为程序员的你是否有过疑问:为什么命令行工具用法都差不多?事实上,这是因为早期基于
C/C++ 开发的命令行工具都使用了 getopt
工具来进行选项和参数的解析。
CocoaPods-Core 主要包括三部分功能,分别是:Podfile 解析、Podspec 解析、Source 管理,前两个功能我们在之前的文章中已经分别进行了介绍,本文我们再来介绍一下最后一个功能——CocoaPods Source 管理机制。
在 CocoaPods 中,podspec 文件主要用于描述一个 pod 库的基本信息,包括:名称、版本、源、依赖等等。本文,我们来介绍一下 CocoaPods-Core 中另一个重要的部分——podspec。
作为 iOS 开发者,我们都知道 Podfile 是 CocoaPods 用于描述 Xcode
项目依赖的配置文件。当需要为项目添加依赖时,我们只需要在 Podfile
中声明一个 pod
即可,比如:
上一篇文章我们介绍了 Xcode 中的各种概念,本文我们来看看这些概念在
Xcode 中的具体表示。其中,有一个最常见的文件
project.pbxproj
,其描述了描述了整个 Xcode Project
的相关信息,包括:文件、Target、Product 等。另外,Xcode Workspace 则使用
contents.xcworkspacedata
进行描述,主要描述了其所包含的
Project 的位置。Xcode Scheme 则使用 .xcscheme
后缀的文件进行描述。
Xcode 有非常多的概念,比如:workspace、project、target、product、scheme 等,这些概念之间有着千丝万缕的关系,当我们理解了这些概念及其关系之后,会对整个 Xcode 工程体系有一个整体的理解,对我们自身工程能力的提升也会有所帮助。本文将对这些概念及其关系进行梳理,从而为后续的学习提供基础。
Swift 4.0 支持了一个新的语言特性——Codable,其提供了一种非常简单的方式支持模型和数据之间的转换。
在 《Swift
泛型协议》 中,我们探讨了如何基于类型擦除技术解决 Swift
泛型协议的存储问题,通过定义一个类型擦除包装器 AnyPrinter
解决了泛型协议 Printer
的存储问题。但是,AnyPrinter
并没有显式地引用
base
实例,因为当我们定义一个泛型类型的属性时,编译器会报错。
之前在一些分享会上经常听到 类型擦除(Type Erase)这个概念,从其命名上大概知道它要干什么,但是对于为什么要用它?以及什么场景下使用它?对此,我并没有深刻的理解。于是,借着假期好好研究了一下。问题的一切要从泛型协议说起。
最近准备魔改一下 R.swift 以支持 Pod 库生成对应的
R.generated.swift
文件。经研究后发现,R.swift 的本质是使用
Swift Package Manager(简称 SPM) 开发了一个命令行工具
rswift
。很显然,要想魔改 R.swift,必须要学习如何使用 Swift
Package Manager
来开发命令行工具。本文,则通过一个简单的例子来对此进行介绍。