Attachment 368347 Details for Bug 197206 – Patch

[patch] Patch

bug-197206.diff (text/plain), 56.24 KB, created by Don Olmstead on 2019-04-26 13:55:34 PDT

(hide)

Description:

Filename:

MIME Type:

Creator: Don Olmstead

Created: 2019-04-26 13:55:34 PDT

Size: 56.24 KB

patch

obsolete

>diff --git a/ChangeLog b/ChangeLog
>index 1f0e867939f..ec3d4abb17a 100644
>--- a/ChangeLog
>+++ b/ChangeLog
>@@ -1,3 +1,26 @@
>+2019-04-26  Don Olmstead  <don.olmstead@sony.com>
>+
>+        [CMake] Add WEBKIT_EXECUTABLE macro
>+        https://bugs.webkit.org/show_bug.cgi?id=197206
>+
>+        Reviewed by NOBODY (OOPS!).
>+
>+        [CMake] Add WEBKIT_EXECUTABLE macro
>+        https://bugs.webkit.org/show_bug.cgi?id=197206
>+
>+        Reviewed by NOBODY (OOPS!).
>+
>+        Add WEBKIT_EXECUTABLE macro for creating executable targets. This wraps the creation of
>+        executable targets using the same conventions of WEBKIT_FRAMEWORK.
>+
>+        Common code from the two macros were moved to WEBKIT_TARGET which is meant as an internal
>+        macro.
>+
>+        Add WEBKIT_WRAP_EXECUTABLE macro to support Windows targets which use a DLLLauncherMain to
>+        launch the executable.
>+
>+        * Source/cmake/WebKitMacros.cmake:
>+
> 2019-04-25  Fujii Hironori  <Hironori.Fujii@sony.com>
> 
>         Unreviewed, rolling out r244669.
>diff --git a/Source/JavaScriptCore/ChangeLog b/Source/JavaScriptCore/ChangeLog
>index 6114aa50fea..9eedbdea3ff 100644
>--- a/Source/JavaScriptCore/ChangeLog
>+++ b/Source/JavaScriptCore/ChangeLog
>@@ -1,3 +1,23 @@
>+2019-04-26  Don Olmstead  <don.olmstead@sony.com>
>+
>+        [CMake] Add WEBKIT_EXECUTABLE macro
>+        https://bugs.webkit.org/show_bug.cgi?id=197206
>+
>+        Reviewed by NOBODY (OOPS!).
>+
>+        Migrate to WEBKIT_EXECUTABLE for the jsc and test targets.
>+
>+        * b3/air/testair.cpp:
>+        * b3/testb3.cpp:
>+        * dfg/testdfg.cpp:
>+        * shell/CMakeLists.txt:
>+        * shell/PlatformGTK.cmake:
>+        * shell/PlatformJSCOnly.cmake: Removed.
>+        * shell/PlatformMac.cmake:
>+        * shell/PlatformPlayStation.cmake:
>+        * shell/PlatformWPE.cmake:
>+        * shell/PlatformWin.cmake:
>+
> 2019-04-26  Don Olmstead  <don.olmstead@sony.com>
> 
>         Add WTF::findIgnoringASCIICaseWithoutLength to replace strcasestr
>@@ -214,7 +234,7 @@
> 
>         LICM incorrectly assumes it'll never insert a node which provably OSR exits
>         https://bugs.webkit.org/show_bug.cgi?id=196721
>-        <rdar://problem/49556479> 
>+        <rdar://problem/49556479>
> 
>         Reviewed by Filip Pizlo.
> 
>@@ -224,16 +244,16 @@
>         hoist something we provably know will OSR exit. However, this is super rare,
>         and the phase is written in such a way where it's easier to gracefully
>         handle this case than to prevent us from hoisting such code.
>-        
>+
>         If we wanted to ensure we never hoisted code that would provably exit, we'd
>         have to teach the phase to know when it inserted code that provably exits. I
>         saw two ways to do that:
>         1: Save and restore the AI state before actually hoisting.
>         2: Write an analysis that can determine if such a node would exit.
>-        
>+
>         (1) is bad because it costs in memory and compile time. (2) will inevitably
>         have bugs as running into this condition is rare.
>-        
>+
>         So instead of (1) or (2), I opted to have LICM gracefully handle when
>         it causes a provable exit. When we encounter this, we mark all blocks
>         in the loop as !cfaHasVisited and !cfaDidFinish.
>@@ -390,7 +410,7 @@
>         Restructuring the PlayStation's RemoteInspector backend which uses native socket for the communication to be ready for WinCairo.
> 
>         What we did is basically:
>-        - Renamed `remote/playstation/` to `remote/socket/`. This directory is now platform independent implementation of socket backend. 
>+        - Renamed `remote/playstation/` to `remote/socket/`. This directory is now platform independent implementation of socket backend.
>         - Renamed `RemoteInspectorSocket` class to `RemoteInspectorSocketEndpoint`. This class is platform independent and core of the backend.
>         - Merged `RemoteInspectorSocket{Client|Server}` classes into `RemoteInspectorSocketEndpoint` class because the differences are little.
>         - Defined a new interface functions in `Inspector::Socket` (new) namespace.
>@@ -463,27 +483,27 @@
>         Reviewed by Michael Saboff.
> 
>         Let's analyze this control flow diamond:
>-        
>+
>         #0
>         branch #1, #2
>-        
>+
>         #1:
>         PutStack(JSValue, loc42)
>         Jump #3
>-        
>+
>         #2:
>         PutStack(Int52, loc42)
>         Jump #3
>-        
>+
>         #3:
>         ...
>-        
>+
>         Our abstract value for loc42 at the head of #3 will contain an abstract
>         value that us the union of Int52 with other things. Obviously in the
>         above program, a GetStack for loc42 would be inavlid, since it might
>         be loading either JSValue or Int52. However, the abstract interpreter
>         just tracks what the value could be, and it could be Int52 or JSValue.
>-        
>+
>         When I did the Int52 refactoring, I expected such things to never happen,
>         but it turns out it does. We should just allow for this instead of asserting
>         against it since it's valid IR to do the above.
>@@ -662,18 +682,18 @@
>         However, we can't statically guarantee that the arguments between these two
>         ranges was filled out by Load/ForwardVarargs. This is because in the general
>         case we don't know the argument count statically.
>-        
>+
>         However, we used to always emit SetArgumentDefinitely up to "limit - 1" for
>         all arguments, even when some arguments aren't guaranteed to be in a valid
>         state. Emitting these SetArgumentDefinitely were helpful because they let us
>         handle variable liveness and OSR exit metadata. However, when we converted
>         to SSA, we ended up emitting a GetStack for each such SetArgumentDefinitely.
>-        
>+
>         This is wrong, as we can't guarantee such SetArgumentDefinitely nodes are
>         actually looking at a range of the stack that are guaranteed to be initialized.
>         This patch introduces a new form of SetArgument node: SetArgumentMaybe. In terms
>         of OSR exit metadata and variable liveness tracking, it behaves like SetArgumentDefinitely.
>-        
>+
>         However, it differs in a couple key ways:
>         1. In ThreadedCPS, GetLocal(@SetArgumentMaybe) is invalid IR, as this implies
>         you might be loading uninitialized stack. (This same rule applies when you do
>@@ -685,7 +705,7 @@
>         of SetArgumentMaybe.
>         3. In SSA conversion, we don't lower SetArgumentMaybe to GetStack, as there
>         should be no data flow user of SetArgumentMaybe.
>-        
>+
>         SetArgumentDefinitely guarantees that the stack slot is initialized.
>         SetArgumentMaybe makes no such guarantee.
> 
>@@ -769,7 +789,7 @@
> 
>         It is a fairly simple and limited patch, as it only works when the DFG can prove the exact object used as prototype.
>         But when it applies it can be a significant win:
>-                                                        Baseline                   Optim                                       
>+                                                        Baseline                   Optim
>         object-create-constant-prototype              3.6082+-0.0979     ^      1.6947+-0.0756        ^ definitely 2.1292x faster
>         object-create-null                           11.4492+-0.2510     ?     11.5030+-0.2402        ?
>         object-create-unknown-object-prototype       15.6067+-0.1851     ?     15.7500+-0.2322        ?
>@@ -1026,7 +1046,7 @@
>         r244238 lead to some debug failures because we were calling checkConsistency()
>         before doing fixTypeForRepresentation when merging in must handle values in
>         CFA. This patch fixes that.
>-        
>+
>         However, as I was reading over mergeOSREntryValue, I realized it was wrong. It
>         was possible it could merge in a value/type outside of the variable's flushed type.
>         Once the flush format types are locked in, we can't introduce a type out of
>@@ -1121,7 +1141,7 @@
> 
>         1. We diligently write code that first checks if we should speculate Int32.
>         For example:
>-        if (shouldSpeculateInt32()) ... 
>+        if (shouldSpeculateInt32()) ...
>         else if (shouldSpeculateInt52()) ...
> 
>         It would be wrong not to fall back to Int52 if we're dealing with the union of
>@@ -1727,23 +1747,23 @@
>         we represented them with SpecInt32Only and SpecInt52Only. For an Int52,
>         SpecInt32Only meant that the value is in int32 range. And SpecInt52Only meant
>         that the is outside of the int32 range.
>-        
>+
>         However, this got confusing because we reused SpecInt32Only both for JSValue
>         representations and Int52 representations. This actually lead to some bugs.
>-        
>+
>         1. It's possible that roundtripping through Int52 representation would say
>         it produces the wrong type. For example, consider this program and how we
>         used to annotate types in AI:
>         a: JSConstant(10.0) => m_type is SpecAnyIntAsDouble
>         b: Int52Rep(@a) => m_type is SpecInt52Only
>         c: ValueRep(@b) => m_type is SpecAnyIntAsDouble
>-        
>+
>         In AI, for the above program, we'd say that @c produces SpecAnyIntAsDouble.
>         However, the execution semantics are such that it'd actually produce a boxed
>         Int32. This patch fixes the bug where we'd say that Int52Rep over SpecAnyIntAsDouble
>         would produce SpecInt52Only. This is clearly wrong, as SpecAnyIntAsDouble can
>         mean an int value in either int32 or int52 range.
>-        
>+
>         2. AsbstractValue::validateTypeAcceptingBoxedInt52 was wrong in how it
>         accepted Int52 values. It was wrong in two different ways:
>         a: If the AbstractValue's type was SpecInt52Only, and the incoming value
>@@ -1753,21 +1773,21 @@
>         b: If the AbstractValue's type was SpecInt32Only, and the incoming value
>         was an Int32 boxed in a double, this would not validate, even though
>         it should have validated.
>-        
>+
>         Solving 2 was easiest if we segregated out the Int52 type into its own
>         lattice. This patch makes a new Int52 lattice, which is composed of
>         SpecInt32AsInt52 and SpecNonInt32AsInt52.
>-        
>+
>         The conversion rules are now really simple.
>-        
>+
>         Int52 rep => JSValue rep
>         SpecInt32AsInt52 => SpecInt32Only
>         SpecNonInt32AsInt52 => SpecAnyIntAsDouble
>-        
>+
>         JSValue rep => Int52 rep
>         SpecInt32Only => SpecInt32AsInt52
>         SpecAnyIntAsDouble => SpecInt52Any
>-        
>+
>         With these rules, the program in (1) will now correctly report that @c
>         returns SpecInt32Only | SpecAnyIntAsDouble.
> 
>@@ -2362,7 +2382,7 @@
>         for saving and restoring the VM's current Wasm context. Instead of emitting
>         an exception handler, we also teach the unwinder how to read the previous
>         wasm context to restore it as it unwindws past this frame.
>-        
>+
>         This patch is straight forward, and leaves some areas for perf improvement:
>         - We can teach the DFG/FTL to directly use the Wasm calling convention when
>           it knows it's calling a single Wasm function. This way we don't shuffle
>@@ -2371,13 +2391,13 @@
>           optimize arity check failures: https://bugs.webkit.org/show_bug.cgi?id=196564
>         - We bail out to the slow path Double JSValues flowing into i32 arguments.
>           We should teach this thunk how to do that conversion directly.
>-        
>+
>         This patch also refactors the code to explicitly have a single pinned size register.
>         We used pretend in some places that we could have more than one pinned size register.
>         However, there was other code that just asserted the size was one. This patch just rips
>         out this code since we never moved to having more than one pinned size register. Doing
>         this refactoring cleans up the various places where we set up the size register.
>-        
>+
>         This patch is a 50-60% progression on JetStream 2's richards-wasm.
> 
>         * JavaScriptCore.xcodeproj/project.pbxproj:
>@@ -2902,16 +2922,16 @@
>         as long as we prove that all users of the ValueRep can be converted
>         to using the incoming double value. That way we prevent introducing
>         a parallel live range for the double value.
>-        
>+
>         This patch tracks the uses of the ValueRep through Phi variables,
>         so we can convert entire Phi variables to being Double instead
>         of JSValue if the Phi also has only double uses.
>-        
>+
>         This is implemented through a simple escape analysis. DoubleRep(RealNumberUse:)
>         and OSR exit hints are not counted as escapes. All other uses are counted
>         as escapes. Connected Phi graphs are converted to being Double only if the
>         entire graph is ok with the result being Double.
>-        
>+
>         Some ways we could extend this phase in the future:
>         - There are a lot of DoubleRep(NumberUse:@ValueRep(@x)) uses. This ensures
>           that the result of the DoubleRep of @x is not impure NaN. We could
>@@ -2925,7 +2945,7 @@
>         - We can extend this phase to handle Int52Rep if it's profitable.
>         - We can opt other nodes into accepting incoming Doubles so we no longer
>           treat them as escapes.
>-        
>+
>         This patch is somewhere between neutral and a 1% progression on JetStream 2.
> 
>         * JavaScriptCore.xcodeproj/project.pbxproj:
>@@ -3559,11 +3579,11 @@
>         the types that AI proves. This option is too expensive to turn on for our
>         regression testing, but we think it will be valuable in other types of running
>         modes, such as when running with a fuzzer.
>-        
>+
>         This patch also adds options to only probabilistically run this validation
>         after the execution of each node. As the probability is lowered, there is
>         less of a perf hit.
>-        
>+
>         This patch just adds this validation in the FTL. A follow-up patch will land
>         it in the DFG too: https://bugs.webkit.org/show_bug.cgi?id=196219
> 
>@@ -4412,7 +4432,7 @@
>         if the value we're checking against is the empty value, since HeapTop
>         does not include the Empty value. Instead, this check should be
>         isBytecodeTop(), which does account for the empty value.
>-        
>+
>         This patch also does a couple of other things:
>         - For our OSR entry AbstractValues, we were using HeapTop to mark
>          a dead value. That is now changed to BytecodeTop. (The idea here
>@@ -4479,9 +4499,9 @@
> 
>         I found this as part of my work in:
>         https://bugs.webkit.org/show_bug.cgi?id=195924
>-        
>+
>         I'm not sure how to write a test for it.
>-        
>+
>         GetCallee was always reporting that the result is SpecFunction. However,
>         for eval, it may result in just a JSCallee object, which is not a JSFunction.
> 
>@@ -4992,10 +5012,10 @@
>         uses of a node that backwards propagation relied on to be sound.
>         Essentially, backwards propagation relies on being able to see uses
>         that would exist in bytecode to be sound.
>-        
>+
>         The rollout in r242989 was a 1% Speedometer2 regression. This patch
>         rolls back in the optimization in a sound way.
>-        
>+
>         This patch augments the code we had prior to r242989 to be sound. In
>         addition to preserving liveness, we now also convert all uses after
>         the ForceOSRExit to be Phantom. This may pessimize the optimizations
>@@ -5145,7 +5165,7 @@
> 
>         Reviewed by Keith Miller.
> 
>-        1. Making LLIntThunks singleton. 
>+        1. Making LLIntThunks singleton.
> 
>         Motivation: Former implementation has one LLIntThunk per type per VM.
>         However, the generated code for every kind of thunk is essentially the
>@@ -5188,7 +5208,7 @@
>         running each benchmark 6 times and using 95% Student's t distribution
>         confidence interval.
> 
>-        microbenchmarks/generate-multiple-llint-entrypoints.js (Changes uses less memory): 
>+        microbenchmarks/generate-multiple-llint-entrypoints.js (Changes uses less memory):
>             Mean of memory peak on ToT: 122576896 bytes (confidence interval: 67747.2316)
>             Mean of memory peak on Changes: 119248213.33 bytes (confidence interval: 50251.2718)
> 
>@@ -5323,7 +5343,7 @@
>         I tested on JetStream2, and only 4776 functions out of 12035 (that reach the DFG tier) have 24 or fewer elements in it.
>         This is a major problem, because we have 5 Operands in every DFG::BasicBlock, resulting in 2688 bytes of inline capacity per basic block.
>         Still on JetStream 2, functions have an average of 18 BB, but those functions whose operands overflow have an average of 27 BB (so we are wasting 72kB on average when compiling them), and the largest function has 1241 BB (!), for a total of 3.3MB being wasted while it is compiled.
>-        
>+
>         So I removed the inline capacity of the vector in Operands, and here are the results:
>         Baseline Jetstream2:
>         159.741
>@@ -5341,7 +5361,7 @@
>         89.147/89.644/89.395
>         89.102.89.585/89.343
>         88.953/89.536/89.2444
>-        
>+
>         So it looks like a roughly 1% improvement on RAMification (at least the tests where the JIT is enabled), and more surprisingly also a 1% progression on Jetstream2 (although I have more doubts about this one considering the variability in my numbers).
>         I hope to land this, and get more accurate results from the bots.
> 
>@@ -5834,13 +5854,13 @@
>         Reviewed by Michael Saboff.
> 
>         This patch fixes two issues with JSScript API:
>-        
>+
>         1. There was a retain cycle causing us to never destroy a JSScript once it
>-        created a JSSourceCode. The reason for this is that JSScript had a 
>+        created a JSSourceCode. The reason for this is that JSScript had a
>         Strong<JSSourceCode> field. And JSSourceCode transitively had RetainPtr<JSScript>.
>-        
>+
>         This patch fixes this issue by making the "jsSourceCode" accessor return a transient object.
>-        
>+
>         2. r242585 made it so that JSScript would keep the cache file descriptor open
>         (and locked) for the duration of the lifetime of the JSScript itself. Our
>         anticipation here is that it would make implementing iterative cache updates
>@@ -6539,7 +6559,7 @@
> 
>         Reviewed by Darin Adler.
> 
>-        Currently we're throwing a *runtime* SyntaxError; this should occur at parse time. 
>+        Currently we're throwing a *runtime* SyntaxError; this should occur at parse time.
> 
>           12.2.8.1 Static Semantics: Early Errors
>             PrimaryExpression : RegularExpressionLiteral
>@@ -7156,7 +7176,7 @@
>         the completion of the outer try block i.e. { Return, 42 }.
> 
>         This patch makes the following changes:
>-        
>+
>         1. Fix handling of finally completion to use a unique set of completion
>            type and value registers for each FinallyContext.
> 
>@@ -7233,7 +7253,7 @@
>         more restricted semantics now as it's always easier to extend these semantics
>         in the future opposed to having to support the more flexible behavior
>         up front.
>-        
>+
>         This patch also:
>         - Adds error messages if writing the cache fails. We don't expect this to
>           fail, but previously we would say we cached it even if write() fails.
>@@ -7284,14 +7304,14 @@
>         Reviewed by Keith Miller.
> 
>         reportUsedRegisters uses reg liveness to eliminate loads/moves into dead
>-        registers. However, liveness can report incorrect results in certain 
>+        registers. However, liveness can report incorrect results in certain
>         scenarios when considering liveness at instruction boundaries. For example,
>         it can go wrong when an Inst has a LateUse of a register and the following
>         Inst has an EarlyDef of that same register. Such a scenario could lead us
>         to incorrectly say the register is not live-in to the first Inst. Pad
>         interference inserts Nops between such instruction boundaries that cause
>         this issue.
>-        
>+
>         The test with this patch fixes the issue in reportUsedRegisters. This patch
>         also conservatively makes it so that lowerAfterRegAlloc calls padInterference
>         since it also reasons about liveness.
>@@ -8487,7 +8507,7 @@
>         in O0, O1, and O2. However, some tests are invalid for O0 and O1.
>         This patch makes it so we only run those tests in O2. These are
>         often tests that assert certain optimizations have occurred. There
>-        are also a class of tests that rely on using patchpoints to stress 
>+        are also a class of tests that rely on using patchpoints to stress
>         the register allocator into only a single valid allocation. The
>         O0, and sometimes O1, register allocators are not always good enough
>         to allocate such programs. To make these valid allocators to use, we rely
>@@ -9037,19 +9057,19 @@
>         Previous SPI assumes all JSScripts are modules. Previous SPI also assigns
>         a sourceURL to the JSScript based on what the module loader decided the
>         identifier should be. We'll remove this once we remove the old SPI.
>-        
>+
>         This patch also adds SPI to JSContext to evaluate a JSScript. For modules,
>         this is like returning the result of doing dynamic import. For programs,
>         this does normal program evaluation.
>-        
>+
>         This patch also fixes a bug in generateBytecode/generateModuleBytecode where
>         we would try to cache the bytecode even if recursivelyGenerateUnlinkedCodeBlock
>         returned null. E.g, if the script had a syntax error.
>-        
>+
>         When writing tests, I also discovered that someone previously broke
>         testapi. This patch also fixes those failures. They were broken when
>         we switched to using a testapiScripts directory to hold our test .js
>-        scripts. 
>+        scripts.
> 
>         * API/JSAPIGlobalObject.h:
>         * API/JSAPIGlobalObject.mm:
>@@ -9673,7 +9693,7 @@
>         Reviewed by Mark Lam.
> 
>         This can happen in the following scenario:
>-        
>+
>         You have a Structure S. S is on the mark stack. Then:
>         1. S grabs its lock
>         2. S adds a new property transition
>@@ -10124,7 +10144,7 @@
>         in the future. The reason this isn't a deal breaker for Wasm is that this patch
>         makes it so that we reuse Tmps as we're generating Air IR in the AirIRGenerator.
>         Because Wasm is a stack machine, we trivially know when we kill a stack value (its last use).
>-        
>+
>         This patch is another 25% Wasm startup time speedup. It seems to be worth
>         another 1% on JetStream2.
> 
>@@ -12338,12 +12358,12 @@
>         of compiling using  B3-01, we now generate Air code directly.
>         The goal of doing this was to speed up compile times for Wasm
>         programs.
>-        
>+
>         This patch provides us with a 20-30% compile time speedup. However, I
>         have ideas on how to improve compile times even further. For example,
>         we should probably implement a faster running register allocator:
>         https://bugs.webkit.org/show_bug.cgi?id=194036
>-        
>+
>         We can also improve on the code we generate.
>         We should emit better code for Switch: https://bugs.webkit.org/show_bug.cgi?id=194053
>         And we should do better instruction selection in various
>@@ -13372,7 +13392,7 @@
>         https://bugs.webkit.org/show_bug.cgi?id=193797
> 
>         Reviewed by Mark Lam.
>-        
>+
>         Updated feature status for Async Iteration, and Object rest/spread.
> 
>         * features.json:
>@@ -13556,7 +13576,7 @@
>         Reviewed by Michael Saboff.
> 
>         The Object Allocation Sinking phase may move allocations around inside
>-        of the program. However, it was not ensuring that it's still possible 
>+        of the program. However, it was not ensuring that it's still possible
>         to walk the stack at the point in the program that it moved the allocation to.
>         Certain InlineCallFrames rely on data in the stack when taking a stack trace.
>         All allocation sites can do a stack walk (we do a stack walk when we GC).
>@@ -13565,7 +13585,7 @@
>         analysis of stack writes. However, this scenario is so rare that we just
>         take the conservative-and-straight-forward approach of checking that the place
>         we're moving to is the same InlineCallFrame as the allocation site.
>-        
>+
>         In general, this issue arises anytime we do any kind of code motion.
>         Interestingly, LICM gets this right. It gets it right because the only
>         InlineCallFrames we can't move out of are the InlineCallFrames that
>@@ -14357,7 +14377,7 @@
> 
>         Former rule was that ValueOp does not GC. However this is wrong, since
>         these operations can trigger GC and mess up memory management. In the end, this
>-        will generate wrong code because we will have wrong GC epoch value during 
>+        will generate wrong code because we will have wrong GC epoch value during
>         Store Barrier Insertion phase.
>         We changed this to consider BigIntUse for such nodes and properly return true when
>         they are BigIntUse.
>@@ -14738,9 +14758,9 @@
>         Otherwise, we may not think we care about the non-integral part in
>         a division (or perhaps overflow in an add, etc). Consider a program
>         like this:
>-        
>+
>         ```return a / b```
>-        
>+
>         That gets compiled to:
>         ```
>         a: ArithDiv // We don't check that the remainder is zero here.
>@@ -14748,7 +14768,7 @@
>         c: ForceOSRExit
>         d: Unreachable
>         ```
>-        
>+
>         If we don't inform @a that we care about its result in full number
>         accuracy, it will choose to ignore its non-integral remainder. This
>         makes sense if *everybody* that all uses of the Div only cared about
>@@ -15432,18 +15452,18 @@
>         that this is buggy. A UseKind should map to a set of SpeculatedTypes, not an
>         actual set of structures. This patch changes the meaning of StringObjectUse
>         to mean an object where jsDynamicCast<StringObject*> would succeed.
>-        
>+
>         This patch also fixes a bug that was caused by the old and weird usage of the
>         UseKind to mean StructureCheck. Consider a program like this:
>         ```
>         S1 = Original StringObject structure
>         S2 = Original StringObject structure with the field "f" added
>-        
>+
>         a: GetLocal()
>         b: CheckStructure(@a, {S2})
>         c: ToString(StringObject:@a)
>         ```
>-        
>+
>         According to AI, in the above program, we would exit at @c, since
>         StringObject:@a implies a structure check of {S1}, and the intersection
>         of {S1} and {S2} is {}. So, we'd convert the program to be:
>@@ -15453,14 +15473,14 @@
>         c: Check(StringObject:@a)
>         d: Unreachable
>         ```
>-        
>+
>         However, AI would set the proof status of the StringObject:@a edge
>         to be proven, since the SpeculatedType for @a is SpecStringObject.
>         This was incorrect of AI to do because the SpeculatedType itself
>         didn't capture the full power of StringObjectUse. However, having
>         a UseKind mean CheckStructure is weird precisely because what AI was
>         doing is a natural fit to how we typically we think about UseKinds.
>-        
>+
>         So the above program would then incorrectly be converted to this, and
>         we'd crash when reaching the Unreachable node:
>         ```
>@@ -15468,12 +15488,12 @@
>         b: CheckStructure(@a, {S2})
>         d: Unreachable
>         ```
>-        
>+
>         This patch makes it so that StringObjectUse just means that the object that
>         filters through a StringObjectUse check must !!jsDynamicCast<StringObject*>.
>         This is now in line with all other UseKinds. It also lets us simplify a bunch
>         of other code that had weird checks for the StringObjectUse UseKind.
>-        
>+
>         This patch also makes it so that anywhere where we used to rely on
>         StringObjectUse implying a structure check we actually emit an explicit
>         CheckStructure node.
>@@ -16077,7 +16097,7 @@
>         This patch is changing the logic how we lower bitwise operations, to
>         consider only the type of input nodes and fix them during FixupPhase,
>         if necessary. We are also changing the prediction propagation rules
>-        for ValueBitOp to use `getHeapPrediction()`. 
>+        for ValueBitOp to use `getHeapPrediction()`.
> 
>         * dfg/DFGBackwardsPropagationPhase.cpp:
>         (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo):
>@@ -16639,7 +16659,7 @@
>         ForceOSRExit
>         Unreachable
>         ```
>-        
>+
>         Things may definitely be live in bytecode at the tail. However, we'll
>         report nothing as being alive. This probably subtly breaks many analyses,
>         but we have a test case of it breaking the interference analysis that
>@@ -17633,7 +17653,7 @@
>         Reviewed by Joseph Pecoraro.
> 
>         Add InspectorInstrumentation::willFireObserverCallback() and use it to wrap calls
>-        to Intersection Observer, Performance Observer and Mutation Observer callbacks so 
>+        to Intersection Observer, Performance Observer and Mutation Observer callbacks so
>         that they get correctly labeled in the Inspector timeline.
> 
>         * inspector/protocol/Timeline.json:
>@@ -18835,7 +18855,7 @@
>         expect a value to be of type SpecStringVar, but the mutator thread may have
>         converted the string into an Identifier.  This creates a race where
>         AbstractValue::checkConsistency() may fail because it sees a SpecStringIdent when
>-        it expects the a SpecStringVar.  
>+        it expects the a SpecStringVar.
> 
>         The fix is to speculate non-Identifier strings as type SpecString which allows it
>         to be SpecStringVar or SpecStringIndent.
>@@ -19045,7 +19065,7 @@
>         https://bugs.webkit.org/show_bug.cgi?id=187882
> 
>         Reviewed by Keith Miller.
>-        
>+
>         Just remove the "friend class HeapStatistics".
> 
>         * heap/Heap.h:
>@@ -19330,11 +19350,11 @@
> 
>         Reviewed by Keith Miller.
> 
>-        In r238510, I wrote the loop like this: 
>+        In r238510, I wrote the loop like this:
>         `for (ScopeOffset offset { 0 }; offset <= symbolTable->maxScopeOffset(); offset += 1)`
>-        
>+
>         This breaks for scopes of size zero because maxScopeOffset() will be UINT_MAX.
>-        
>+
>         This patch fixes this by writing the loop as:
>         `for (unsigned offset = 0; offset < symbolTable->scopeSize(); ++offset)`
> 
>@@ -19509,12 +19529,12 @@
> 
>         This is a similar bug to what Keith fixed in r232134. The issue is if we have
>         a program like this:
>-        
>+
>         a: JSConstant(jsNumber(0))
>         b: SetLocal(Int32:@a, loc1, FlushedInt32)
>         c: ArrayifyToStructure(Cell:@a)
>         d: Jump(...)
>-        
>+
>         At the point in the program right after the Jump, a GetLocal for loc1
>         would return whatever the ArrayifyToStructure resulting type is. This breaks
>         the invariant that a GetLocal must return a value that is a subtype of its
>@@ -19692,15 +19712,15 @@
>         generated from AI about type checks being proved), but the code we emit in the
>         compiler backend unconditionally generates an OSR exit, even if that exit may
>         never execute. For example, let's say we have this IR:
>-        
>+
>         SomeNode(Boolean:@input)
>-        
>+
>         And we always emit code like this as a way of emitting a boolean type check:
>-        
>+
>         jump L1 if input == true
>         jump L1 if input == false
>         emit an OSR exit
>-        
>+
>         In such a program, when we generate the above OSR exit, in a validationEnabled()
>         build, and if @input is proved to be a boolean, we'll end up crashing because we
>         have the bogus assertion saying !exitOK. This is one reason why things are cleaner
>@@ -19719,7 +19739,7 @@
> 
>         We were asserting that the input edge should have type SpecCell but it should
>         really be SpecCellCheck since the type filter for KnownCellUse is SpecCellCheck.
>-        
>+
>         This patch cleans up that assertion code by joining a bunch of cases into a
>         single function call which grabs the type filter for the edge UseKind and
>         asserts that the incoming edge meets the type filter criteria.
>@@ -20048,31 +20068,31 @@
>         When merging two IC variant lists, we may end up in a world where we have
>         overlapping structure sets. We defend against this when we append a new
>         variant, but we should also defend against it once we merge in a new variant.
>-        
>+
>         Consider this case with MultiPutByOffset, where we merge two PutByIdStatuses
>         together, P1 and P2.
>-        
>+
>         Let's consider these structures:
>         s1 = {}
>         s2 = {p: 0}
>         s3 = {p: 0, p2: 1}
>-        
>+
>         P1 contains these variants:
>         Transition: [s1 => s2]
>         Replace: [s2, s3]
>-        
>+
>         P2 contains:
>         Replace: [s2]
>-        
>+
>         Because of the ordering of the variants, we may end up combining
>         P2's replace into P1's transition, forming this new list:
>         Transition: [(s1, s2) => s2]
>         Replace: [s2, s3]
>-        
>+
>         Obviously the ideal thing here is to have some ordering when we merge
>         in variants to choose the most ideal option. It'd be ideal for P2's
>         Replace to be merged into P1's replace.
>-        
>+
>         If we notice that this is super important, we can implement some kind
>         of ordering. None of our tests (until this patch) stress this. This patch
>         just makes it so we defend against this crazy scenario by falling back
>@@ -20308,20 +20328,20 @@
>         We write transformations in the compiler like this where we emit edges with
>         KnownCellUse if we know we're inserting code at a point where we're dominated
>         by a Cell check:
>-        
>+
>         a: SomeValue
>         b: Something(Cell:@a)
>         c: SomethingElse(@b)
>         d: CheckNotEmpty(@a)
>-        
>+
>         =>
>-        
>+
>         a: SomeValue
>         b: Something(Cell:@a)
>         e: RandomOtherThing(KnownCellUse:@a)
>         c: SomethingElse(@b)
>         d: CheckNotEmpty(@a)
>-        
>+
>         However, doing this used to lead to subtly incorrect programs since KnownCellUse
>         did not allow the empty value to flow through it. We used to end up incorrectly
>         deleting @d in the above program. We fix this, we make KnownCellUse allow the empty
>@@ -20542,7 +20562,7 @@
> 
>         processLogEntries will call into calculatedClassName, which will clear
>         any exceptions it encounters (it assumes that they're stack overflow exceptions).
>-        However, this code may be called when an exception is already pending on the 
>+        However, this code may be called when an exception is already pending on the
>         VM (e.g, when we throw an exception in the DFG, we compile an OSR exit
>         offramp, which may compile a baseline codeblock, which will process
>         the type profiler log). To get around this, processLogEntires should stash
>@@ -20664,7 +20684,7 @@
>         LLINT_BEGIN_NO_SET_PC() at the top of llint_replace.
> 
>         We also do the same for llint_osr.
>-        
>+
>         Note: both of these LLInt slow path functions are called with a fully initialized
>         CallFrame.  Hence, there's no issue with setting topCallFrame to their CallFrames
>         for these functions.
>@@ -20977,7 +20997,7 @@
> 
>         * inspector/protocol/Worker.json:
>         Cleanup, remove empty types list.
>-        
>+
>         * inspector/protocol/Recording.json:
>         Cleanup, only expose this in the "web" domain for now.
> 
>@@ -23795,7 +23815,7 @@
>         in the range of nodes where we can't exit, we would end up generating
>         an invalid exit (and running with validateFTLOSRExitLiveness flag
>         would find this issue).
>-        
>+
>         This patch makes vmCall check to see if the node can exit before
>         emitting an exception check. A node not being able to exit implies
>         that it can't exit for exceptions, therefore, by definition, it can't
>@@ -25468,22 +25488,22 @@
>         For example, the FTL may know more about data flow than AI in certain programs,
>         and it needs to inform AI of these data flow properties to appease the assertion
>         we have in AI that a node must perform type checks on its child nodes.
>-        
>+
>         For example, consider this program:
>-        
>+
>         ```
>         bb#1
>         a: Phi // Let's say it has an Int32 result, so it goes into the int32 hash table in FTLLower
>         Branch(...,  #2, #3)
>-        
>+
>         bb#2
>         ArrayifyToStructure(Cell:@a) // This modifies @a to have the its previous type union the type of some structure set.
>         Jump(#3)
>-        
>+
>         bb#3
>         c: Add(Int32:@something, Int32:@a)
>         ```
>-        
>+
>         When the Add node does lowInt32() for @a, FTL lower used to just grab it
>         from the int32 hash table without filtering the AbstractValue. However,
>         the parent node is asking for a type check to happen, so we must inform
>@@ -26497,7 +26517,7 @@
>         Daegeun Lee <realking@mizi.com> - for pointing out some bugs and providing much code for the String and Date object.
>         Marco Pinelli <pinmc@libero.it> - for his patches
>         Christian Kirsch <ck@held.mind.de> - for his contribution to the Date object
>-        
>+
> 2018-09-24  Fujii Hironori  <Hironori.Fujii@sony.com>
> 
>         Rename WTF_COMPILER_GCC_OR_CLANG to WTF_COMPILER_GCC_COMPATIBLE
>@@ -26552,16 +26572,16 @@
>         the outer macro definition will instead refer to the f argument of the
>         anonymous macro passed to `g`. That leads to this code failing to
>         compile (f expected 0 args but got 1).
>-        
>+
>         ```
>         macro f(x)
>             move x, t0
>         end
>-        
>+
>         macro g(fn)
>             fn(macro () f(42) end)
>         end
>-        
>+
>         g(macro(f) f() end)
>         ```
> 
>@@ -26617,9 +26637,9 @@
>         c: ForceExit
>         d: GetArrayLength(@a, @b)
>         ```
>-        
>+
>         And we will fail DFG validation since @b does not have a result.
>-        
>+
>         The fix is to just remove all nodes after the ForceExit and plant an
>         Unreachable after it. So the above code program will now turn into this:
>         ```
>diff --git a/Source/JavaScriptCore/b3/air/testair.cpp b/Source/JavaScriptCore/b3/air/testair.cpp
>index 9dc9966a944..ef1544c07bb 100644
>--- a/Source/JavaScriptCore/b3/air/testair.cpp
>+++ b/Source/JavaScriptCore/b3/air/testair.cpp
>@@ -2216,3 +2216,10 @@ int main(int argc, char** argv)
> 
>     return 0;
> }
>+
>+#if OS(WINDOWS)
>+extern "C" __declspec(dllexport) int WINAPI dllLauncherEntryPoint(int argc, const char* argv[])
>+{
>+    return main(argc, const_cast<char**>(argv));
>+}
>+#endif
>diff --git a/Source/JavaScriptCore/b3/testb3.cpp b/Source/JavaScriptCore/b3/testb3.cpp
>index ff3b3b53831..7f31679b413 100644
>--- a/Source/JavaScriptCore/b3/testb3.cpp
>+++ b/Source/JavaScriptCore/b3/testb3.cpp
>@@ -18800,3 +18800,9 @@ int main(int argc, char** argv)
>     return 0;
> }
> 
>+#if OS(WINDOWS)
>+extern "C" __declspec(dllexport) int WINAPI dllLauncherEntryPoint(int argc, const char* argv[])
>+{
>+    return main(argc, const_cast<char**>(argv));
>+}
>+#endif
>diff --git a/Source/JavaScriptCore/dfg/testdfg.cpp b/Source/JavaScriptCore/dfg/testdfg.cpp
>index 5335e64661b..6d3322910ad 100644
>--- a/Source/JavaScriptCore/dfg/testdfg.cpp
>+++ b/Source/JavaScriptCore/dfg/testdfg.cpp
>@@ -118,3 +118,10 @@ int main(int argc, char** argv)
> 
>     return 0;
> }
>+
>+#if OS(WINDOWS)
>+extern "C" __declspec(dllexport) int WINAPI dllLauncherEntryPoint(int argc, const char* argv[])
>+{
>+    return main(argc, const_cast<char**>(argv));
>+}
>+#endif
>diff --git a/Source/JavaScriptCore/shell/CMakeLists.txt b/Source/JavaScriptCore/shell/CMakeLists.txt
>index aa7ce64ec1c..434f9c60037 100644
>--- a/Source/JavaScriptCore/shell/CMakeLists.txt
>+++ b/Source/JavaScriptCore/shell/CMakeLists.txt
>@@ -1,101 +1,106 @@
>-set(JSC_SOURCES
>+set(jsc_SOURCES
>     ../jsc.cpp
> )
> 
>-set(JSC_LIBRARIES
>+if ("${JavaScriptCore_LIBRARY_TYPE}" MATCHES "STATIC")
>+    set(jsc_PRIVATE_DEFINITIONS STATICALLY_LINKED_WITH_JavaScriptCore)
>+endif ()
>+
>+set(jsc_LIBRARIES
>     ${CMAKE_DL_LIBS}
>     JavaScriptCore${DEBUG_SUFFIX}
>     WTF${DEBUG_SUFFIX}
> )
> 
>+set(jsc_PRIVATE_INCLUDE_DIRECTORIES
>+    ${JavaScriptCore_INCLUDE_DIRECTORIES}
>+    ${JavaScriptCore_PRIVATE_INCLUDE_DIRECTORIES}
>+    ${JavaScriptCore_PRIVATE_FRAMEWORK_HEADERS_DIR}
>+    ${JavaScriptCore_SYSTEM_INCLUDE_DIRECTORIES}
>+)
>+
> if (WTF_OS_MAC_OS_X)
>-    list(APPEND JSC_LIBRARIES edit)
>+    list(APPEND jsc_LIBRARIES edit)
> endif ()
> 
>-if ("${JavaScriptCore_LIBRARY_TYPE}" MATCHES "STATIC")
>-    add_definitions(-DSTATICALLY_LINKED_WITH_JavaScriptCore)
>+WEBKIT_EXECUTABLE_DECLARE(jsc)
>+
>+if (DEVELOPER_MODE)
>+    set(testapi_SOURCES
>+        ../API/tests/CompareAndSwapTest.cpp
>+        ../API/tests/CustomGlobalObjectClassTest.c
>+        ../API/tests/ExecutionTimeLimitTest.cpp
>+        ../API/tests/FunctionOverridesTest.cpp
>+        ../API/tests/GlobalContextWithFinalizerTest.cpp
>+        ../API/tests/JSONParseTest.cpp
>+        ../API/tests/JSObjectGetProxyTargetTest.cpp
>+        ../API/tests/MultithreadedMultiVMExecutionTest.cpp
>+        ../API/tests/PingPongStackOverflowTest.cpp
>+        ../API/tests/TypedArrayCTest.cpp
>+        ../API/tests/testapi.c
>+        ../API/tests/testapi.cpp
>+    )
>+    set(testapi_DEFINITIONS ${jsc_PRIVATE_DEFINITIONS})
>+    set(testapi_PRIVATE_INCLUDE_DIRECTORIES ${jsc_PRIVATE_INCLUDE_DIRECTORIES})
>+    set(testapi_LIBRARIES JavaScriptCore)
>+
>+    set(testmasm_SOURCES ../assembler/testmasm.cpp)
>+    set(testmasm_DEFINITIONS ${jsc_PRIVATE_DEFINITIONS})
>+    set(testmasm_PRIVATE_INCLUDE_DIRECTORIES ${jsc_PRIVATE_INCLUDE_DIRECTORIES})
>+    set(testmasm_LIBRARIES JavaScriptCore)
>+
>+    set(testRegExp_SOURCES ../testRegExp.cpp)
>+    set(testRegExp_DEFINITIONS ${jsc_PRIVATE_DEFINITIONS})
>+    set(testRegExp_PRIVATE_INCLUDE_DIRECTORIES ${jsc_PRIVATE_INCLUDE_DIRECTORIES})
>+    set(testRegExp_LIBRARIES JavaScriptCore)
>+
>+    set(testb3_SOURCES ../b3/testb3.cpp)
>+    set(testb3_DEFINITIONS ${jsc_PRIVATE_DEFINITIONS})
>+    set(testb3_PRIVATE_INCLUDE_DIRECTORIES ${jsc_PRIVATE_INCLUDE_DIRECTORIES})
>+    set(testb3_LIBRARIES JavaScriptCore)
>+
>+    set(testair_SOURCES ../b3/air/testair.cpp)
>+    set(testair_DEFINITIONS ${jsc_PRIVATE_DEFINITIONS})
>+    set(testair_PRIVATE_INCLUDE_DIRECTORIES ${jsc_PRIVATE_INCLUDE_DIRECTORIES})
>+    set(testair_LIBRARIES JavaScriptCore)
>+
>+    set(testdfg_SOURCES ../dfg/testdfg.cpp)
>+    set(testdfg_DEFINITIONS ${jsc_PRIVATE_DEFINITIONS})
>+    set(testdfg_PRIVATE_INCLUDE_DIRECTORIES ${jsc_PRIVATE_INCLUDE_DIRECTORIES})
>+    set(testdfg_LIBRARIES JavaScriptCore)
>+
>+    WEBKIT_EXECUTABLE_DECLARE(testapi)
>+    WEBKIT_EXECUTABLE_DECLARE(testRegExp)
>+    WEBKIT_EXECUTABLE_DECLARE(testmasm)
>+    WEBKIT_EXECUTABLE_DECLARE(testb3)
>+    WEBKIT_EXECUTABLE_DECLARE(testair)
>+    WEBKIT_EXECUTABLE_DECLARE(testdfg)
> endif ()
> 
>-set(TESTAPI_SOURCES
>-    ../API/tests/CompareAndSwapTest.cpp
>-    ../API/tests/CustomGlobalObjectClassTest.c
>-    ../API/tests/ExecutionTimeLimitTest.cpp
>-    ../API/tests/FunctionOverridesTest.cpp
>-    ../API/tests/GlobalContextWithFinalizerTest.cpp
>-    ../API/tests/JSONParseTest.cpp
>-    ../API/tests/JSObjectGetProxyTargetTest.cpp
>-    ../API/tests/MultithreadedMultiVMExecutionTest.cpp
>-    ../API/tests/PingPongStackOverflowTest.cpp
>-    ../API/tests/TypedArrayCTest.cpp
>-    ../API/tests/testapi.c
>-    ../API/tests/testapi.cpp
>-)
>-
> WEBKIT_INCLUDE_CONFIG_FILES_IF_EXISTS()
> 
>-WEBKIT_WRAP_SOURCELIST(${JSC_SOURCES})
>-WEBKIT_WRAP_SOURCELIST(${TESTAPI_SOURCES})
>-include_directories(./ ${JavaScriptCore_INCLUDE_DIRECTORIES} ${JavaScriptCore_PRIVATE_INCLUDE_DIRECTORIES})
>-include_directories(SYSTEM ${JavaScriptCore_SYSTEM_INCLUDE_DIRECTORIES})
>-add_executable(jsc ${JSC_SOURCES})
>-target_link_libraries(jsc ${JSC_LIBRARIES})
>-
>-if (JSC_OUTPUT_NAME)
>-    set_target_properties(jsc PROPERTIES OUTPUT_NAME ${JSC_OUTPUT_NAME})
>-endif ()
>-
>-if (JSC_LINK_FLAGS)
>-    WEBKIT_ADD_TARGET_PROPERTIES(jsc LINK_FLAGS "${JSC_LINK_FLAGS}")
>-endif ()
>+WEBKIT_EXECUTABLE(jsc)
> 
> if (SHOULD_INSTALL_JS_SHELL)
>     install(TARGETS jsc DESTINATION "${LIBEXEC_INSTALL_DIR}")
> endif ()
> 
>-if (TARGET jscLib)
>-    add_dependencies(jsc jscLib)
>+if (DEVELOPER_MODE)
>+    WEBKIT_EXECUTABLE(testapi)
>+    WEBKIT_EXECUTABLE(testRegExp)
>+    WEBKIT_EXECUTABLE(testmasm)
>+    WEBKIT_EXECUTABLE(testb3)
>+    WEBKIT_EXECUTABLE(testair)
>+    WEBKIT_EXECUTABLE(testdfg)
>+
>+    file(COPY
>+        "${JAVASCRIPTCORE_DIR}/API/tests/testapi.js"
>+        DESTINATION
>+        ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/testapiScripts
>+    )
>+    file(COPY
>+        "${JAVASCRIPTCORE_DIR}/API/tests/testapi-function-overrides.js"
>+        DESTINATION
>+        ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/testapiScripts
>+    )
> endif ()
>-
>-set(TESTMASM_SOURCES
>-    ../assembler/testmasm.cpp
>-)
>-
>-set(TESTB3_SOURCES
>-    ../b3/testb3.cpp
>-)
>-
>-set(TESTAIR_SOURCES
>-    ../b3/air/testair.cpp
>-)
>-
>-set(TESTDFG_SOURCES
>-    ../dfg/testdfg.cpp
>-)
>-
>-if (DEVELOPER_MODE AND NOT WIN32)
>-    add_executable(testmasm ${TESTMASM_SOURCES})
>-    target_link_libraries(testmasm ${JSC_LIBRARIES})
>-
>-    add_executable(testb3 ${TESTB3_SOURCES})
>-    target_link_libraries(testb3 ${JSC_LIBRARIES})
>-
>-    add_executable(testair ${TESTAIR_SOURCES})
>-    target_link_libraries(testair ${JSC_LIBRARIES})
>-
>-    add_executable(testdfg ${TESTDFG_SOURCES})
>-    target_link_libraries(testdfg ${JSC_LIBRARIES})
>-
>-    add_executable(testapi ${TESTAPI_SOURCES})
>-    target_link_libraries(testapi ${JSC_LIBRARIES})
>-endif ()
>-
>-file(COPY
>-    "${JAVASCRIPTCORE_DIR}/API/tests/testapi.js"
>-    DESTINATION
>-    ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/testapiScripts
>-)
>-file(COPY
>-    "${JAVASCRIPTCORE_DIR}/API/tests/testapi-function-overrides.js"
>-    DESTINATION
>-    ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/testapiScripts
>-)
>diff --git a/Source/JavaScriptCore/shell/PlatformGTK.cmake b/Source/JavaScriptCore/shell/PlatformGTK.cmake
>index 623183a2b08..c4ac7c9a209 100644
>--- a/Source/JavaScriptCore/shell/PlatformGTK.cmake
>+++ b/Source/JavaScriptCore/shell/PlatformGTK.cmake
>@@ -1,3 +1,3 @@
>-list(APPEND JSC_LIBRARIES
>+list(APPEND jsc_LIBRARIES
>     ${GLIB_LIBRARIES}
> )
>diff --git a/Source/JavaScriptCore/shell/PlatformJSCOnly.cmake b/Source/JavaScriptCore/shell/PlatformJSCOnly.cmake
>deleted file mode 100644
>index ca4f1271cf7..00000000000
>--- a/Source/JavaScriptCore/shell/PlatformJSCOnly.cmake
>+++ /dev/null
>@@ -1,9 +0,0 @@
>-# FIXME: https://bugs.webkit.org/show_bug.cgi?id=178730
>-# Make the Windows build and other builds work more similarly
>-# rather than having a very different build process with
>-# library/launcher on Windows and build directly into
>-# executable elsewhere
>-if (WIN32)
>-    include(PlatformWin.cmake)
>-    add_definitions(-DWIN_CAIRO)
>-endif ()
>diff --git a/Source/JavaScriptCore/shell/PlatformMac.cmake b/Source/JavaScriptCore/shell/PlatformMac.cmake
>index 7c0fea252e6..830680b24f7 100644
>--- a/Source/JavaScriptCore/shell/PlatformMac.cmake
>+++ b/Source/JavaScriptCore/shell/PlatformMac.cmake
>@@ -1,4 +1,4 @@
>-set(TESTAPI_OBJC_SOURCES
>+set(testapi_OBJC_SOURCES
>     ../API/tests/CurrentThisInsideBlockGetterTest.mm
>     ../API/tests/DateTests.mm
>     ../API/tests/JSExportTests.mm
>@@ -6,6 +6,5 @@ set(TESTAPI_OBJC_SOURCES
>     ../API/tests/Regress141809.mm
>     ../API/tests/testapi.mm
> )
>-list(APPEND TESTAPI_SOURCES ${TESTAPI_OBJC_SOURCES})
>-
>-set_source_files_properties(${TESTAPI_OBJC_SOURCES} PROPERTIES COMPILE_FLAGS -fobjc-arc)
>+list(APPEND testapi_SOURCES ${testapi_OBJC_SOURCES})
>+set_source_files_properties(${testapi_OBJC_SOURCES} PROPERTIES COMPILE_FLAGS -fobjc-arc)
>diff --git a/Source/JavaScriptCore/shell/PlatformPlayStation.cmake b/Source/JavaScriptCore/shell/PlatformPlayStation.cmake
>index 0937f931d0e..56b43d83034 100644
>--- a/Source/JavaScriptCore/shell/PlatformPlayStation.cmake
>+++ b/Source/JavaScriptCore/shell/PlatformPlayStation.cmake
>@@ -1,5 +1,4 @@
>-
>-list(APPEND JSC_SOURCES
>+list(APPEND jsc_SOURCES
>     ${JAVASCRIPTCORE_DIR}/shell/playstation/Initializer.cpp
> )
> 
>@@ -8,4 +7,4 @@ find_library(LIBTESTWRAPPERS testwrappers PATHS ${WEBKIT_LIBRARIES_DIR}/lib)
> set(PLAYSTATION_jsc_PROCESS_NAME "JSCShell")
> set(PLAYSTATION_jsc_MAIN_THREAD_NAME "JSCShell")
> set(PLAYSTATION_jsc_WRAP fopen getcwd main)
>-list(APPEND JSC_LIBRARIES ${LIBTESTWRAPPERS})
>+list(APPEND jsc_LIBRARIES ${LIBTESTWRAPPERS})
>diff --git a/Source/JavaScriptCore/shell/PlatformWPE.cmake b/Source/JavaScriptCore/shell/PlatformWPE.cmake
>index 15754f40598..1bec33b19ca 100644
>--- a/Source/JavaScriptCore/shell/PlatformWPE.cmake
>+++ b/Source/JavaScriptCore/shell/PlatformWPE.cmake
>@@ -1,4 +1,4 @@
>-list(APPEND JSC_LIBRARIES
>+list(APPEND jsc_LIBRARIES
>     ${GLIB_LIBRARIES}
>     ${GLIB_GMODULE_LIBRARIES}
> )
>diff --git a/Source/JavaScriptCore/shell/PlatformWin.cmake b/Source/JavaScriptCore/shell/PlatformWin.cmake
>index aafc629fb63..c1240844913 100644
>--- a/Source/JavaScriptCore/shell/PlatformWin.cmake
>+++ b/Source/JavaScriptCore/shell/PlatformWin.cmake
>@@ -1,40 +1,56 @@
>-include_directories(./ PRIVATE ${JavaScriptCore_INCLUDE_DIRECTORIES} ${JavaScriptCore_PRIVATE_INCLUDE_DIRECTORIES} ${JavaScriptCore_PRIVATE_FRAMEWORK_HEADERS_DIR})
>-include_directories(SYSTEM ${JavaScriptCore_SYSTEM_INCLUDE_DIRECTORIES})
>-add_library(jscLib SHARED ${JSC_SOURCES})
>-
>-list(APPEND JSC_LIBRARIES
>-    Winmm
>-)
>-
>-target_link_libraries(jscLib ${JSC_LIBRARIES})
>+set(wrapper_DEFINITIONS USE_CONSOLE_ENTRY_POINT)
> 
> if (${WTF_PLATFORM_WIN_CAIRO})
>-    add_definitions(-DWIN_CAIRO)
>+    list(APPEND wrapper_DEFINITIONS WIN_CAIRO)
> endif ()
> 
>-set(JSC_SOURCES ${JAVASCRIPTCORE_DIR}/shell/DLLLauncherMain.cpp)
>-set(JSC_LIBRARIES shlwapi)
>-add_definitions(-DUSE_CONSOLE_ENTRY_POINT)
>-
>-set(JSC_OUTPUT_NAME "jsc${DEBUG_SUFFIX}")
>-
>-add_library(testRegExpLib SHARED ../testRegExp.cpp)
>-add_executable(testRegExp ${JSC_SOURCES})
>-set_target_properties(testRegExp PROPERTIES OUTPUT_NAME "testRegExp${DEBUG_SUFFIX}")
>-target_link_libraries(testRegExp shlwapi)
>-add_dependencies(testRegExp testRegExpLib)
>-target_link_libraries(testRegExpLib JavaScriptCore)
>-
>-add_library(testapiLib SHARED ${TESTAPI_SOURCES})
>-add_executable(testapi ${JSC_SOURCES})
>-set_target_properties(testapi PROPERTIES OUTPUT_NAME "testapi${DEBUG_SUFFIX}")
>-target_link_libraries(testapi shlwapi)
>-add_dependencies(testapi testapiLib)
>-target_link_libraries(testapiLib JavaScriptCore)
>-
>-add_library(testmasmLib SHARED ../assembler/testmasm.cpp)
>-add_executable(testmasm ${JSC_SOURCES})
>-set_target_properties(testmasm PROPERTIES OUTPUT_NAME "testmasm${DEBUG_SUFFIX}")
>-target_link_libraries(testmasm shlwapi)
>-add_dependencies(testmasm testmasmLib)
>-target_link_libraries(testmasmLib JavaScriptCore)
>+WEBKIT_WRAP_EXECUTABLE(jsc
>+    SOURCES DLLLauncherMain.cpp
>+    LIBRARIES shlwapi
>+)
>+target_compile_definitions(jsc PRIVATE ${wrapper_DEFINITIONS})
>+set(jsc_OUTPUT_NAME jsc${DEBUG_SUFFIX})
>+
>+if (DEVELOPER_MODE)
>+    WEBKIT_WRAP_EXECUTABLE(testapi
>+        SOURCES DLLLauncherMain.cpp
>+        LIBRARIES shlwapi
>+    )
>+    target_compile_definitions(testapi PRIVATE ${wrapper_DEFINITIONS})
>+    set(testapi_OUTPUT_NAME testapi${DEBUG_SUFFIX})
>+
>+    WEBKIT_WRAP_EXECUTABLE(testRegExp
>+        SOURCES DLLLauncherMain.cpp
>+        LIBRARIES shlwapi
>+    )
>+    target_compile_definitions(testRegExp PRIVATE ${wrapper_DEFINITIONS})
>+    set(testRegExp_OUTPUT_NAME testRegExp${DEBUG_SUFFIX})
>+
>+    WEBKIT_WRAP_EXECUTABLE(testmasm
>+        SOURCES DLLLauncherMain.cpp
>+        LIBRARIES shlwapi
>+    )
>+    target_compile_definitions(testmasm PRIVATE ${wrapper_DEFINITIONS})
>+    set(testmasm_OUTPUT_NAME testmasm${DEBUG_SUFFIX})
>+
>+    WEBKIT_WRAP_EXECUTABLE(testb3
>+        SOURCES DLLLauncherMain.cpp
>+        LIBRARIES shlwapi
>+    )
>+    target_compile_definitions(testb3 PRIVATE ${wrapper_DEFINITIONS})
>+    set(testb3_OUTPUT_NAME testb3${DEBUG_SUFFIX})
>+
>+    WEBKIT_WRAP_EXECUTABLE(testair
>+        SOURCES DLLLauncherMain.cpp
>+        LIBRARIES shlwapi
>+    )
>+    target_compile_definitions(testair PRIVATE ${wrapper_DEFINITIONS})
>+    set(testair_OUTPUT_NAME testair${DEBUG_SUFFIX})
>+
>+    WEBKIT_WRAP_EXECUTABLE(testdfg
>+        SOURCES DLLLauncherMain.cpp
>+        LIBRARIES shlwapi
>+    )
>+    target_compile_definitions(testdfg PRIVATE ${wrapper_DEFINITIONS})
>+    set(testdfg_OUTPUT_NAME testdfg${DEBUG_SUFFIX})
>+endif ()
>diff --git a/Source/cmake/WebKitMacros.cmake b/Source/cmake/WebKitMacros.cmake
>index a065b1cdc22..48ee725c23f 100644
>--- a/Source/cmake/WebKitMacros.cmake
>+++ b/Source/cmake/WebKitMacros.cmake
>@@ -142,16 +142,41 @@ macro(WEBKIT_FRAMEWORK_DECLARE _target)
>     add_library(${_target} ${${_target}_LIBRARY_TYPE} "${CMAKE_BINARY_DIR}/cmakeconfig.h")
> endmacro()
> 
>-macro(WEBKIT_FRAMEWORK _target)
>-    target_sources(${_target} PRIVATE
>-        ${${_target}_HEADERS}
>-        ${${_target}_SOURCES}
>+macro(WEBKIT_EXECUTABLE_DECLARE _target)
>+    add_executable(${_target} "${CMAKE_BINARY_DIR}/cmakeconfig.h")
>+endmacro()
>+
>+# Private macro for setting the properties of a target.
>+# Rather than just having _target like WEBKIT_FRAMEWORK and WEBKIT_EXECUTABLE the parameters are
>+# split into _target_logical_name, which is used for variable expansion, and _target_cmake_name.
>+# This is done to support WEBKIT_WRAP_EXECUTABLE which uses the _target_logical_name variables
>+# but requires a different _target_cmake_name.
>+macro(_WEBKIT_TARGET _target_logical_name _target_cmake_name)
>+    target_sources(${_target_cmake_name} PRIVATE
>+        ${${_target_logical_name}_HEADERS}
>+        ${${_target_logical_name}_SOURCES}
>     )
>-    target_include_directories(${_target} PUBLIC "$<BUILD_INTERFACE:${${_target}_INCLUDE_DIRECTORIES}>")
>-    target_include_directories(${_target} SYSTEM PRIVATE "$<BUILD_INTERFACE:${${_target}_SYSTEM_INCLUDE_DIRECTORIES}>")
>-    target_include_directories(${_target} PRIVATE "$<BUILD_INTERFACE:${${_target}_PRIVATE_INCLUDE_DIRECTORIES}>")
>-    target_link_libraries(${_target} ${${_target}_LIBRARIES})
>-    set_target_properties(${_target} PROPERTIES COMPILE_DEFINITIONS "BUILDING_${_target}")
>+    target_include_directories(${_target_cmake_name} PUBLIC "$<BUILD_INTERFACE:${${_target_logical_name}_INCLUDE_DIRECTORIES}>")
>+    target_include_directories(${_target_cmake_name} SYSTEM PRIVATE "$<BUILD_INTERFACE:${${_target_logical_name}_SYSTEM_INCLUDE_DIRECTORIES}>")
>+    target_include_directories(${_target_cmake_name} PRIVATE "$<BUILD_INTERFACE:${${_target_logical_name}_PRIVATE_INCLUDE_DIRECTORIES}>")
>+
>+    target_compile_definitions(${_target_cmake_name} PRIVATE "BUILDING_${_target_logical_name}")
>+    if (${_target_logical_name}_DEFINITIONS)
>+        target_compile_definitions(${_target_cmake_name} PUBLIC ${${_target_logical_name}_DEFINITIONS})
>+    endif ()
>+    if (${_target_logical_name}_PRIVATE_DEFINITIONS)
>+        target_compile_definitions(${_target_cmake_name} PRIVATE ${${_target_logical_name}_PRIVATE_DEFINITIONS})
>+    endif ()
>+
>+    target_link_libraries(${_target_cmake_name} ${${_target_logical_name}_LIBRARIES})
>+
>+    if (${_target}_DEPENDENCIES)
>+        add_dependencies(${_target_cmake_name} ${${_target}_DEPENDENCIES})
>+    endif ()
>+endmacro()
>+
>+macro(WEBKIT_FRAMEWORK _target)
>+    _WEBKIT_TARGET(${_target} ${_target})
> 
>     if (${_target}_OUTPUT_NAME)
>         set_target_properties(${_target} PROPERTIES OUTPUT_NAME ${${_target}_OUTPUT_NAME})
>@@ -172,6 +197,43 @@ macro(WEBKIT_FRAMEWORK _target)
>     endif ()
> endmacro()
> 
>+macro(WEBKIT_EXECUTABLE _target)
>+    _WEBKIT_TARGET(${_target} ${_target})
>+
>+    if (${_target}_OUTPUT_NAME)
>+        set_target_properties(${_target} PROPERTIES OUTPUT_NAME ${${_target}_OUTPUT_NAME})
>+    endif ()
>+endmacro()
>+
>+macro(WEBKIT_WRAP_EXECUTABLE _target)
>+    set(oneValueArgs TARGET_NAME)
>+    set(multiValueArgs SOURCES LIBRARIES)
>+    cmake_parse_arguments(opt "" "${oneValueArgs}" "${multiValueArgs}" ${ARGN})
>+
>+    if (opt_TARGET_NAME)
>+        set(_wrapped_target_name ${opt_TARGET_NAME})
>+    else ()
>+        set(_wrapped_target_name ${_target}Lib)
>+    endif ()
>+
>+    add_library(${_wrapped_target_name} SHARED "${CMAKE_BINARY_DIR}/cmakeconfig.h")
>+
>+    _WEBKIT_TARGET(${_target} ${_wrapped_target_name})
>+
>+    # Unset values
>+    unset(${_target}_HEADERS)
>+    unset(${_target}_DEFINITIONS)
>+    unset(${_target}_PRIVATE_DEFINITIONS)
>+    unset(${_target}_INCLUDE_DIRECTORIES)
>+    unset(${_target}_SYSTEM_INCLUDE_DIRECTORIES)
>+    unset(${_target}_PRIVATE_INCLUDE_DIRECTORIES)
>+
>+    # Reset the sources
>+    set(${_target}_SOURCES ${opt_SOURCES})
>+    set(${_target}_LIBRARIES ${opt_LIBRARIES})
>+    set(${_target}_DEPENDENCIES ${_wrapped_target_name})
>+endmacro()
>+
> macro(WEBKIT_CREATE_FORWARDING_HEADER _target_directory _file)
>     get_filename_component(_source_path "${CMAKE_SOURCE_DIR}/Source/" ABSOLUTE)
>     get_filename_component(_absolute "${_file}" ABSOLUTE)

Actions: View | Formatted Diff | Diff

Attachments on bug 197206: 368050 | 368052 | 368053 | 368054 | 368064 | 368155 | 368175 | 368332 | 368342 | 368347 | 368348 | 368360 | 368467 | 368470