Refactor all ctor callsites of PathFragment to instead call a static 'create' method.
This paves the way for changing PathFragment to e.g. an abstract class with multiple subclasses. This way we can split out the windows-specific stuff into one of these concrete classes, making the code more readable and also saving memory (since the shallow heap size of the NonWindowsPathFragment subclass will hopefully be smaller than that of the current PathFragment).
This also lets us pursue gc churn optimizations. We can now do interning in PathFragment#create and can also get rid of unnecessary intermediate PathFragment allocations.
RELNOTES: None
PiperOrigin-RevId: 152145768
diff --git a/src/test/java/com/google/devtools/build/lib/packages/RelativePackageNameResolverTest.java b/src/test/java/com/google/devtools/build/lib/packages/RelativePackageNameResolverTest.java
index 9f2f9b6..fee2a7c 100644
--- a/src/test/java/com/google/devtools/build/lib/packages/RelativePackageNameResolverTest.java
+++ b/src/test/java/com/google/devtools/build/lib/packages/RelativePackageNameResolverTest.java
@@ -112,7 +112,7 @@
}
private void createResolver(String offset, boolean discardBuild) {
- resolver = new RelativePackageNameResolver(new PathFragment(offset), discardBuild);
+ resolver = new RelativePackageNameResolver(PathFragment.create(offset), discardBuild);
}
private void assertResolvesTo(String relative, String expectedAbsolute) throws Exception {
