Skip to content
This repository has been archived by the owner on Feb 23, 2022. It is now read-only.

Defining and calling mixins from separate files causes "Compiler internal error" #70

Closed
hochhaus opened this issue Nov 3, 2015 · 6 comments

Comments

@hochhaus
Copy link

hochhaus commented Nov 3, 2015

When defining and calling a mixin in separate source files the compiler currently (both 1.0 and HEAD) result in a "Compiler internal error". However, this did not used to be the case. A compiler that I build on Dec 23 2014 compiles these inputs just fine.

ahochhaus@ahochhaus-pc:~/test$ cat def.gss 
@defmixin spriteUrl() {
  background: url('sprite.png') no-repeat;
}
ahochhaus@ahochhaus-pc:~/test$ cat call.gss 
.example {
  @mixin spriteUrl();
}
ahochhaus@ahochhaus-pc:~/test$ java -jar closure-stylesheets.jar def.gss call.gss
Compiler internal error: com.google.common.css.compiler.ast.CssMixinNode cannot be cast to com.google.common.css.compiler.ast.CssDeclarationNode
java.lang.ClassCastException: com.google.common.css.compiler.ast.CssMixinNode cannot be cast to com.google.common.css.compiler.ast.CssDeclarationNode
        at com.google.common.css.compiler.passes.DisallowDuplicateDeclarations.enterRuleset(DisallowDuplicateDeclarations.java:69)
        at com.google.common.css.compiler.ast.DefaultVisitController$VisitRulesetState.doVisit(DefaultVisitController.java:875)
        at com.google.common.css.compiler.ast.DefaultVisitController.startVisit(DefaultVisitController.java:2028)
        at com.google.common.css.compiler.passes.DisallowDuplicateDeclarations.runPass(DisallowDuplicateDeclarations.java:80)
        at com.google.common.css.compiler.passes.PassRunner.runPasses(PassRunner.java:147)
        at com.google.common.css.compiler.commandline.DefaultCommandLineCompiler.parseAndPrint(DefaultCommandLineCompiler.java:130)
        at com.google.common.css.compiler.commandline.DefaultCommandLineCompiler.compile(DefaultCommandLineCompiler.java:116)
        at com.google.common.css.compiler.commandline.DefaultCommandLineCompiler.execute(DefaultCommandLineCompiler.java:157)
        at com.google.common.css.compiler.commandline.ClosureCommandLineCompiler.executeJob(ClosureCommandLineCompiler.java:335)
        at com.google.common.css.compiler.commandline.ClosureCommandLineCompiler.main(ClosureCommandLineCompiler.java:400)
ahochhaus@ahochhaus-pc:~/test$ cat def.gss call.gss > combined.gss
ahochhaus@ahochhaus-pc:~/test$ java -jar closure-stylesheets.jar combined.gss 
.example{background:url('sprite.png') no-repeat}
ahochhaus@ahochhaus-pc:~/test$ java -jar closure-stylesheets-20141223.jar def.gss call.gss 
.example{background:url('sprite.png') no-repeat}
@hochhaus
Copy link
Author

hochhaus commented Nov 3, 2015

I built a few versions of the stylesheets compiler. As best I can tell this code works in (2fd63e3) and fails after (a439723).

@iflan
Copy link
Member

iflan commented Nov 4, 2015

I confirmed this with:

git bisect start
git bisect bad
git bisect good 2fd63e3d5a7a73def76079b43e73a3638aa7d11a
git bisect run /bin/bash -c "ant && java -jar build/closure-stylesheets.jar ../def.gss ../call.gss"

I've looked through that change. The only thing that jumped out at me was the addition of the allowDefPropagation field in JobDescription. I think that may have caused the issue because, as far as I can see, there is no flag to actually turn that on.

I'm going to add a test and fix for this internally, then push it back out.

Thanks for your excellent bug report!

@iflan
Copy link
Member

iflan commented Nov 4, 2015

BTW, there are actually two errors wrapped up in the same bug.

  1. The allowDefPropagation field is false, meaning that mixins defined in one file can't be used in other files. This should print the error:
The name of the mixin matches no mixin definition name in call.gss at line 1 column 12:
.example { @mixin spriteUrl(); }
           ^
  1. The java.lang.ClassCastException causes the parser to exit before the error can be printed.

I've got a fix for (1) that will allow @def and @mixins to propagate by default. It's going to take a bit more work to make fatal errors still report the errors that happened first.

@hochhaus
Copy link
Author

hochhaus commented Nov 4, 2015

Thanks for the prompt reply. Even just fixing (1) allowDefPropagation by default [or with a flag] is good enough for me. The error reporting is far less important from my perspective.

iflan added a commit that referenced this issue Nov 4, 2015
During a previous refactoring, allowDefPropagation got moved to
JobDescription but the ClosureCommandLineCompiler was not updated to set
it or provide a default.

This fixes issue #70 on GitHub.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=107058094
@iflan
Copy link
Member

iflan commented Nov 4, 2015

This should be fixed.

@iflan iflan closed this as completed Nov 4, 2015
@hochhaus
Copy link
Author

hochhaus commented Nov 4, 2015

Thanks! I can confirm that your change resolves my issue.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants