@gibson042 Sometimes I wonder if this cache code is more than its worth. Have we ever done perf testing focused on how much we gain with dir caching? If we could do away with all of this, we'd resolve the issue and have cleaner code.

I think we have checked, but I can't find anything about it now. As I remember, though, it was highly valuable in precisely the cases one would expect: long-prefix selectors against deep DOM trees (since dir caching shortcuts everything to the left of a combinator when a node is visited multiple times by the same filter).

So to provide other side of the argument, that adds a lot of logic and code, whereas if we would just expose the expando and remove it in core code it would be simple without additional byte hit.

This way is more correct, but what we would solve here?

The size difference is negligible (+7 to Sizzle for exposing expando and an additional +7 to jQuery for using it vs. +12 to Sizzle for being inherently cloneNode-safe in oldIE), and :nth-last-child(…) caching is actually clarified by this change (which is essentially a single new lookup/assignment that appears in three places).

The cache data was always supposed to have single-element scope; this just guarantees that cloneNode doesn't violate that intention.

Okay then, i assume we don't need additional tests in core? If so, we can close jquery/jquery#1709 from the latest commit in here?

Correct.

So you would need to change commit message of the last commit?

I don't think so. What did you have in mind?

You know, little stuff, no big deals :-).

We have three commits here with identical commit headers, i would either distinguish them more clearly or unite those changes in one commit.

And not Ref jquery/jquery#1709 but Fixes jquery/jquery#1709, so we could close that ticket while closing this pull.

Also, https://github.com/jquery/sizzle/pull/328/files#r27660499. But that would be fixed either way with jscs at some point, oh and btw, how about we do jquery/jquery#2056 for the sizzle, before releasing the new version? Since code-styles now is changed so much?

We have three commits here with identical commit headers, i would either distinguish them more clearly or unite those changes in one commit.

I'll be collapsing them before a merge to master.

And not Ref jquery/jquery#1709 but Fixes jquery/jquery#1709, so we could close that ticket while closing this pull.

I can change it to "Fixes", but jquery/jquery#1709 won't auto-close—and rightly so, since it still exists until jQuery pulls in the change. @jquery/core: thoughts on "Ref" vs. "Fixes" here?

As for updating grunt-jscs before release, I think that's feasible.

I'd go with Ref, since as you say it won't be closed until the jQuery update. That update can have Closes in its commit message, right? It would be a good practice to do that anyway so we know what we're fixing.

I can change it to "Fixes", but jquery/jquery#1709 won't auto-close—and rightly so, since it still exists until jQuery pulls in the change. @jquery/core: thoughts on "Ref" vs. "Fixes" here?

It should - https://github.com/blog/1439-closing-issues-across-repositories

since it still exists until jQuery pulls in the change

Right, but the issue itself is fixed, just in another repo, we could do that when we will update Sizzle, but it has good probability of ignoring this issue or issues like this.

If we would follow this logic, we could close jquery tickets (or issues of any other project) only after we would release it.

Right, but the issue itself is fixed, just in another repo

The issue is fixed if it's fixed on master (or compat for jQuery Compat). Until Sizzle is updated there, it's therefore not fixed. This is important; otherwise we could release thinking we have no blockers and forget about updating Sizzle first. This has already happened; we have guards in jquery-release but it's better to know about such things before deciding to release.

I guess better way would be to make it a sizzle issue, not a core one