FCurve: Setting extrapolation needs to recalc handles
Fix T40388: 2.70a - Blender Render - Texture Stack - persistent checkbox state.

Reset 'use_texture' flag of a material tex slot when creating/assigning
a texture to an empty slot.
Fix T40399, OpenCL compile error.
Fix T40383: Keying node doesn't work

We should actually re-consider whether zero-sized kernels are allowed
for edge detection.
Fix T40403: Particles disappear after rendering

Read the comment in ensure_curve_cache, it tells it all.
Style cleanup
Fix T40272: Error setting option flags2 to value fastpskip
Add asserts to BKE_mesh_normals_loop_split
Fix T40405: Blender crashes on FBX export instantly.

This crash can only happen in case faces in same 'smooth fan' have reversed normals.
To support this, we have to always keep a way to get real values in loop_to_poly,
even when loop itself is tagged as done, it might be needed in computation of one of
its neighbor's split normal later.
Fix mask transform when display aspect is not 1:1

Requires some more intense testing.
Fix T40338: Vertex transform origin ignores Normalize option in graph editor

Simply apply unit scale on curve transdata and un-apply on flush.

Needs some more intense testing tho.
Fix T40386: cycles anisotropic BSDF difference between SVM and OSL.
Found another bmesh func that invalidates loop indices...
Fix T40405: Blender crashes on FBX export instantly.
Better fix than rBbef5cb3aa2e5a: consider edges between faces with opposed normals as sharp.

In fact, previous code was broken more deeply in this case (inconsistent normals across
a 'smooth fan') - some loop normals would even never be computed!

Fixing this is possible (even wrote it, actually), but this adds more complexity
to a piece of code that is already awfully complicated, *and* normals in that kind
of smooth fan do not make much sense anyway. So simpler and nicer results with
assuming sharp edges between such 'opposed' faces!

Note that there is some face (loop) ordering black magic at work here, added more comments
to try to explain how and why all this works.

As a bonus, we do not need to check for already computed loop normals anymore, since we
know each 'smooth fan' will be walked once, and only once.
Fix T40157: Loading movies larger than 4GB in size fails

Issue was caused by _wstat returning EOVERFLOW error because
of file size didn't fit into stat structure which was using
long datatype.

The idea of this patch is to use _wstat64 and _stat64 structure
which is capable storing 64bit file sizes.

Made it a typedef for stat structure used by BLI_stat function
in order to make code easier to follow and avoid ifdefs all
over the place.

Additionally solved issue with BLI_exists which was wrongly
returning False in cases destination file is larger then 4GB.
Fix T40412: Moving mask layers does not invalidate mask drawing in the movie clip editor

Issue was caused by a missing WM_event_add_notifier(..) in the mask_layer_move_exec() function...
Add notifiers and reuse update calls for flood fill operators
Related to T40381,

Cleanup the normal flag or else the smooth tool will work on more and
more nodes as we sculpt.
Fix T40381 and revert previous commit.

Looks like the normal update flag is used internally in the modifier
itself. So as a workaround just pass normal update to the nodes when
flood filling
Revert "fix T40375 Glossy shader bakes different than render"

This reverts commit 12abe94de827d9ae9c0dd6cc49bc6c3e377842ad.

After a long discussion in the bug tracker we decided baking should use
the faces normals for glossy (and combined). This is what Blender
Internal is doing, and one of the more predictable way of yielding
predictable results.

That also means the result will not match the render perfectly, but this
is preferrable over the alternatives at hand.

Conflicts:
	intern/cycles/kernel/kernel_bake.h