Support `@nosideeffects` all code (not just externs)
See original GitHub issueThere are many scenarios where the developer knows that code has no side-effects but the CC fails to detect it and retains the code.
CC already has @nosideeffects
annotation, but that one only works in externs file. Could we make it work in normal code as well?
Issue Analytics
- State:
- Created 7 years ago
- Comments:9 (3 by maintainers)
Top Results From Across the Web
Expressions with no side effects in C++ - Stack Overflow
The Java compiler forbids unreachable code (as opposed to code with no effect), which is a mixed blessing for the programmer, and requires...
Read more >Annotating JavaScript for the Closure Compiler - GitHub
@nosideeffects indicates that a call to the declared function has no side effects. This annotation allows the compiler to remove calls to the...
Read more >Understanding the Restrictions Imposed by the Closure ...
All Compiler optimization levels remove comments, so code that relies on specially formatted comments does not work with the Compiler.
Read more >Pure vs Impure Functions in Functional Programming
A side effect occurs in a program whenever you use external code in your function — which, as a result, impacts the function's...
Read more >Tree Shaking - webpack
A "side effect" is defined as code that performs a special behavior when imported, other than exposing one or more exports. An example...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Sorry to be commenting on an old thread, but this is the only one I’ve found to be remotely relevant to the question I am about to ask. Babel 7 now emits
#__PURE__
annotations in order to improve tree-shake-ability when the transpiled output is consumed by Uglify. References: babel/babel#6209, babel/babel#5632, https://github.com/mishoo/UglifyJS2/commit/1e51586996ae4fdac68a8ea597c20ab170809c43, and theside_effects
compiler option in Uglify’s README. I was wondering if Google Closure Compiler also supports or plans to support this annotation at some point in the future?The compiler side effects computation could definitely use some improvement.
As an alternative to adding “@nosideeffects” someone could invest time into making the PureFunctionIdentifier more accurate. For example, the following function “f” would be marked as having side effects:
Note that the severity of this is probably reduced by the inline variables pass.
See: https://github.com/google/closure-compiler/blob/de36c96e070dc2f9ad69fb814925af34c4d6c91d/src/com/google/javascript/jscomp/PureFunctionIdentifier.java#L58
And: https://github.com/google/closure-compiler/blob/26b48d2562494a46c74a193fd65f6be872933285/src/com/google/javascript/jscomp/NodeUtil.java#L4238
Tests to be improved: https://github.com/google/closure-compiler/blob/de36c96e070dc2f9ad69fb814925af34c4d6c91d/test/com/google/javascript/jscomp/PureFunctionIdentifierTest.java#L947
https://github.com/google/closure-compiler/blob/de36c96e070dc2f9ad69fb814925af34c4d6c91d/test/com/google/javascript/jscomp/PureFunctionIdentifierTest.java#L1321
https://github.com/google/closure-compiler/blob/de36c96e070dc2f9ad69fb814925af34c4d6c91d/test/com/google/javascript/jscomp/PureFunctionIdentifierTest.java#L697
Perhaps I should open a new bug for that, or maybe there already is one…