Nevermind, if I load factory defaults, the current default works fine with freestyle. Something is wrong with how the collections interact with freeing FreeStyle in the old file. (There might be a bug hidden in here, but it could just be a bug in the old defaults file). Thanks for fixing this by the way, it's great!
Jan 10 2019
Jan 5 2019
Sorry, I was working through the callback and I saw a mention of the scene collection. I tried taking the default scene back to the factory defaults, and now it works. So for some reason, the default scene that was saved when I started using 2.8 causes problems now. I'll reopen if that's incorrect and it is infact an intermittent crash. I've tried several times and it only crashes if I don't load factory defaults first.
Now I get a segfault instead of a black render when opening a new file, activating freestyle, then rendering. Still macOS.
Jan 3 2019
Dec 28 2018
I've seen this crash as well, and was about to report it when I found this issue. I am on macOS, and just rebuilt Blender 2.8. It's really hard to consistently reproduce at the same point, but it does happen somewhere in the steps I was doing:
If you open a new file, activate freestyle, then render, the image turns black when freestyle runs. If you switch to 'relative' line thickness mode, it segfaults blender instead. Changing to Cycles fixes the problem (though freestyle is quite slow on cycles, just like 2.7).
Dec 22 2018
That patch only protects one of the places, not both - I don't think the includes are ordered in such a way where that stops all the warnings. I still get lots of warnings for when the Cycles header in included first.
Dec 21 2018
I noticed this too, and was about to submit an issue. I think you can use #ifndef instead of #if !defined(. I would also probably put it on both definitions since GCC7+ would still produce warnings. The cleanest way would be to simply wrap the whole if else with an ifndef.