2016-12-31 00:34:49 +01:00
|
|
|
{
|
|
|
|
"compilerOptions": {
|
2016-12-31 20:16:36 +01:00
|
|
|
"outDir": "bin",
|
2016-12-31 00:34:49 +01:00
|
|
|
"target": "es6",
|
|
|
|
"module": "commonjs",
|
|
|
|
"moduleResolution": "node",
|
|
|
|
"declaration": true,
|
2017-01-08 22:20:46 +01:00
|
|
|
"sourceMap": true,
|
2016-12-31 00:34:49 +01:00
|
|
|
"stripInternal": true,
|
|
|
|
"experimentalDecorators": true,
|
|
|
|
"pretty": true,
|
|
|
|
"noFallthroughCasesInSwitch": true,
|
|
|
|
"noImplicitAny": true,
|
2017-01-13 19:42:50 +01:00
|
|
|
"noImplicitThis": true,
|
2016-12-31 00:34:49 +01:00
|
|
|
"noImplicitReturns": true,
|
2016-12-31 22:29:46 +01:00
|
|
|
"noUnusedLocals": false,
|
|
|
|
"noUnusedParameters": false,
|
2016-12-31 00:34:49 +01:00
|
|
|
"forceConsistentCasingInFileNames": true,
|
|
|
|
"strictNullChecks": true
|
|
|
|
},
|
|
|
|
"files": [
|
Add a compiler module
This change adds a simple compiler module that hosts TypeScript and
compiles a program. The compile function takes a path and optional options
data structure; the path can be one of three things: 1) a path to a single `*.ts`
file, in which case it, and it alone, is compiled; 2) a path to a `tsconfig.json`
file, in which case it is loaded, parsed, and used to drive compilation just
like the `tsc` command line driver; or 3) a path to a directory containing a
`tsconfig.json` file, in which case it is discovered and used just like #2.
There is also a new command line driver that just blindly passes arguments to
this compiler API, and prints the results. Next up, this will begin lowering and
transforming the resulting TypeScript AST to MuPack and MuIL.
Note that I've reorganized the source code slightly, so that instead of just
`src/*`, we now have `lib/*` for the library, `cmd/*` for any CLI drivers, and,
soon, `test/*` for test cases.
2016-12-31 20:23:20 +01:00
|
|
|
"cmd/index.ts",
|
|
|
|
|
|
|
|
"lib/index.ts",
|
2016-12-31 21:22:22 +01:00
|
|
|
"lib/ast/index.ts",
|
|
|
|
"lib/ast/definitions.ts",
|
|
|
|
"lib/ast/expressions.ts",
|
|
|
|
"lib/ast/nodes.ts",
|
|
|
|
"lib/ast/source.ts",
|
|
|
|
"lib/ast/statements.ts",
|
Add a compiler module
This change adds a simple compiler module that hosts TypeScript and
compiles a program. The compile function takes a path and optional options
data structure; the path can be one of three things: 1) a path to a single `*.ts`
file, in which case it, and it alone, is compiled; 2) a path to a `tsconfig.json`
file, in which case it is loaded, parsed, and used to drive compilation just
like the `tsc` command line driver; or 3) a path to a directory containing a
`tsconfig.json` file, in which case it is discovered and used just like #2.
There is also a new command line driver that just blindly passes arguments to
this compiler API, and prints the results. Next up, this will begin lowering and
transforming the resulting TypeScript AST to MuPack and MuIL.
Note that I've reorganized the source code slightly, so that instead of just
`src/*`, we now have `lib/*` for the library, `cmd/*` for any CLI drivers, and,
soon, `test/*` for test cases.
2016-12-31 20:23:20 +01:00
|
|
|
"lib/compiler/index.ts",
|
|
|
|
"lib/compiler/compile.ts",
|
2017-01-10 21:42:42 +01:00
|
|
|
"lib/compiler/discover.ts",
|
Add real diagnostics
This change adds a set of true diagnostics constructs, underneath the
new `diag` module.
This includes projecting Mu-specific errors as real diagnostics in a
way that is unified with TypeScript errors. The only difference, of
course, is that Mu errors tend to happen in later passes. But this is
not necessarily always the case.
As part of this, I've rearranged the compiler passes to present a
simpler interface to users of the compiler API (currently just the CLI
and test harness, but it's just a library, so anybody can use it).
Namely, there are three phases:
1. Compilation is the overall process of taking an input path
and driving the entire compilation process, yielding a set of
diagnostics and, ideally, a final MuPackage at the end of it.
2. Script compilation is the process of driving the front-end
compiler -- in this case TypeScript -- yielding a set of Mu
diagnostics and, if that went well, the script's AST.
3. Transformation is the process of taking the script output and
lowering it into the final MuPackage form.
Most people will deal with 1, blissfully unaware of the presence of
independent 2 and 3 phases. We choose to keep them distinct for
white box testing and for future scenarios we have yet to envision.
2017-01-11 21:11:46 +01:00
|
|
|
"lib/compiler/script.ts",
|
2017-01-10 21:42:42 +01:00
|
|
|
"lib/compiler/transform.ts",
|
Add real diagnostics
This change adds a set of true diagnostics constructs, underneath the
new `diag` module.
This includes projecting Mu-specific errors as real diagnostics in a
way that is unified with TypeScript errors. The only difference, of
course, is that Mu errors tend to happen in later passes. But this is
not necessarily always the case.
As part of this, I've rearranged the compiler passes to present a
simpler interface to users of the compiler API (currently just the CLI
and test harness, but it's just a library, so anybody can use it).
Namely, there are three phases:
1. Compilation is the overall process of taking an input path
and driving the entire compilation process, yielding a set of
diagnostics and, ideally, a final MuPackage at the end of it.
2. Script compilation is the process of driving the front-end
compiler -- in this case TypeScript -- yielding a set of Mu
diagnostics and, if that went well, the script's AST.
3. Transformation is the process of taking the script output and
lowering it into the final MuPackage form.
Most people will deal with 1, blissfully unaware of the presence of
independent 2 and 3 phases. We choose to keep them distinct for
white box testing and for future scenarios we have yet to envision.
2017-01-11 21:11:46 +01:00
|
|
|
"lib/diag/index.ts",
|
|
|
|
"lib/diag/context.ts",
|
|
|
|
"lib/diag/diagnostic.ts",
|
Add a compiler module
This change adds a simple compiler module that hosts TypeScript and
compiles a program. The compile function takes a path and optional options
data structure; the path can be one of three things: 1) a path to a single `*.ts`
file, in which case it, and it alone, is compiled; 2) a path to a `tsconfig.json`
file, in which case it is loaded, parsed, and used to drive compilation just
like the `tsc` command line driver; or 3) a path to a directory containing a
`tsconfig.json` file, in which case it is discovered and used just like #2.
There is also a new command line driver that just blindly passes arguments to
this compiler API, and prints the results. Next up, this will begin lowering and
transforming the resulting TypeScript AST to MuPack and MuIL.
Note that I've reorganized the source code slightly, so that instead of just
`src/*`, we now have `lib/*` for the library, `cmd/*` for any CLI drivers, and,
soon, `test/*` for test cases.
2016-12-31 20:23:20 +01:00
|
|
|
"lib/pack/index.ts",
|
2017-01-08 22:20:46 +01:00
|
|
|
"lib/symbols/index.ts",
|
2016-12-31 21:22:22 +01:00
|
|
|
|
2017-01-08 22:20:46 +01:00
|
|
|
"tests/util.ts",
|
|
|
|
"tests/output/index.ts"
|
2016-12-31 00:34:49 +01:00
|
|
|
]
|
|
|
|
}
|
|
|
|
|