Hello! I am a bot.

Thank you for your pull request!

I have assigned @vtjnash to this pull request.

@vtjnash can either choose to review this pull request themselves, or they can choose to find someone else to review this pull request.

Note: If you are a Julia committer, please make sure that your organization membership is public.

Apologies if I'm wrong, but this PR seems to be for AI generated code changes that hasn't been fully reviewed before being submitted. It's a bit of a waste of reviewer time.

I rewrote the code and changed the code to suit the changes I was making so that the code felt written in one way. I removed some comments as I thought they weren't needed, but I was wrong and made the changes as asked by the maintainers.

@IanButterworth If there are any more suggestions, I am open to work on them and help this pr become better. My biggest issue right now as a contributor is that I sometimes rush through things and miss the big picture, which leads to mistakes but I am working on it.

I generally view pull requests as a dialog - the person who opens it effectively says "hey, I have these changes I think would be beneficial, are they ok?" and the reviewer(s) try to give feedback or ask questions when something is a bit unclear. So far, we've suggested concrete changes (which have been incorporated, that's good) and asked some clarifying questions (which were not answered, and the commented code instead changed without reply). When a reviewer is asking a question about the changes, they're trying to understand what the reasons behind that specific change are. This does not always have the goal of changing the code, but primarily serves to further understanding on the reviewers' side. This also has the benefit of documenting these decisions for future readers of the code, who may need this context to understand the code in the future.

Not giving those answers gives the impression that working on a PR is more about getting the PR itself merged than communicating with reviewers about what a mergeable version of a PR would look like. So personally, I'm not opposed to fixing #58640 in this PR, but I do think this dialog has been pretty one-sided so far :)

@Seelengrab thank you for the perspective. I apologise for not communicating better before (I have now given mythought to all of the reviews submitted on this pr) but I assure you that I will keep this in mind in my work in this pr and future prs, not just on Julia, but on any organisation I work with.

this still contains several needless changes that appear AI-generated (but lacking necessary human review)

for example, lines are rearranged here for no apparent reason moving newlen = len + delta below memlen = length(mem) which makes the diff appear larger than it needs to be. same goes for moving

    newmemlen = max(overallocation(len), len + 2 * delta + 1)
    newoffset = div(newmemlen - newlen, 2) + 1

below the block comment.

I also noticed a change from if newoffset + newlen < memlen to if newoffset + newlen <= memlen (note that the equality is now weak). I don't know this code well enough to say which is correct, but this is definitely the kind of thing that needs to be intentional & reasoned about in the PR description.