[ 
https://issues.apache.org/jira/browse/TINKERPOP-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17945135#comment-17945135
 ] 

ASF GitHub Bot commented on TINKERPOP-3155:
-------------------------------------------

codecov-commenter commented on PR #3095:
URL: https://github.com/apache/tinkerpop/pull/3095#issuecomment-2810172194

   ## 
[Codecov](https://app.codecov.io/gh/apache/tinkerpop/pull/3095?dropdown=coverage&src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache)
 Report
   All modified and coverable lines are covered by tests :white_check_mark:
   > Project coverage is 74.22%. Comparing base 
[(`9b46b67`)](https://app.codecov.io/gh/apache/tinkerpop/commit/9b46b6777d2fa250e41daacf2fa4554605aff53a?dropdown=coverage&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache)
 to head 
[(`008cf0f`)](https://app.codecov.io/gh/apache/tinkerpop/commit/008cf0feaec3fb8376c1fcaea2f9b3337b9d703f?dropdown=coverage&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache).
   > Report is 329 commits behind head on 3.7-dev.
   
   <details><summary>Additional details and impacted files</summary>
   
   
   ```diff
   @@              Coverage Diff              @@
   ##             3.7-dev    #3095      +/-   ##
   =============================================
   - Coverage      76.14%   74.22%   -1.92%     
   =============================================
     Files           1084       28    -1056     
     Lines          65160     5913   -59247     
     Branches        7285        0    -7285     
   =============================================
   - Hits           49616     4389   -45227     
   + Misses         12839     1322   -11517     
   + Partials        2705      202    -2503     
   ```
   
   </details>
   
   [:umbrella: View full report in Codecov by 
Sentry](https://app.codecov.io/gh/apache/tinkerpop/pull/3095?dropdown=coverage&src=pr&el=continue&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache).
   
   :loudspeaker: Have feedback on the report? [Share it 
here](https://about.codecov.io/codecov-pr-comment-feedback/?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache).
   
   <details><summary> :rocket: New features to boost your workflow: </summary>
   
   - :snowflake: [Test 
Analytics](https://docs.codecov.com/docs/test-analytics): Detect flaky tests, 
report on failures, and find test suite problems.
   - :package: [JS Bundle 
Analysis](https://docs.codecov.com/docs/javascript-bundle-analysis): Save 
yourself from yourself by tracking and limiting bundle sizes in JS merges.
   </details>




> Operator.addAll checks for instanceof on the wrong parameter
> ------------------------------------------------------------
>
>                 Key: TINKERPOP-3155
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-3155
>             Project: TinkerPop
>          Issue Type: Bug
>            Reporter: Martin Häusler
>            Priority: Major
>
> Hi,
> I was experimenting with "sack(...)" today and noticed a weirdness in the 
> gremlin source code for Operator. Here's the "addAll" literal, as defined in 
> the gremlin source code:
> {code:java}
> addAll {
>     public Object apply(final Object a, final Object b) {
>         if (null == a || null == b) {
>             if (null == a && null == b)
>                 return null;
>             else
>                 return null == b ? a : b;
>         }
>         if (a instanceof Map && b instanceof Map)
>             ((Map<?,?>) a).putAll((Map) b);
>         else if (a instanceof Collection && a instanceof Collection)
>             ((Collection<?>) a).addAll((Collection) b);
>         else
>             throw new IllegalArgumentException(String.format("Objects must be 
> both of Map or Collection: a=%s b=%s",
>                     a.getClass().getSimpleName(), 
> b.getClass().getSimpleName()));
>         return a;
>     }
> }, {code}
>  
> Note the line 
> {code:java}
> else if (a instanceof Collection && a instanceof Collection) {code}
>  
> That's weird. We're checking twice if "a" is a Collection. Not only is that 
> pointless, but it also ignores parameter b. Shouldn't the second part of the 
> condition be:
>  
> {code:java}
> b instanceof Collection{code}
>  
> ... since we're downcasting b into a Collection afterwards?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to