google/closure-compiler

Polymer pass crashes when "properties" is not an object literal

Open

#1,950 opened on Aug 11, 2016

View on GitHub
 (0 comments) (0 reactions) (0 assignees)Java (1,197 forks)batch import
help wanted

Repository metrics

Stars
 (7,176 stars)
PR merge metrics
 (Avg merge 3d 4h) (1 merged PR in 30d)

Description

https://closure-compiler-debugger.appspot.com/#input0%3DPolymer(%257B%250A%2520%2520is%253A%2520'x-y'%252C%250A%2520%2520properties%253A%2520(function()%2520%257B%250A%2520%2520%2520%2520return%2520%257B%257D%253B%250A%2520%2520%257D)()%252C%250A%257D)%26input1%26conformanceConfig%26externs%3Dvar%2520Polymer%2520%253D%2520function(obj)%2520%257B%257D%250Avar%2520PolymerElement%2520%253D%2520function(obj)%2520%257B%257D%26refasterjs-template%26includeDefaultExterns%3D1%26CHECK_SYMBOLS%3D1%26CHECK_TYPES%3D1%26CLOSURE_PASS%3D1%26LANG_IN_IS_ES6%3D1%26MISSING_PROPERTIES%3D1%26POLYMER_PASS%3D1%26PRESERVE_TYPE_ANNOTATIONS%3D1%26PRETTY_PRINT%3D1%26TRANSPILE%3D1

We don't want to allow this, I don't think. But we should report an error rather than crashing :)

Contributor guide

Research direction
Locate the Polymer pass code in the Closure Compiler and identify the code path that assumes 'properties' is an object literal. Modify it to handle non object literal values and throw a descriptive error instead of crashing.
Tech stack
java
Domain
frontend
Issue type
Bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
2
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-3 hours
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
GitJava
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
75