Fix NullPointerException when generating Xcode project for top-level rule

Created by: ProfessaA

Background

Generating an Xcode project for a top-level rule results in a NullPointerException.

This can be reproduced with the fixture project at https://github.com/facebook/buck/tree/master/test/com/facebook/buck/features/apple/project/testdata/generating_root_directory_project though interestingly the integration test that uses this fixture project (ProjectIntegrationTest#generatingRootDirectoryProject) succeeds.

The exception is coming from this check: https://github.com/facebook/buck/blob/814f5483920695c07bc555978b2630ec7aad1ad7/src/com/facebook/buck/features/apple/project/WorkspaceAndProjectGenerator.java#L561 getFileName is null in real-world use (where Path is an instance of com.facebook.buck.cli.bootstrapper.filesystem.BuckUnixPath) but is an empty string under test (where Path is an instance of the default sun.nio.fs.UnixPath).

sun.nio.fs.UnixPath actually seems to have behavior that conflicts with the documentation of getFileName, which states:

a path representing the name of the file or directory, or null if this path has zero elements

We can see the difference in behavior with a simple test:

BuckFileSystemProvider provider = new BuckFileSystemProvider(FileSystems.getDefault().provider());
Path blankBuckPath = provider.getFileSystem(URI.create("file:///")).getPath("");
assertNull(blankBuckPath.getFileName());
assertEquals(blankBuckPath.getNameCount(), 0);

MacOSXFileSystemProvider macOSXFileSystemProvider = new MacOSXFileSystemProvider();
Path blankMacOSXPath = macOSXFileSystemProvider.getFileSystem(URI.create("file:///")).getPath("");
assertNotNull(blankMacOSXPath.getFileName());
assertEquals(blankMacOSXPath.getNameCount(), 1);

assertEquals(blankMacOSXPath.toString(), blankBuckPath.toString());

This means this bug was introduced with https://github.com/facebook/buck/commit/33266e587dc0f5bb9c65aca451ca521062c53f33, since from then on getFileName returned null, which is correct but breaks the previous check which relied on the incorrect behavior of sun.nio.fs.UnixPath.

Changes

Simply handle a null return from getFileName before trying to call toString on it.

Test Plan

Unfortunately, I'm not sure how to expose this bug under test.

If we run ProjectIntegrationTest#generatingRootDirectoryProject directly with -Djava.nio.file.spi.DefaultFileSystemProvider=com.facebook.buck.core.filesystems.BuckFileSystemProvider, we run into the exception (before this fix).

However, adding -Djava.nio.file.spi.DefaultFileSystemProvider=com.facebook.buck.core.filesystems.BuckFileSystemProvider as a vm_arg and //src/com/facebook/buck/core/filesystems:filesystems as a dep for test/com/facebook/buck/features/apple/project:project doesn't work because FileClassPathRunner uses Path before loading the buck.classpath_file. I'm not familiar enough with the test set up to know what the right way to use the BuckFileSystemProvider under test is.