Due to https://github.com/golang/go/issues/12294, our Travis jobs are
failing with
pkg/compiler/binder/stmtexpr.go:160: no formatting directive in Errorf call
etc, etc. Perplexingly, this is supposedly fixed as of Go 1.7.5, and we are
running Go 1.8.2 in Travis. However, vet is a separate binary tool, so it seems
either (1) Go's Linux distro doesn't contain the right version or (2) Travis's
image doesn't contain the right version. I have to imagine (2) is more likely,
except that I can't actually look at the machine (and go vet doesn't have a version)!
For now, we will just skip the -printf checks.
The eval test in its current form depends on the Lumi standard library
as an external dependency. This means that, in order to run the test,
you must first install the standard library. Not only is this poor
practice, it is also interfering with our ability to get our new CI/CD
system up and running. This change fixes all of that by mocking the one
standard library runtime function that we need in order to hook the intrinsic.
This change adds the -v flag so that verbose output is emitted in the
CI/CD logs. Since restore can take a little while, this at least lets
you monitor what it's doing and how long what it's doing is taking...
There isn't a pre-canned Glide distribution for amd64 linux, and the
integration with Glide and Travis isn't nearly as swanky as with Godep
(which essentially works out of the box). Furthermore, Godep has caught
up with Go's vendoring changes since last time I looked, which was the
primary reason I ended up going with Glide in the first place.
We now support the `ManagedPolicyARNs` property on `aws.iam.Role`, enabling pre-defined policies to be attaced to an IAM role as part of it's definition.
To make it easier to discover and work with AWS managed policies, constants for all currently defined AWS managed policy ARNs are provided in the IAM module.
Inline policies are still not yet supported.
This change adds some machinery to make it easier to write evaluator tests,
and also implements some tests for the lumi:runtime/dynamic:isFunction intrinsic.
During various refactorings pertaining to dynamic vs static invoke, the
intrinsics machinery broke in a few ways:
* MaybeIntrinsic needs to happen elsewhere. Rather than doing it at binding
time, we can do it when populating the properties in the first place,
reusing the same property symbol from one access to the next.
* Last week, I refactored the intrinsics module to also have a dynamic sub-
module. The tokens in the Intrinsics map needed to also get updated.
* As a result of the tokens now containing member parts, we can't use
tokens.Token.Name, since it is assumed to be a simple name; instead, we
need to convert to tokens.ModuleMember, and then fetch Name. To be honest,
this is probably worth revisiting, since I think most people would expect
Name to just work regardless of the Token kind. The assert that it be
Simple might be a little overly aggressive...
This checkin fixes these issues. I'm not pushing to master just yet,
however, until there are some solid tests in here to prevent future breakage.
This is triggering the need for all downstream consumers of the Lumi
library to enable experimental decorators support. Given that it's not
even clear where we'll land on this (pending pulumi/lumi#137), and in
fact are actively revisiting the relationship between functions and
assets, I'm removing this annotation.
If a resource has no required properties, there's no need for an
argument object. (In the extreme case, perhaps the resource has
*no* properties.) This is a minor usability thing, but it's far
nicer to write code like
let buck = new Bucket("images");
than it is to write code like
let buck = new Bucket("images", {});
The storing of output properties won't work correctly until pulumi/lumi#90
is completed. The update logic sees properties that weren't supplied by the
developer and thinks this means an update is required; this is easy to fix
but better to just roll into the overall pending change that will land soon.
This change keeps the lumi prefix on our CLI tools.
As @lukehoban pointed out in person, as soon as we do pulumi/coconut#98,
most people (other than compiler authors themselves) won't actually be
typing the commands. And, furthermore, the commands aren't all that bad.
Eventually I assume we'll want something like `lumi-js`, or
`lumi-js-compiler`, so that binaries are discovered dynamically in a way
that is extensible for future languages. We can tackle this during #98.
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.
