Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More careful PROTECT()/UNPROTECT() in rbindlist for rchk #6311

Merged
merged 6 commits into from
Aug 5, 2024

Conversation

MichaelChirico
Copy link
Member

@MichaelChirico MichaelChirico commented Jul 26, 2024

I'm actually still not convinced this is actually meaningful, but the flood of rchk warnings (#6263) does diminish (though not totally gone) with this change.

I'm not a fan of the redundancy, but I didn't see a way around it:

  • We can't move the if (ret) branch outside the if (listprotect) branch because ret will have the wrong scope. 1
  • We also can't pre-declare ret like const char *ret; ret=... because that's non-const behavior.
  • simple if (listprotect) PROTECT(...); ...; if (listprotect) UNPROTECT(); doesn't satisfy rchk 2, i.e. the problem is not just to do with how the if condition is constructed & listprotect is written

Open to other suggestions...

Copy link

github-actions bot commented Jul 26, 2024

Comparison Plot

Generated via commit 695be8b

Download link for the artifact containing the test results: ↓ atime-results.zip

Time taken to finish the standard R installation steps: 11 minutes and 46 seconds

Time taken to run atime::atime_pkg on the tests: 6 minutes and 11 seconds

@MichaelChirico MichaelChirico added this to the 1.16.0 milestone Jul 27, 2024
@MichaelChirico
Copy link
Member Author

PTAL @ben-schwen -- we can move to turn on the rchk GHA after this

src/rbindlist.c Outdated Show resolved Hide resolved
src/rbindlist.c Outdated Show resolved Hide resolved
Copy link
Member

@ben-schwen ben-schwen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIU #6263 our pattern with listprotect, PROTECT and UNPROTECT inside the if cannot be checked with rchk.

However, we need this pattern because of the protection stack size(see #5448).

WDYT should we try to use a PROTECT_WITH_INDEX instead?

@MichaelChirico
Copy link
Member Author

MichaelChirico commented Aug 5, 2024

WDYT should we try to use a PROTECT_WITH_INDEX instead?

It sounds good in principle, but I'm not seeing a straightforward way to do so in practice -- thisCol is first assigned "lazily" in the RHS of ||, so we'd have to break up that statement to add further nesting to accomplish the PROTECT_WITH_INDEX approach IINM. Anyway thisCol only needs to be PROTECT()'d in the rare case of this weird behavior for list input that needs coercion -- usually it's just column l[[i]][[w]] from the input, so, already under protection.

I'd rather defer this to a follow-up where we try and simplify the code a bit more while we're at it: #6353

@ben-schwen
Copy link
Member

Seems ok for me but in the end we can cut this PR down to?

bool listprotect = (TYPEOF(target)==VECSXP || TYPEOF(target)==EXPRSXP) && TYPEOF(thisCol)!=TYPEOF(target);
// do an as.list() on the atomic column; #3528
if (listprotect) {
  thisCol = PROTECT(coerceVector(thisCol, TYPEOF(target)));

@MichaelChirico
Copy link
Member Author

No, rchk spews a lot more unless we do the repetitive thing done now :\

@ben-schwen
Copy link
Member

Well, then we are good to go!

@MichaelChirico MichaelChirico merged commit 377c202 into master Aug 5, 2024
4 of 5 checks passed
@MichaelChirico MichaelChirico deleted the rchk-rbindlist branch August 5, 2024 20:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants