Lexer fails to parse regex literal: /\\/

[ComFreek]

Plunker: http://plnkr.co/edit/pNtjb67O8OQa2SS3P4Ed?p=preview

The following code throws a lexer error:

<div ng-style="{'': /\\/}"></div>

The lexer seems to fail at the regex literal /\\/.

The error message:

Error: [$parse:lexerr] Lexer Error: Unexpected next character  at columns 6-6 [\] in expression [{'': /\\/}].

The raw error dump from Chrome's dev tools:

Error: [$parse:lexerr] Lexer Error: Unexpected next character  at columns 6-6 [\] in expression [{'': /\\/}].
http://errors.angularjs.org/1.3.2/$parse/lexerr?p0=Unexpected%20nextharacter%20&p1=s%206-6%20%5B%5C%5D&p2=%7B''%3A%20%2F%5C%5C%2F%7D
    at REGEX_STRING_REGEXP (https://code.angularjs.org/1.3.2/angular.js:80:12)
    at Lexer.throwError (https://code.angularjs.org/1.3.2/angular.js:11626:11)
    at Lexer.lex (https://code.angularjs.org/1.3.2/angular.js:11585:16)
    at Parser.parse (https://code.angularjs.org/1.3.2/angular.js:11798:30)
    at $parse (https://code.angularjs.org/1.3.2/angular.js:12481:39)
    at Scope.$get.Scope.$watch (https://code.angularjs.org/1.3.2/angular.js:13631:19)
    at https://code.angularjs.org/1.3.2/angular.js:24623:9
    at invokeLinkFn (https://code.angularjs.org/1.3.2/angular.js:8125:9)
    at nodeLinkFn (https://code.angularjs.org/1.3.2/angular.js:7637:11)
    at compositeLinkFn (https://code.angularjs.org/1.3.2/angular.js:6993:13)

Note: The bug can be easily circumvented by placing the regex literal into a controller method or the like.

[pkozlowski-opensource]

I don't think it was ever the intention to parse literal regexp expressions:
http://plnkr.co/edit/nz8okjthzzK61keFon91?p=preview

[pkozlowski-opensource]

@petebacondarwin @lgalfaso @caitp what do you guys think? I would say "won't fix" and update https://docs.angularjs.org/guide/expression but yeh, wanted to check with you.

[caitp]

I feel like it's a wontfix

[lakario]

A more practical (albeit contrived) example, perhaps:

<!-- item.color = "red orange" -->
<span ng-style="{'color': item.color.replace(/ /g, '-')}">

[caitp]

I don't think this is something that we want to support, mainly for performance reasons, but also because it's just kind of ugly instead.

If someone did want something like that, it would be a great place to use a filter

<span ng-style="{color: item.color | hyphenate}">

or something

[pkozlowski-opensource]

Yeh, I'm with @caitp - a filter is far more elegant (and testable!) in this case. I'm going to put together a PR with the doc update stating clearly that we don't support regexp literals in expressions - unless someone is strongly opposed.

[lakario]

Seems reasonable.

[caitp]

cool, lets close this then. @ComFreek does that work for you?

[ComFreek]

@caitp Yes, using a filter seems to be a good fit for my use case (encoding a URL while replacing slashes). Thanks for the quick replies!