Fix destructuring evaluation with call expressions

[danez]

Q	A
Bug fix?	yes
Breaking change?	no
New feature?	no
Deprecations?	no
Spec compliancy?	no
Tests added/pass?	yes
Fixed tickets	#4054
License	MIT
Doc PR

Do not optimize destructions with callExpressions or memberExpressions, as the call
might change the value of a variable that we are assigning to and memberExpressions might be getters with side effects.

[codecov-io]

Current coverage is 88.35% (diff: 100%)

Merging #4552 into master will increase coverage by <.01%

@@             master      #4552   diff @@
==========================================
  Files           194        194          
  Lines         13624      13626     +2   
  Methods        1427       1427          
  Messages          0          0          
  Branches       3151       3153     +2   
==========================================
+ Hits          12037      12039     +2   
  Misses         1587       1587          
  Partials          0          0          

Powered by Codecov. Last update d7533e8...b04cbdb

[overlookmotel]

Please see my comments in original issue here: #4054 (comment)

[overlookmotel]

Can I ask, does t.isMemberExpression(elem) return true if elem represents a variable (not a property of an object)?

As I mentioned in 2nd part of my comment #4054 (comment), I think in some (fairly niche) circumstances this can be unsafe to optimize too.

I don't know what babel's policy is on balancing optimization versus rock solid reliability. Perhaps the edge cases I'm pointing out are really pretty unlikely to ever occur in the real world, but hey, I value reliability over pretty much anything else.

[hzoo]

@overlookmotel I think we would tend to lean on the reliability side. smaller/faster output can go under a loose mode option or on the opposite side a spec option?

[hzoo]

lgtm can always make another pr for others