maxmustermann/pulumi
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
pulumi/pkg/tokens/constants.go

45 lines
1.6 KiB
Go
Raw Normal View History

Add license headers
2018-05-22 21:43:36 +02:00
// Copyright 2016-2018, Pulumi Corporation.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
Create MuPack and MuIL packages in our Go toolset This change carries over all of the metadata shapes in the MuPack and MuIL file formats to our Go toolset. This includes creating a proper discriminated AST type tree along with correct annotations so that the metadata will serialize and deserialize correctly.
2017-01-13 23:32:10 +01:00
Begin overhauling semantic phases This change further merges the new AST and MuPack/MuIL formats and abstractions into the core of the compiler. A good amount of the old code is gone now; I decided against ripping it all out in one fell swoop so that I can methodically check that we are preserving all relevant decisions and/or functionality we had in the old model. The changes are too numerous to outline in this commit message, however, here are the noteworthy ones: * Split up the notion of symbols and tokens, resulting in: - pkg/symbols for true compiler symbols (bound nodes) - pkg/tokens for name-based tokens, identifiers, constants * Several packages move underneath pkg/compiler: - pkg/ast becomes pkg/compiler/ast - pkg/errors becomes pkg/compiler/errors - pkg/symbols becomes pkg/compiler/symbols * pkg/ast/... becomes pkg/compiler/legacy/ast/... * pkg/pack/ast becomes pkg/compiler/ast. * pkg/options goes away, merged back into pkg/compiler. * All binding functionality moves underneath a dedicated package, pkg/compiler/binder. The legacy.go file contains cruft that will eventually go away, while the other files represent a halfway point between new and old, but are expected to stay roughly in the current shape. * All parsing functionality is moved underneath a new pkg/compiler/metadata namespace, and we adopt new terminology "metadata reading" since real parsing happens in the MetaMu compilers. Hence, Parser has become metadata.Reader. * In general phases of the compiler no longer share access to the actual compiler.Compiler object. Instead, shared state is moved to the core.Context object underneath pkg/compiler/core. * Dependency resolution during binding has been rewritten to the new model, including stashing bound package symbols in the context object, and detecting import cycles. * Compiler construction does not take a workspace object. Instead, creation of a workspace is entirely hidden inside of the compiler's constructor logic. * There are three Compile* functions on the Compiler interface, to support different styles of invoking compilation: Compile() auto- detects a Mu package, based on the workspace; CompilePath(string) loads the target as a Mu package and compiles it, regardless of the workspace settings; and, CompilePackage(*pack.Package) will compile a pre-loaded package AST, again regardless of workspace. * Delete the _fe, _sema, and parsetree phases. They are no longer relevant and the functionality is largely subsumed by the above. ...and so very much more. I'm surprised I ever got this to compile again!
2017-01-18 21:18:37 +01:00
package tokens
Create MuPack and MuIL packages in our Go toolset This change carries over all of the metadata shapes in the MuPack and MuIL file formats to our Go toolset. This includes creating a proper discriminated AST type tree along with correct annotations so that the metadata will serialize and deserialize correctly.
2017-01-13 23:32:10 +01:00
Use export tables This change redoes the way module exports are represented. The old mechanism -- although laudible for its attempt at consistency -- was wrong. For example, consider this case: let v = 42; export { v }; The old code would silently add *two* members, both with the name "v", one of which would be dropped since the entries in the map collided. It would be easy enough just to detect collisions, and update the above to mark "v" as public, when the export was encountered. That doesn't work either, as the following two examples demonstrate: let v = 42; export { v as w }; let x = w; // error! This demonstrates: * Exporting "v" with a different name, "w" to consumers of the module. In particular, it should not be possible for module consumers to access the member through the name "v". * An inability to access the exported name "w" from within the module itself. This is solely for external consumption. Because of this, we will use an export table approach. The exports live alongside the members, and we are smart about when to consult the export table, versus the member table, during name binding.
2017-02-13 18:56:25 +01:00
// Accessibility determines the visibility of a class member.
type Accessibility string
Fix up a bunch of `golint` errors
2017-01-28 00:42:39 +01:00
Use export tables This change redoes the way module exports are represented. The old mechanism -- although laudible for its attempt at consistency -- was wrong. For example, consider this case: let v = 42; export { v }; The old code would silently add *two* members, both with the name "v", one of which would be dropped since the entries in the map collided. It would be easy enough just to detect collisions, and update the above to mark "v" as public, when the export was encountered. That doesn't work either, as the following two examples demonstrate: let v = 42; export { v as w }; let x = w; // error! This demonstrates: * Exporting "v" with a different name, "w" to consumers of the module. In particular, it should not be possible for module consumers to access the member through the name "v". * An inability to access the exported name "w" from within the module itself. This is solely for external consumption. Because of this, we will use an export table approach. The exports live alongside the members, and we are smart about when to consult the export table, versus the member table, during name binding.
2017-02-13 18:56:25 +01:00
// Accessibility modifiers.
Progress on the `mu describe` command This change makes considerable progress on the `mu describe` command; the only thing remaining to be implemented now is full IL printing. It now prints the full package/module structure. For example, to print the set of exports from our scenarios/point test: $ mujs tools/mujs/tests/output/scenarios/point/ | mu describe - -e package "scenarios/point" { dependencies [] module "index" { class "Point" [public] { method "add": (other: any): any property "x" [public, readonly]: number property "y" [public, readonly]: number method ".ctor": (x: number, y: number): any } } } This is just a pretty-printed, but is coming in handy with debugging.
2017-01-16 20:47:21 +01:00
const (
Use export tables This change redoes the way module exports are represented. The old mechanism -- although laudible for its attempt at consistency -- was wrong. For example, consider this case: let v = 42; export { v }; The old code would silently add *two* members, both with the name "v", one of which would be dropped since the entries in the map collided. It would be easy enough just to detect collisions, and update the above to mark "v" as public, when the export was encountered. That doesn't work either, as the following two examples demonstrate: let v = 42; export { v as w }; let x = w; // error! This demonstrates: * Exporting "v" with a different name, "w" to consumers of the module. In particular, it should not be possible for module consumers to access the member through the name "v". * An inability to access the exported name "w" from within the module itself. This is solely for external consumption. Because of this, we will use an export table approach. The exports live alongside the members, and we are smart about when to consult the export table, versus the member table, during name binding.
2017-02-13 18:56:25 +01:00
PublicAccessibility Accessibility = "public"
PrivateAccessibility Accessibility = "private"
ProtectedAccessibility Accessibility = "protected"
Create MuPack and MuIL packages in our Go toolset This change carries over all of the metadata shapes in the MuPack and MuIL file formats to our Go toolset. This includes creating a proper discriminated AST type tree along with correct annotations so that the metadata will serialize and deserialize correctly.
2017-01-13 23:32:10 +01:00
)
Perform package and module evaluation This change looks up the main module from a package, and that module's entrypoint, when performing evaluation. In any case, the arguments are validated and bound to the resulting function's parameters.
2017-01-26 03:38:53 +01:00
Begin tracking graph dependencies This change refactors the interpreter hooks into a first class interface with many relevant event handlers (including enter/leave functions for packages, modules, and functions -- something necessary to generate object monikers). It also includes a rudimentary start for tracking actual object allocations and their dependencies, a step towards creating a MuGL graph.
2017-02-01 02:42:06 +01:00
// Special module names.
const (
DefaultModule ModuleName = ".default" // used to reference the default module.
)
// Special variable names.
Perform package and module evaluation This change looks up the main module from a package, and that module's entrypoint, when performing evaluation. In any case, the arguments are validated and bound to the resulting function's parameters.
2017-01-26 03:38:53 +01:00
const (
ThisVariable Name = ".this" // the current object (for class methods).
SuperVariable Name = ".super" // the parent class object (for class methods).
)
Begin tracking graph dependencies This change refactors the interpreter hooks into a first class interface with many relevant event handlers (including enter/leave functions for packages, modules, and functions -- something necessary to generate object monikers). It also includes a rudimentary start for tracking actual object allocations and their dependencies, a step towards creating a MuGL graph.
2017-02-01 02:42:06 +01:00
// Special function names.
Perform package and module evaluation This change looks up the main module from a package, and that module's entrypoint, when performing evaluation. In any case, the arguments are validated and bound to the resulting function's parameters.
2017-01-26 03:38:53 +01:00
const (
Run class and module initializers
2017-01-27 23:47:26 +01:00
EntryPointFunction ModuleMemberName = ".main" // the special package entrypoint function.
ModuleInitFunction ModuleMemberName = ".init" // the special module initialization function.
ClassConstructorFunction ClassMemberName = ".ctor" // the special class instance constructor function.
ClassInitFunction ClassMemberName = ".init" // the special class initialization function.
Perform package and module evaluation This change looks up the main module from a package, and that module's entrypoint, when performing evaluation. In any case, the arguments are validated and bound to the resulting function's parameters.
2017-01-26 03:38:53 +01:00
)
Reference in a new issue Copy permalink