maxmustermann/pulumi
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
pulumi/pkg/compiler/errors/binder.go

52 lines
4.1 KiB
Go
Raw Normal View History

Clarify aspects of using the DCO
2017-06-26 23:46:34 +02:00
// Copyright 2016-2017, Pulumi Corporation. All rights reserved.
Lay some groundwork for symbol binding This change lays some groundwork that registers symbols when doing semantic analysis of the resulting AST. For now, that just entails detecting duplicate services by way of symbol registration. Note that we've also split binding into two phases to account for the fact that intra-stack dependencies are wholly legal.
2016-11-16 22:11:58 +01:00
package errors
Clean up errors This change eliminates all traces of the old, legacy errors and warnings. It also renumbers everything so that we don't have any "gaps". Finally, it introduces a factory method for new errors and warnings, private to this package, that ensures we don't accidentally register duplicate IDs.
2017-01-26 02:58:16 +01:00
// Binder errors are in the [500-600) range.
var (
Replace tree-walk-style type binding with token map lookups Now that we have introduced a full blown token map -- new as of just a few changes ago -- we can start using it for all of our symbol binding. This also addresses some order-dependent issues, like intra-module references looking up symbols that have been registered in the token map but not necessarily stored in the relevant parent symbols just yet. Plus, frankly, it's much simpler and uses a hashmap lookup instead of a fairly complex recursive tree walk. I've kept the tree walk case, however, to improve diagnostics upon failure. This allows us to tell developers, for example, that the reason a binding failed was due to a missing package.
2017-01-27 01:49:38 +01:00
ErrorInvalidPackageName = newError(500, "The package name must be a valid identifier")
Implement dynamic loads from the environment¬ This rearranges the way dynamic loads work a bit. Previously, they¬ required an object, and did a dynamic lookup in the object's property¬ map. For real dynamic loads -- of the kind Python uses, obviously,¬ but also ECMAScript -- we need to search the "environment". This change searches the environment by looking first in the lexical¬ scope in the current function. If a variable exists, we will use it.¬ If that misses, we then look in the module scope. If a variable exists¬ there, we will use it. Otherwise, if the variable is used in a non-lval position, an dynamic error will be raised ("name not declared"). If an lval, however, we will lazily allocate a slot for it. Note that Python doesn't use block scoping in the same way that most languages do. This behavior is simply achieved by Python not emitting any lexically scoped blocks other than at the function level. This doesn't perfectly achieve the scoping behavior, because we don't yet bind every name in a way that they can be dynamically discovered. The two obvious cases are class names and import names. Those will be covered in a subsequent commit. Also note that we are getting lucky here that class static/instance variables aren't accessible in Python or ECMAScript "ambiently" like they are in some languages (e.g., C#, Java); as a result, we don't need to introduce a class scope in the dynamic lookup. Some day, when we want to support such languages, we'll need to think about how to let languages control the environment probe order; for instance, perhaps the LoadDynamicExpression node can have an "environment" property.
2017-04-09 01:47:15 +02:00
ErrorMalformedToken = newError(501, "%v token '%v' is malformed: %v")
ErrorMalformedPackageURL = newError(502, "Package URL '%v' is malformed: %v")
ErrorImportNotFound = newError(503, "The imported package '%v' was not found; has it been installed?%v")
ErrorTypeNotFound = newError(504, "Type '%v' could not be found: %v")
ErrorSymbolNotFound = newError(505, "Symbol '%v' could not be found: %v")
ErrorSymbolAlreadyExists = newError(506, "A symbol already exists with the name '%v'")
ErrorIncorrectExprType = newError(507, "Expression has the wrong type; expected '%v', got '%v'")
ErrorMemberNotAccessible = newError(508, "Member '%v' is not accessible (it is %v)")
ErrorExpectedReturnExpr = newError(509, "Expected a return expression of type '%v'")
ErrorUnexpectedReturnExpr = newError(510, "Unexpected return expression; function has no return type (void)")
ErrorDuplicateLabel = newError(511, "Duplicate label '%v': %v")
ErrorUnknownJumpLabel = newError(512, "Unknown label '%v' used in the %v statement")
ErrorCannotNewAbstractClass = newError(513, "Cannot `new` an abstract class '%v'")
ErrorIllegalObjectLiteralType = newError(514,
Clean up errors This change eliminates all traces of the old, legacy errors and warnings. It also renumbers everything so that we don't have any "gaps". Finally, it introduces a factory method for new errors and warnings, private to this package, that ensures we don't accidentally register duplicate IDs.
2017-01-26 02:58:16 +01:00
"The type '%v' may not be used as an object literal type; only records and interfaces are permitted")
Implement dynamic loads from the environment¬ This rearranges the way dynamic loads work a bit. Previously, they¬ required an object, and did a dynamic lookup in the object's property¬ map. For real dynamic loads -- of the kind Python uses, obviously,¬ but also ECMAScript -- we need to search the "environment". This change searches the environment by looking first in the lexical¬ scope in the current function. If a variable exists, we will use it.¬ If that misses, we then look in the module scope. If a variable exists¬ there, we will use it. Otherwise, if the variable is used in a non-lval position, an dynamic error will be raised ("name not declared"). If an lval, however, we will lazily allocate a slot for it. Note that Python doesn't use block scoping in the same way that most languages do. This behavior is simply achieved by Python not emitting any lexically scoped blocks other than at the function level. This doesn't perfectly achieve the scoping behavior, because we don't yet bind every name in a way that they can be dynamically discovered. The two obvious cases are class names and import names. Those will be covered in a subsequent commit. Also note that we are getting lucky here that class static/instance variables aren't accessible in Python or ECMAScript "ambiently" like they are in some languages (e.g., C#, Java); as a result, we don't need to introduce a class scope in the dynamic lookup. Some day, when we want to support such languages, we'll need to think about how to let languages control the environment probe order; for instance, perhaps the LoadDynamicExpression node can have an "environment" property.
2017-04-09 01:47:15 +02:00
ErrorMissingRequiredProperty = newError(515, "Missing required property '%v'")
ErrorUnaryOperatorInvalidForType = newError(516,
Add some quotes to a few error messages
2017-02-08 17:57:54 +01:00
"The operator %v is invalid on operand type '%v'; expected '%v'")
Implement dynamic loads from the environment¬ This rearranges the way dynamic loads work a bit. Previously, they¬ required an object, and did a dynamic lookup in the object's property¬ map. For real dynamic loads -- of the kind Python uses, obviously,¬ but also ECMAScript -- we need to search the "environment". This change searches the environment by looking first in the lexical¬ scope in the current function. If a variable exists, we will use it.¬ If that misses, we then look in the module scope. If a variable exists¬ there, we will use it. Otherwise, if the variable is used in a non-lval position, an dynamic error will be raised ("name not declared"). If an lval, however, we will lazily allocate a slot for it. Note that Python doesn't use block scoping in the same way that most languages do. This behavior is simply achieved by Python not emitting any lexically scoped blocks other than at the function level. This doesn't perfectly achieve the scoping behavior, because we don't yet bind every name in a way that they can be dynamically discovered. The two obvious cases are class names and import names. Those will be covered in a subsequent commit. Also note that we are getting lucky here that class static/instance variables aren't accessible in Python or ECMAScript "ambiently" like they are in some languages (e.g., C#, Java); as a result, we don't need to introduce a class scope in the dynamic lookup. Some day, when we want to support such languages, we'll need to think about how to let languages control the environment probe order; for instance, perhaps the LoadDynamicExpression node can have an "environment" property.
2017-04-09 01:47:15 +02:00
ErrorUnaryOperatorInvalidForOperand = newError(517, "The operator %v is invalid on operand %v; expected %v")
ErrorUnaryOperatorMustBePrefix = newError(518, "The operator %v must be in a prefix position (not postfix)")
ErrorBinaryOperatorInvalidForType = newError(519,
Add some quotes to a few error messages
2017-02-08 17:57:54 +01:00
"The operator %v is invalid on %v operand type '%v'; expected '%v'")
Implement dynamic loads from the environment¬ This rearranges the way dynamic loads work a bit. Previously, they¬ required an object, and did a dynamic lookup in the object's property¬ map. For real dynamic loads -- of the kind Python uses, obviously,¬ but also ECMAScript -- we need to search the "environment". This change searches the environment by looking first in the lexical¬ scope in the current function. If a variable exists, we will use it.¬ If that misses, we then look in the module scope. If a variable exists¬ there, we will use it. Otherwise, if the variable is used in a non-lval position, an dynamic error will be raised ("name not declared"). If an lval, however, we will lazily allocate a slot for it. Note that Python doesn't use block scoping in the same way that most languages do. This behavior is simply achieved by Python not emitting any lexically scoped blocks other than at the function level. This doesn't perfectly achieve the scoping behavior, because we don't yet bind every name in a way that they can be dynamically discovered. The two obvious cases are class names and import names. Those will be covered in a subsequent commit. Also note that we are getting lucky here that class static/instance variables aren't accessible in Python or ECMAScript "ambiently" like they are in some languages (e.g., C#, Java); as a result, we don't need to introduce a class scope in the dynamic lookup. Some day, when we want to support such languages, we'll need to think about how to let languages control the environment probe order; for instance, perhaps the LoadDynamicExpression node can have an "environment" property.
2017-04-09 01:47:15 +02:00
ErrorIllegalAssignmentLValue = newError(520, "Cannot assign to the target LHS expression (not an l-value)")
ErrorIllegalNumericAssignmentLValue = newError(521, "Cannot perform numeric assignment %v on a non-numeric LHS")
ErrorIllegalAssignmentTypes = newError(522, "Cannot assign a value of type '%v' to target of type '%v'")
ErrorCannotInvokeNonFunction = newError(523, "Cannot invoke a non-function; type '%v' is not a function")
ErrorArgumentCountMismatch = newError(524, "Function expects %v arguments; got %v instead")
ErrorConstructorReturnType = newError(525, "Constructor '%v' has a return type '%v'; should be nil (void)")
ErrorConstructorNotMethod = newError(526, "Constructor '%v' is not a method; got %v instead")
ErrorExpectedObject = newError(527,
Implement static properties in the runtime
2017-02-13 14:45:28 +01:00
"Expected an object target for this instance member load operation")
Implement dynamic loads from the environment¬ This rearranges the way dynamic loads work a bit. Previously, they¬ required an object, and did a dynamic lookup in the object's property¬ map. For real dynamic loads -- of the kind Python uses, obviously,¬ but also ECMAScript -- we need to search the "environment". This change searches the environment by looking first in the lexical¬ scope in the current function. If a variable exists, we will use it.¬ If that misses, we then look in the module scope. If a variable exists¬ there, we will use it. Otherwise, if the variable is used in a non-lval position, an dynamic error will be raised ("name not declared"). If an lval, however, we will lazily allocate a slot for it. Note that Python doesn't use block scoping in the same way that most languages do. This behavior is simply achieved by Python not emitting any lexically scoped blocks other than at the function level. This doesn't perfectly achieve the scoping behavior, because we don't yet bind every name in a way that they can be dynamically discovered. The two obvious cases are class names and import names. Those will be covered in a subsequent commit. Also note that we are getting lucky here that class static/instance variables aren't accessible in Python or ECMAScript "ambiently" like they are in some languages (e.g., C#, Java); as a result, we don't need to introduce a class scope in the dynamic lookup. Some day, when we want to support such languages, we'll need to think about how to let languages control the environment probe order; for instance, perhaps the LoadDynamicExpression node can have an "environment" property.
2017-04-09 01:47:15 +02:00
ErrorUnexpectedObject = newError(528,
Implement static properties in the runtime
2017-02-13 14:45:28 +01:00
"Unexpected object target for this static or module load operation")
Implement dynamic loads from the environment¬ This rearranges the way dynamic loads work a bit. Previously, they¬ required an object, and did a dynamic lookup in the object's property¬ map. For real dynamic loads -- of the kind Python uses, obviously,¬ but also ECMAScript -- we need to search the "environment". This change searches the environment by looking first in the lexical¬ scope in the current function. If a variable exists, we will use it.¬ If that misses, we then look in the module scope. If a variable exists¬ there, we will use it. Otherwise, if the variable is used in a non-lval position, an dynamic error will be raised ("name not declared"). If an lval, however, we will lazily allocate a slot for it. Note that Python doesn't use block scoping in the same way that most languages do. This behavior is simply achieved by Python not emitting any lexically scoped blocks other than at the function level. This doesn't perfectly achieve the scoping behavior, because we don't yet bind every name in a way that they can be dynamically discovered. The two obvious cases are class names and import names. Those will be covered in a subsequent commit. Also note that we are getting lucky here that class static/instance variables aren't accessible in Python or ECMAScript "ambiently" like they are in some languages (e.g., C#, Java); as a result, we don't need to introduce a class scope in the dynamic lookup. Some day, when we want to support such languages, we'll need to think about how to let languages control the environment probe order; for instance, perhaps the LoadDynamicExpression node can have an "environment" property.
2017-04-09 01:47:15 +02:00
ErrorInvalidCast = newError(529, "Illegal cast from '%v' to '%v'; this can never succeed")
ErrorModuleAliasTargetNotFound = newError(530, "Module alias target '%v' was not found (from '%v')")
Fix a handful of things * Move checking the validity of a derived class with no constructor from evlauation to binding (verification). Furthermore, make it a verification error instead of an assert, and make the checking complete (i.e., don't just check for the existence of a base class, also check for the existence of a ctor, recursively). * Refactor the constructor accessor out of the evaluator and make it a method, Ctor, on the Function abstraction. * Add a recursive Module population case to property initialization. * Only treat the top-most frame in a module's initializer as belonging to the module scope. This avoids interpreting block scopes within that initializer as belonging to the module scope. Ultimately, it's up to the language compiler to decide where to place scopes, but this gives it more precise control over module scoping. * Assert against unsupported named/star/keyword args in CocoPy.
2017-04-10 17:36:48 +02:00
ErrorDerivedClassHasNoCtor = newError(531, "Class '%v' has no constructor, but its base class '%v' does")
Permit Statements in SequenceExpressions The previous shape of SequenceExpression only permitted expressions in the sequence. This is pretty common in most ILs, however, it usually leads to complicated manual spilling in the event that a statement is needed. This is often necessary when, for example, a compiler is deeply nested in some expression production, and then realizes the code expansion requires a statement (e.g., maybe a new local variable must be declared, etc). Instead of requiring complicated code-gen, this change permits SequenceExpression to contain an arbitrary mixture of expression/statement prelude nodes, terminating with a single, final Expression which yields the actual expression value. The runtime bears the burden of implementing this which, frankly, is pretty trivial.
2017-05-04 19:54:07 +02:00
ErrorSequencePreludeExprStmt = newError(532, "Sequence preludes must consist of expressions and/or statements")
Implement property accessors This change implements property accessors (getters and setters). The approach is fairly basic, but is heavily inspired by the ECMAScript5 approach of attaching a getter/setter to any property slot (even if we don't yet fully exploit this capability). The evaluator then needs to track and utilize the appropriate accessor functions when loading locations. This change includes CocoJS support and makes a dent in pulumi/coconut#66.
2017-05-16 02:46:14 +02:00
ErrorPropertyGetterParamCount = newError(533, "Property getter must not have any parameters; got %v")
ErrorPropertyGetterReturnType = newError(534, "Property getter returned type '%v'; expected '%v'")
ErrorPropertySetterParamCount = newError(535, "Property setter must have exactly 1 parameter; got %v")
ErrorPropertySetterParamType = newError(536, "Property setter parameter is type '%v'; expected '%v'")
Fix a minor error message typo
2017-05-16 02:50:13 +02:00
ErrorPropertySetterReturnType = newError(537, "Property setter returned type '%v'; expected no return type")
Fix empty body issues We recently changed the Resource base type to have no constructor, rather than a manual empty constructor. This ought to work just fine. The LumiJS compiler indeed generates a constructor, however, it is missing a body and when the interpreter tries to invoke it, we crash with a nil reference panic. The runtime actually tolerates missing constructors entirely, although the way LumiJS binds super calls doesn't tolerate the missing base constructor. This change simply generates such constructors in LumiJS with empty bodies. In addition, I've added an error that will catch the empty body problem during binding, since technically speaking, all functions must have bodies. (Our runtime happens to support the notion of "abstract", however, so we only fire the error on concrete functions.)
2017-06-14 19:30:46 +02:00
ErrorMethodsMustHaveBodies = newError(538, "Non-abstract methods must have bodies: '%v' is %v")
Lay some groundwork for symbol binding This change lays some groundwork that registers symbols when doing semantic analysis of the resulting AST. For now, that just entails detecting duplicate services by way of symbol registration. Note that we've also split binding into two phases to account for the fact that intra-stack dependencies are wholly legal.
2016-11-16 22:11:58 +01:00
)
Reference in a new issue Copy permalink