ggplot2 3.5.0 broke axis lines in coord_trans_xy()

[willgearty]

Recent changes in ggplot2 (presumably part of v. 3.5.0) have caused the axis lines (primary and secondary) of coord_trans_xy() to be rendered in the wrong positions:

library(ggforce)
#> Loading required package: ggplot2
library(ggplot2)
library(deeptime)
trans <- linear_trans(shear(2, 0), rotate(-pi / 3))
square <- data.frame(x = c(-2, -2, 2, 2), y = c(-2, 2, 2, -2))
points <- data.frame(
    x = rep(seq(-2, 2, 0.25), each = 17),
    y = rep(seq(-2, 2, 0.25), 17),
    color = rep(seq(1, 17, 1), each = 17)
)
ggplot(data = points, aes(x = x, y = y, color = color)) +
    geom_polygon(data = square, fill = NA, color = "black") +
    geom_point() +
    scale_x_continuous(sec.axis = sec_axis(~.)) +
    coord_trans_xy(trans = trans, expand = FALSE) +
    theme_classic()

^{Created on 2024-03-01 with reprex v2.1.0}

The ticks and labels all are correct, so this appears to be related to the drawing of the axis lines themselves. I've been going through as much of the ggplot2 internals as I can, and I haven't really been able to figure out where in the code it is determined where to plot the axis lines. Maybe @teunbrand has some insight about what I need to tweak to make sure the axis lines render properly given the recent changes to the internals?

[teunbrand]

So the axes rely on the coord to transform c(-Inf, Inf) to the appropriate range (normally 0-1, barring some exceptions). Typically, coords do this by squishing (scales::oob_squish_infinite). I'm not recognising any squishing happening in CoordTransXY$transform. If it is not the squish, I'd take a look at the special cases where all x or y variables are non-finite.

[willgearty]

OK, I was able to fix some use cases of coord_trans_xy() in 859ad85, but many edges still seem to exist. I'll need to keep looking into it.

[willgearty]

In my testing, I found that the axis lines never have non-finite values @teunbrand. When the coordinates for the axis lines are passed to CoordTransXY$transform they always have finite x and y values. In fact, I found it quite odd that those fixed values seemed to correspond to the opposite axis (e.g., the coordinates for the bottom axis would all have the y-value of where the top axis should be).

[teunbrand]

I found it quite odd that those fixed values seemed to correspond to the opposite axis

If you have a left axis, the line needs to be at the right side of the bounding box of the axis, that is why it is opposite.