opened
brad4d
username_0
I got this idea from a suggestion that we add a check for, probably accidental, calls to x.prototype.foo()
instead of x.prototype.foo.apply() (or call()).

It's a good idea, but probably not worth spending closure-compiler eng time on. It would be great if people could quickly write their own errors and warnings like this one by using a DSL like the one used by refasterJS, just a bit of JS template with annotations. For this example, I'm thinking it would look something like this.

/**
 * Warn if code calls a method on func.prototype directly instead of using its call() or apply() method.
 * @param {Function} func
 * @identifierParam someFunc
 * @warning Direct call to prototype method. Did you mean to use apply() or call()?
 */
function warning_prototypeMethodCall(func, someFunc) {
  func.prototype.someFunc(/** @anyParameters */);
}

There would be a compiler option to specify one or more files containing such templates to be used during compilation.

This could even be extended to optimizations or other code modification.
Closure-compiler eng could use this as a quick way to prototype an optimization.
Provide refasterJS-style DSL to allow quick definition of custom compiler passes
issue
created
MatrixFrog
username_1
cc @username_2 who created RefasterJS
comment
created
mknichel
username_2
Hi @username_0 ,

You can use RefasterJS syntax with the Closure Compiler conformance framework (https://github.com/google/closure-compiler/wiki/JS-Conformance-Framework - BANNED_CODE_PATTERN).

Have you seen this before? Are you asking for something that's not possible with that?
comment
created
brad4d
username_0
That's a very good point, @username_2. I'm not very familiar with the
conformance framework, which is why I forgot about it here.
I know it can prevent compilation of banned code patterns.
Can it also just warn?
Can it modify the AST also?

Thanks,
Bradford
comment
created
mknichel
username_2
I don't think you can cause one particular conformance rule to warn while the rest error, but I think you can cause all conformance violations to warn by setting the level for JSC_CONFORMANCE_VIOLATION..

Right now there's no support for transforming code in the compiler with the RefasterJS syntax. It's something that we have discussed before, but so far we've never come up with a use case to implement it.
comment
created
brad4d
username_0
So to sum-up the current state of things:

- The JS conformance framework will allow users to forbid or give warnings for code patterns they define, but it isn't fine-grained enough now to treat some patterns as errors and others as warnings.
- RefasterJS can be used for code transformations, but the compiler doesn't support incorporating such transformations into a compiler pass.

So, suppose I'm a super power user, and I really want to define my own custom code manipulation, warnings, and errors on top of what the compiler can provide. The current solution would be a tool chain that looks something like this.

Whenever compilation is needed...
1. Run RefasterJS over the code with my custom code modification definitions.
2. Get my custom warnings by running the compiler once with minimal code modification options, JS Conformance errors treated as warnings, and my custom "warnings" JS Conformance specifications.
3. Run the compiler again with all the options I want enabled and my custom JS Conformance error specifications.

So, all this is do-able if a bit awkward in places.

It seems reasonable to just use RefasterJS for custom code modification.
The main awkwardness is around defining some code patterns as warnings and others as errors.
Allowing separate specification of error and warning conformance patterns in a single invocation of the compiler at least doesn't *sound* like it would be difficult, but there are a lot of more important things to work on, so I'll just close this.

Thanks.
comment
closed
brad4d
username_0
issue
created
concavelenz
username_3
There was some discussion and proposal to create conformance rule "level"  (lint, warning, error) but I haven't implemented it.
comment
created
mknichel
username_2
We're still discussing how to classify conformance errors (security, lint, performance, etc.) - we may propose something to you in the upcoming months.
comment