Buildfix for OpenGL ES2 build #1
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@hugopl , we summon you. :) |
|
Same with GLDefs change. Why do we need to include OpenGLShims for Gles?? |
|
It was necessary because GL_READ_FRAMEBUFFER and GL_READ_FRAMEBUFFER are missing from gl2ext.h and I don't know how to fix it properly. (it is needed at platform/graphics/opengl/GLPlatformSurface.cpp) |
|
k, there is no support for EXT_framebuffer_blit on GLES2, which defines all the needed attachment points for blitting. Even though we might get it complied, it would cause run time issues. I have some changes pending which should solve this for GraphicsSurface implementations. Would put it for review today eve or so. |
1 similar comment
|
k, there is no support for EXT_framebuffer_blit on GLES2, which defines all the needed attachment points for blitting. Even though we might get it complied, it would cause run time issues. I have some changes pending which should solve this for GraphicsSurface implementations. Would put it for review today eve or so. |
|
So I think is better to wait for kalyan patches, btw those add_definitions aren't needed, they should already exist in the generated cmakeconfig.h file. |
|
Thanks Hugo, I see now how it works. I thought that these defines coming from the .cmake files. Anyway I agree with waiting for Kalyan patches and then just the Tools/WebKitTestRunner/nix/PlatformWebViewNix.cpp left to fix. |
rafaelbrandao
pushed a commit
that referenced
this pull request
Feb 22, 2013
https://bugs.webkit.org/show_bug.cgi?id=110473 Reviewed by Pavel Feldman. In a single canvas frame capture mode do not show the single "Frame #1" node. Drive-by: Fix a wrong "this" pointer. * inspector/front-end/CanvasProfileView.js: (WebInspector.CanvasProfileView.prototype._didReceiveTraceLog): (WebInspector.CanvasProfileView.prototype.appendDrawCallGroup): (WebInspector.CanvasProfileView.prototype._flattenSingleFrameNode): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@143731 268f45cc-cd09-0410-ab3c-d52691b4dbfc
dakerfp
pushed a commit
that referenced
this pull request
Mar 1, 2013
* platform/chromium/TestExpectations: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@144291 268f45cc-cd09-0410-ab3c-d52691b4dbfc
|
Do we need to keep this open? |
|
I think we can close this. I will check later the status of the Opengl ES2 build. |
lauromoura
pushed a commit
that referenced
this pull request
Apr 23, 2013
Rebaseline #1 after enabling the subpixel layout, covering the animations, css1, fonts, fullscreen, transforms and transitions directories. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148795 268f45cc-cd09-0410-ab3c-d52691b4dbfc
This was referenced Jul 15, 2013
dakerfp
pushed a commit
that referenced
this pull request
Jul 26, 2013
… read and what they write https://bugs.webkit.org/show_bug.cgi?id=118910 Source/JavaScriptCore: Reviewed by Sam Weinig. Add the notion of AbstractHeap to the DFG. This is analogous to the AbstractHeap in the FTL, except that the FTL's AbstractHeaps are used during LLVM lowering and are engineered to obey LLVM TBAA logic. The FTL's AbstractHeaps are also engineered to be inexpensive to use (they just give you a TBAA node) but expensive to create (you create them all up front). FTL AbstractHeaps also don't actually give you the ability to reason about aliasing; they are *just* a mechanism for lowering to TBAA. The DFG's AbstractHeaps are engineered to be both cheap to create and cheap to use. They also give you aliasing machinery. The DFG AbstractHeaps are represented internally by a int64_t. Many comparisons between them are just integer comaprisons. AbstractHeaps form a three-level hierarchy (World is the supertype of everything, Kind with a TOP payload is a direct subtype of World, and Kind with a non-TOP payload is the direct subtype of its corresponding TOP Kind). Add the notion of a ClobberSet. This is the set of AbstractHeaps that you had clobbered. It represents the set that results from unifying a bunch of AbstractHeaps, and is intended to quickly answer overlap questions: does the given AbstractHeap overlap any AbstractHeap in the ClobberSet? To this end, if you add an AbstractHeap to a set, it "directly" adds the heap itself, and "super" adds all of its ancestors. An AbstractHeap is said to overlap a set if any direct or super member is equal to it, or if any of its ancestors are equal to a direct member. Example #1: - I add Variables(5). I.e. Variables is the Kind and 5 is the payload. This is a subtype of Variables, which is a subtype of World. - You query Variables. I.e. Variables with a TOP payload, which is the supertype of Variables(X) for any X, and a subtype of World. The set will have Variables(5) as a direct member, and Variables and World as super members. The Variables query will immediately return true, because Variables is indeed a super member. Example #2: - I add Variables(5) - You query NamedProperties NamedProperties is not a member at all (neither direct or super). We next query World. World is a member, but it's a super member, so we return false. Example #3: - I add Variables - You query Variables(5) The set will have Variables as a direct member, and World as a super member. The Variables(5) query will not find Variables(5) in the set, but then it will query Variables. Variables is a direct member, so we return true. Example #4: - I add Variables - You query NamedProperties(5) Neither NamedProperties nor NamedProperties(5) are members. We next query World. World is a member, but it's a super member, so we return false. Overlap queries require that either the heap being queried is in the set (either direct or super), or that one of its ancestors is a direct member. Another way to think about how this works is that two heaps A and B are said to overlap if A.isSubtypeOf(B) or B.isSubtypeOf(A). This is sound since heaps form a single-inheritance heirarchy. Consider that we wanted to implement a set that holds heaps and answers the question, "is any member in the set an ancestor (i.e. supertype) of some other heap". We would have the set contain the heaps themselves, and we would satisfy the query "A.isSubtypeOfAny(set)" by walking the ancestor chain of A, and repeatedly querying its membership in the set. This is what the "direct" members of our set do. Now consider the other part, where we want to ask if any member of the set is a descendent of a heap, or "A.isSupertypeOfAny(set)". We would implement this by implementing set.add(B) as adding not just B but also all of B's ancestors; then we would answer A.isSupertypeOfAny(set) by just checking if A is in the set. With two such sets - one that answers isSubtypeOfAny() and another that answers isSupertypeOfAny() - we could answer the "do any of my heaps overlap your heap" question. ClobberSet does this, but combines the two sets into a single HashMap. The HashMap's value, "direct", means that the key is a member of both the supertype set and the subtype set; if it's false then it's only a member of one of them. Finally, this adds a functorized clobberize() method that adds the read and write clobbers of a DFG::Node to read and write functors. Common functors for adding to ClobberSets, querying overlap, and doing nothing are provided. Convenient wrappers are also provided. This allows you to say things like: ClobberSet set; addWrites(graph, node1, set); if (readsOverlap(graph, node2, set)) // We know that node1 may write to something that node2 may read from. Currently this facility is only used to improve graph dumping, but it will be instrumental in both LICM and GVN. In the future, I want to completely kill the NodeClobbersWorld and NodeMightClobber flags, and eradicate CSEPhase's hackish way of accomplishing almost exactly what AbstractHeap gives you. * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGAbstractHeap.cpp: Added. (DFG): (JSC::DFG::AbstractHeap::Payload::dump): (JSC::DFG::AbstractHeap::dump): (WTF): (WTF::printInternal): * dfg/DFGAbstractHeap.h: Added. (DFG): (AbstractHeap): (Payload): (JSC::DFG::AbstractHeap::Payload::Payload): (JSC::DFG::AbstractHeap::Payload::top): (JSC::DFG::AbstractHeap::Payload::isTop): (JSC::DFG::AbstractHeap::Payload::value): (JSC::DFG::AbstractHeap::Payload::valueImpl): (JSC::DFG::AbstractHeap::Payload::operator==): (JSC::DFG::AbstractHeap::Payload::operator!=): (JSC::DFG::AbstractHeap::Payload::operator<): (JSC::DFG::AbstractHeap::Payload::isDisjoint): (JSC::DFG::AbstractHeap::Payload::overlaps): (JSC::DFG::AbstractHeap::AbstractHeap): (JSC::DFG::AbstractHeap::operator!): (JSC::DFG::AbstractHeap::kind): (JSC::DFG::AbstractHeap::payload): (JSC::DFG::AbstractHeap::isDisjoint): (JSC::DFG::AbstractHeap::overlaps): (JSC::DFG::AbstractHeap::supertype): (JSC::DFG::AbstractHeap::hash): (JSC::DFG::AbstractHeap::operator==): (JSC::DFG::AbstractHeap::operator!=): (JSC::DFG::AbstractHeap::operator<): (JSC::DFG::AbstractHeap::isHashTableDeletedValue): (JSC::DFG::AbstractHeap::payloadImpl): (JSC::DFG::AbstractHeap::encode): (JSC::DFG::AbstractHeapHash::hash): (JSC::DFG::AbstractHeapHash::equal): (AbstractHeapHash): (WTF): * dfg/DFGClobberSet.cpp: Added. (DFG): (JSC::DFG::ClobberSet::ClobberSet): (JSC::DFG::ClobberSet::~ClobberSet): (JSC::DFG::ClobberSet::add): (JSC::DFG::ClobberSet::addAll): (JSC::DFG::ClobberSet::contains): (JSC::DFG::ClobberSet::overlaps): (JSC::DFG::ClobberSet::clear): (JSC::DFG::ClobberSet::direct): (JSC::DFG::ClobberSet::super): (JSC::DFG::ClobberSet::dump): (JSC::DFG::ClobberSet::setOf): (JSC::DFG::addReads): (JSC::DFG::addWrites): (JSC::DFG::addReadsAndWrites): (JSC::DFG::readsOverlap): (JSC::DFG::writesOverlap): * dfg/DFGClobberSet.h: Added. (DFG): (ClobberSet): (JSC::DFG::ClobberSet::isEmpty): (ClobberSetAdd): (JSC::DFG::ClobberSetAdd::ClobberSetAdd): (JSC::DFG::ClobberSetAdd::operator()): (ClobberSetOverlaps): (JSC::DFG::ClobberSetOverlaps::ClobberSetOverlaps): (JSC::DFG::ClobberSetOverlaps::operator()): (JSC::DFG::ClobberSetOverlaps::result): * dfg/DFGClobberize.cpp: Added. (DFG): (JSC::DFG::didWrites): * dfg/DFGClobberize.h: Added. (DFG): (JSC::DFG::clobberize): (NoOpClobberize): (JSC::DFG::NoOpClobberize::NoOpClobberize): (JSC::DFG::NoOpClobberize::operator()): (CheckClobberize): (JSC::DFG::CheckClobberize::CheckClobberize): (JSC::DFG::CheckClobberize::operator()): (JSC::DFG::CheckClobberize::result): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): Source/WTF: Reviewed by Sam Weinig. Fix compile goof in sortedListDump(). * wtf/ListDump.h: (WTF::sortedListDump): Conflicts: Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153294 268f45cc-cd09-0410-ab3c-d52691b4dbfc
tulliolucena
pushed a commit
that referenced
this pull request
Sep 6, 2013
…t breakage. * Scripts/run-javascriptcore-tests: (readAllLines): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155101 268f45cc-cd09-0410-ab3c-d52691b4dbfc
hugopl
pushed a commit
that referenced
this pull request
Sep 12, 2013
…caping to bytecode, as opposed to just escaping within DFG code.
Rubber stamped by Mark Hahnenberg.
We need to care about escaping to bytecode if we're doing a lossy optimization,
i.e. the optimization means we produce less information and so we can't rescue
ourselves during OSR exit.
We only need to care about escaping within the DFG code (and can ignore what
might happen in bytecode) if we're doing an optimization that is lossless, i.e.
we can always still reconstruct the values that bytecode wants.
Example #1:
Large int32 + int32 which overflows. We want to optimize away the overflow
check and just do a 32-bit add.
This is lossy; the result should have one extra bit but we simply throw
that bit away by doing a check-less 32-bit add. Hence we need to know that
even the bytecode wouldn't have cared about that bit. This is true in cases
like (a + b) | 0.
Example #2:
Larbe int32 + int32 which overflows. We want to optimize away the overflow
check by doing a 64-bit add.
This is lossless. We can always convert the resulting 64-bit int back to a
double if that's what bytecode wants. Hence we only need to know that the
DFG code won't want to do something to this value that would make 64-bit
ints either unprofitable or unsound.
The backwards propagator's notions of flags (NodeUsedAsValue, etc) are for lossy
optimizations and so should be named in a way that reflects this. This patch
calls then NodeBytecodeUsesAsValue, etc.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::::executeEffects):
* dfg/DFGArrayMode.cpp:
(JSC::DFG::ArrayMode::refine):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::mergeDefaultFlags):
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
* dfg/DFGNode.h:
(JSC::DFG::Node::arithNodeFlags):
* dfg/DFGNodeFlags.cpp:
(JSC::DFG::dumpNodeFlags):
* dfg/DFGNodeFlags.h:
(JSC::DFG::bytecodeUsesAsNumber):
(JSC::DFG::bytecodeCanTruncateInteger):
(JSC::DFG::bytecodeCanIgnoreNegativeZero):
(JSC::DFG::nodeMayNegZero):
(JSC::DFG::nodeCanSpeculateInt32):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileDoubleAsInt32):
(JSC::DFG::SpeculativeJIT::compileAdd):
(JSC::DFG::SpeculativeJIT::compileArithSub):
(JSC::DFG::SpeculativeJIT::compileArithNegate):
(JSC::DFG::SpeculativeJIT::compileArithMul):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGVariableAccessData.h:
(JSC::DFG::VariableAccessData::shouldUseDoubleFormatAccordingToVote):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileAdd):
(JSC::FTL::LowerDFGToLLVM::compileArithSub):
(JSC::FTL::LowerDFGToLLVM::compileArithMul):
(JSC::FTL::LowerDFGToLLVM::compileArithDiv):
(JSC::FTL::LowerDFGToLLVM::compileArithMod):
(JSC::FTL::LowerDFGToLLVM::compileArithNegate):
git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155497 268f45cc-cd09-0410-ab3c-d52691b4dbfc
hugopl
pushed a commit
that referenced
this pull request
Sep 16, 2013
…th DFG and FTL https://bugs.webkit.org/show_bug.cgi?id=121371 Reviewed by Sam Weinig. Forward rewiring is a tricky part of OSR that handles the following: a: Something(...) SetLocal(@A, locX) b: Int32ToDouble(@A) c: SomethingThatExits(@b) <no further uses of @A or @b> Note that at @c, OSR will think that locX->@A, but @A will be dead. So it must be smart enough to find @b, which contains an equivalent value. It must do this for any identity functions we support. Currently we support four such functions. Currently the code for doing this is basically duplicated between the DFG and the FTL. Also both versions of the code have some really weirdly written logic for picking the "best" identity function to use. We should fix this by simply having a way to ask "is this node an identity function, and if so, then how good is it?" Then both the DFG and FTL could use this and have no hard-wired knowledge of those identity functions. While we're at it, this also changes some terminology because I found the use of the word "needs" confusing. Note that this retains the somewhat confusing behavior that we don't search all possible forward/backward uses. We only search one step in each direction. This is because we only need to handle cases that FixupPhase and the parser insert. All other code that tries to insert intermediate conversion nodes should ensure to Phantom the original node. For example, the following transformation is illegal: Before: x: SomethingThatExits(@A) After: w: Conversion(@A) x: SomethingThatExits(@w) The correct form of that transformation is one of these: Correct #1: v: DoAllChecks(@A) // exit here w: Conversion(@A) x: Something(@w) // no exit Correct #2: w: Conversion(@A) x: SomethingThatExits(@w) y: Phantom(@A) Correct #3: w: Conversion(@A) x: SomethingThatExits(@w, @A) Note that we use #3 for some heap accesses, but of course it requires that the node you're using has an extra slot for a "dummy" use child. Broadly speaking though, such transformations should be relegated to something below DFG IR, like LLVM IR. * dfg/DFGNodeType.h: (JSC::DFG::forwardRewiringSelectionScore): (JSC::DFG::needsOSRForwardRewiring): * dfg/DFGVariableEventStream.cpp: (JSC::DFG::VariableEventStream::reconstruct): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155793 268f45cc-cd09-0410-ab3c-d52691b4dbfc
lauromoura
pushed a commit
that referenced
this pull request
Oct 12, 2013
…hread (causing scroll bars not to appear/update quickly in some cases) https://bugs.webkit.org/show_bug.cgi?id=122585 -and corresponding- <rdar://problem/10710775> Reviewed by Simon Fraser. Source/WebCore: This patch does a few things in order to allow scrollbars to be updated on the scrolling thread: 1. This patch adds the ability to know if the lower-level APIs necessary to get this to work right are available, AND if the content is actually capable of taking advantage of this feature. This is currently implemented as Scrollbar::supportsUpdateOnSecondaryThread() which makes use of a new ScrollableArea function called updatesScrollLayerPositionOnMainThread() 2. To update on the scrolling thread, the scrolling tree needs to know about the ScrollbarPainters. 3. Once it knows about them, it should update the presentation value whenever the layer position changes. 4. Presentation value is basically the same thing as double value. There is a bit of code we maintain currently to compute that. This patch moves that code to a static function on ScrollableArea that can be called from both the main thread and the scrolling thread. 5. ScrollbarPainter API needs to know about the layers we have created for the vertical and horizontal scrollbars, then they will use those layers and the presentation value that we set on the scrolling thread to move the layers around. This is part of #1 above. * page/FrameView.cpp: (WebCore::FrameView::updatesScrollLayerPositionOnMainThread): * page/FrameView.h: This is part of #2. ScrollingStateScrollingNodes now have vertical and horizontal ScrollbarPainters for Mac only. * page/scrolling/ScrollingStateScrollingNode.cpp: (WebCore::ScrollingStateScrollingNode::ScrollingStateScrollingNode): * page/scrolling/ScrollingStateScrollingNode.h: (WebCore::ScrollingStateScrollingNode::verticalScrollbarPainter): (WebCore::ScrollingStateScrollingNode::horizontalScrollbarPainter): Also part of #2. Make sure to set the ScrollbarPainters for scrolling nodes when appropriate. * page/scrolling/mac/ScrollingCoordinatorMac.h: * page/scrolling/mac/ScrollingCoordinatorMac.mm: (WebCore::ScrollingCoordinatorMac::frameViewLayoutUpdated): Implement this function that was just stubbed out before. This is part of #5 in that is will allow the ScrollbarPainter API to know about any layer changes. (WebCore::ScrollingCoordinatorMac::scrollableAreaScrollbarLayerDidChange): Back to #2, making sure we properly set the ScrollbarPainters to send over to the scrolling thread. (WebCore::ScrollingCoordinatorMac::setScrollbarPaintersForNode): * page/scrolling/mac/ScrollingStateScrollingNodeMac.mm: (WebCore::ScrollingStateScrollingNode::setScrollbarPainters): This code achieves #3. It uses new ScrollbarPainter API to adjust the position of the scrollbars from the scrolling thread. * page/scrolling/mac/ScrollingTreeScrollingNodeMac.h: * page/scrolling/mac/ScrollingTreeScrollingNodeMac.mm: (WebCore::ScrollingTreeScrollingNodeMac::ScrollingTreeScrollingNodeMac): (WebCore::ScrollingTreeScrollingNodeMac::updateBeforeChildren): (WebCore::ScrollingTreeScrollingNodeMac::setScrollLayerPosition): This is for #5. ScrollbarPainter needs to know about our scrollbar layers. * platform/ScrollAnimator.h: (WebCore::ScrollAnimator::verticalScrollbarLayerDidChange): (WebCore::ScrollAnimator::horizontalScrollbarLayerDidChange): * platform/ScrollableArea.cpp: (WebCore::ScrollableArea::verticalScrollbarLayerDidChange): (WebCore::ScrollableArea::horizontalScrollbarLayerDidChange): This is for #4. This code computes the scrollbar’s value and current overhang amount. (WebCore::ScrollableArea::computeScrollbarValueAndOverhang): * platform/ScrollableArea.h: (WebCore::ScrollableArea::layerForHorizontalScrollbar): (WebCore::ScrollableArea::layerForVerticalScrollbar): (WebCore::ScrollableArea::layerForScrolling): This is for #1. We need to know if we have the ability to update scrollbars on a different thread. We can do that only on certain versions of the OS, only when threaded scrolling is enabled, and only when the current page is actually using the scrolling thread to scroll. * platform/Scrollbar.cpp: (WebCore::Scrollbar::supportsUpdateOnSecondaryThread): * platform/Scrollbar.h: * platform/ScrollbarThemeClient.h: New ScrollbarPainter APIs. * platform/mac/NSScrollerImpDetails.h: This is for #5, letting the ScrollbarPainter API know about the layers. * platform/mac/ScrollAnimatorMac.h: * platform/mac/ScrollAnimatorMac.mm: (-[WebScrollbarPainterDelegate layer]): (-[WebScrollbarPainterDelegate convertRectToLayer:]): (-[WebScrollbarPainterDelegate shouldUseLayerPerPartForScrollerImp:]): Before we kick off a scroll animation, set the current painting characteristics so they are up-to-date in case we are scrolling on the scrolling thread. (-[WebScrollbarPainterDelegate setUpAlphaAnimation:scrollerPainter:part:WebCore::animateAlphaTo:duration:]): (-[WebScrollbarPainterDelegate scrollerImp:animateKnobAlphaTo:duration:]): (-[WebScrollbarPainterDelegate scrollerImp:animateTrackAlphaTo:duration:]): (WebCore::ScrollAnimatorMac::didAddVerticalScrollbar): (WebCore::ScrollAnimatorMac::didAddHorizontalScrollbar): (WebCore::ScrollAnimatorMac::verticalScrollbarLayerDidChange): (WebCore::ScrollAnimatorMac::horizontalScrollbarLayerDidChange): Only paint the scrollbars through ScrollbarThemeMac if they are NOT being updated by the scrolling thread. * platform/mac/ScrollbarThemeMac.h: * platform/mac/ScrollbarThemeMac.mm: (WebCore::ScrollbarThemeMac::setCurrentPaintCharacteristics): (WebCore::scrollbarPainterPaint): (WebCore::ScrollbarThemeMac::paint): Back to #1. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::updatesScrollLayerPositionOnMainThread): * rendering/RenderLayer.h: * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::updateOverflowControlsLayers): * rendering/RenderListBox.h: Source/WebKit2: New pure virtual function. * WebProcess/Plugins/PDF/PDFPlugin.h: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157253 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm not sure that these changes are correct so I need somebody to review.