aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/vfs/PathFragment.java
Commit message (Collapse)AuthorAge
* Hand-roll PathFragment$Codec, to squeeze a bit of performance out of it.Gravatar janakr2018-05-25
| | | | PiperOrigin-RevId: 198124705
* Normalize parameter name commentsGravatar cushon2018-04-27
| | | | PiperOrigin-RevId: 194512971
* Make some objects frequently encountered during serialization into ↵Gravatar janakr2018-04-10
| | | | | | | | constants. A lot of care is needed here because we're using reference equality. I plan to add value-equality constants in a follow-up. Add ImmutableSortedSet marshaller because I think it might have been needed, and hey, why not. PiperOrigin-RevId: 192326359
* Optimize GC churn due to PackageFunction#getContainingDirectory. While I'm ↵Gravatar nharmata2018-03-15
| | | | | | | | | here, also slightly restructure the code in #handleLabelsCrossingSubpackagesAndPropagateInconsistentFilesystemExceptions to make it more readable (and defer PackageIdentifier allocations). Alternatives considered: Add a PathFragment#getParentDirectoryOfRelative(String other) instance method, and use it in PackageFunction#getContainingDirectory. I thought the approach in this CL would be preferable to adding a specialized method like that to PathFragment. RELNOTES: None PiperOrigin-RevId: 189197855
* Serialize Path using AutoCodec.Gravatar janakr2018-03-05
| | | | PiperOrigin-RevId: 187945746
* Deletes CODEC fields now that they are no longer needed.Gravatar shahan2018-02-28
| | | | PiperOrigin-RevId: 187397314
* Move CommandLine, CommandLineItem, and ParamFileInfo from ↵Gravatar tomlu2018-02-15
| | | | | | | | | lib.analysis.actions -> lib.actions. These are fundamental types that want to sit alongside types like Spawn. RELNOTES: None PiperOrigin-RevId: 185887971
* Add context argument to ObjectCodec.{serialize,deserialize}Gravatar michajlo2018-02-11
| | | | | | | | | | Context implementations are currently empty, just doing the plumbing in this change. Once this is in we can start passing along the ObjectCodecRegistry, which will allow runtime codec resolution for classes not known at compile time. We'll also inevitably add some memoization helpers, allowing us to optimize the serialization process further. PiperOrigin-RevId: 185305674
* Replace path implementation.Gravatar tomlu2018-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Path and PathFragment have been replaced with String-based implementations. They are pretty similar, but each method is dissimilar enough that I did not feel sharing code was appropriate. A summary of changes: PATH ==== * Subsumes LocalPath (deleted, its tests repurposed) * Use a simple string to back Path * Path instances are no longer interned; Reference equality will no longer work * Always normalized (same as before) * Some operations will now be slower, like instance compares (which were previously just a reference check) * Multiple identical paths will now consume more memory since they are not interned PATH FRAGMENT ============= * Use a simple string to back PathFragment * No more segment arrays with interned strings * Always normalized * Remove isNormalized * Replace some isNormalizied uses with containsUpLevelReferences() to check if path fragments try to escape their scope * To check if user input is normalized, supply static methods on PathFragment to validate the string before constructing a PathFragment * Because PathFragments are always normalized, we have to replace checks for literal "." from PathFragment#getPathString to PathFragment#getSafePathString. The latter returns "." for the empty string. * The previous implementation supported efficient segment semantics (segment count, iterating over segments). This is now expensive since we do longer have a segment array. ARTIFACT ======== * Remove Path instance. It is instead dynamically constructed on request. This is necessary to avoid this CL becoming a memory regression. RELNOTES: None PiperOrigin-RevId: 185062932
* Add CommandLineItem interface.Gravatar tomlu2018-01-25
| | | | | | | | This interface makes it clearer in the type system exactly how items that go into a CustomCommandLine are turned into strings. It is a preparatory change to allow command line fingerprints to be more cheaply calculated, but it is valuable in itself from a code quality standpoint. PiperOrigin-RevId: 183274022
* Fix usages of PathFragment segments that will become inefficient.Gravatar tomlu2018-01-19
| | | | | | | An upcoming replacement to PathFragment will not have efficient segment semantics, causing code to become unnecessarily inefficient. RELNOTES: None PiperOrigin-RevId: 182553098
* Inline rarely used PathFragment methods that do not deserve to be on a core ↵Gravatar tomlu2018-01-19
| | | | | | path class. PiperOrigin-RevId: 182526427
* Change packaging rules to operate on strings instead of path fragments.Gravatar tomlu2018-01-12
| | | | | | | | | | | | The upcoming path refactor will normalize all path fragments upon creation. That is fine 99% of the time, but sometimes we want to disallow non-normalized paths on rule attributes. Even this isn't usually a problem since we can validate the string prior to putting it in a path fragment. However, in the case of the packaging rule we do not know the rules of validation until the packaging rule is *consumed* by some other rule. Therefore, retain input as a string on these rules all the way through. We don't really do a lot of path fragmenty stuff with these strings. The main drawback is losing a bit of type safety / readability. SKIP_KOKORO PiperOrigin-RevId: 181760613
* Redo FileType to reduce generated garbage.Gravatar tomlu2017-12-22
| | | | | | | | | | | | | * Change FileType to no longer assume it operates on just the base name (it can now be given a full path). * Move the responsibility to specific classes (Artifact, Path, PathFragment) to decide how they want to offer up a string that includes the file name. * Flip the order in which users are expected to check Artifact type, from FileType#matches(Artifact) to Artifact#isFileType(FileType). This looks natural and should encourage developers to use efficient file type checking methods. * Change CppCompileAction to use the new API. RELNOTES: None PiperOrigin-RevId: 179903239
* Makes PathFragment have internal CODEC definition.Gravatar Googler2017-12-19
| | | | PiperOrigin-RevId: 179588512
* Update PathPackageLocator to take a list of potential build file names,Gravatar John Cater2017-11-28
| | | | | | | | | | | | | | instead of assuming BUILD. - Default the list to the same value as PackageLookupFunction: BUILD.bazel, BUILD. - Move BuildFileNames to the packages package, so it is more generally available. Part of #4056. Change-Id: Ie12512b492cd7d47a9e56ec3bc209f829feaf4b5 PiperOrigin-RevId: 177261295
* Replace all usages of Blaze's Preconditions class with guava.Gravatar tomlu2017-11-09
| | | | | | | | Blaze had its own class to avoid GC from varargs array creation for the precondition happy path. Guava now (mostly) implements these, making it unnecessary to maintain our own. This change was almost entirely automated by search-and-replace. A few BUILD files needed fixing up since I removed an export of preconditions from lib:util, which was all done by add_deps. There was one incorrect usage of Preconditions that was caught by error prone (which checks Guava's version of Preconditions) that I had to change manually. PiperOrigin-RevId: 175033526
* Break dependency on vfs from the interface of syntax and cmdline.Gravatar tomlu2017-11-06
| | | | | | | | These libs are exposed externally, implying that the vfs is also exposed externally. We break out PathFragment from vfs to still use this in their interface. This class is a much smaller dependency than the entire vfs. PiperOrigin-RevId: 174729373
* Make UnionFileSystem accept all paths Bazel can throw at it.Gravatar ccalvarin2017-09-27
| | | | | | | | | Instead of relying on a character-by-character StringTrie, segment paths based on PathFragments. This means UnionFS can accept any path that Bazel stores internally, removing the ASCII limitations. This also means removing the ability to have a filesystem bound for sub-PathFragments, /foo/barbar, /foo/barqux could have the same filesystem bound at /foo/bar. This feature was tested for when a use case was envisioned, but it was never used, so removing it is safe. RELNOTES: None. PiperOrigin-RevId: 170054656
* Add all generated headers as mandatory inputs for compile actions.Gravatar rduan2017-07-21
| | | | | | | We previously only add those under genfiles root. But J2ObjC and objc proto headers are under the bin root, which we may also fix in the near future. RELNOTES: None. PiperOrigin-RevId: 162656166
* Inline AttributeContainer.ATTRIBUTE_CONTAINER_FACTORY and ↵Gravatar laurentlb2017-07-03
| | | | | | | PathFragment.TO_PATH_FRAGMENT RELNOTES: None. PiperOrigin-RevId: 160668541
* Automated conversion to Java 8Gravatar laurentlb2017-06-30
| | | | | | | With a few manual fixes for readability. RELNOTES: None. PiperOrigin-RevId: 160582556
* For objc rules, generated headers are mandatory inputs to CppCompileAction.Gravatar cpeyser2017-05-26
| | | | PiperOrigin-RevId: 157218175
* Make PathFragment an abstract class.Gravatar nharmata2017-04-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are now four concrete implementations: RelativeUnixPathFragment, AbsoluteUnixPathFragment, RelativeWindowsPathFragment, AbsoluteWindowsPathFragment. Goals: -Reduce memory usage of PathFragment on non-Windows platforms while maintaining existing semantics. -Make a few simple performance improvements along the way. -Add TODOs for a few more simple performance improvements. -Open the way for reducing code complexity of PathFragment. All of the Windows-specific stuff ought not complicate the code so much. Non goals: -Make the entire codebase as pretty as possible wrt PathFragment & Windows. -Make PathFragment usage more sane in general (e.g. change semantics to ban coexistence of Windows and Unix PathFragments). -Optimize PathFragment as much as possible wrt memory or even in any other dimensions (e.g. gc churn, cpu). To elaborate, the primary motivation is per-instance memory usage of PathFragment on Unix platforms: Before this change ------------------ +UseCompressedOops --> 32 bytes per instance -UseCompressedOops --> 40 bytes per instance After this change ------------------ +UseCompressedOops --> 24 bytes per instance -UseCompressedOops --> 32 bytes per instance Since Bazel can retain lots of PathFragments, the memory savings of this CL are fairly large. RELNOTES: None PiperOrigin-RevId: 154052905
* Update stale Windows path comment.Gravatar ccalvarin2017-04-11
| | | | PiperOrigin-RevId: 152684266
* Remove the last remaining public ctor from PathFragment.Gravatar nharmata2017-04-07
| | | | | RELNOTES: None PiperOrigin-RevId: 152400979
* Refactor all ctor callsites of PathFragment to instead call a static ↵Gravatar nharmata2017-04-05
| | | | | | | | | | | | '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
* PathFragment comparisons are now platform-aware Gravatar László Csomor2017-03-06
| | | | | | | | | | | | | | | | | | | | | | | | | PathFragment's `equals`, `hashCode`, `compareTo`, `startsWith`, `endsWith`, and `relativeTo` are now aware of case-insensitivity when running on Windows. This approach is better than https://bazel-review.googlesource.com/c/9124/ because it preserves path casing, which is important when computing action output paths. This change contains two additional bugfixes: - `compareTo` now takes `driveLetter` into account - the `InMemoryFileSystem` in `PathWindowsTest` is not case-insensitive Fixes https://github.com/bazelbuild/bazel/issues/2613 -- Change-Id: I1a4250a373fff03fa02a6d8360457450b47a42a8 Reviewed-on: https://cr.bazel.build/9126 PiperOrigin-RevId: 149106930 MOS_MIGRATED_REVID=149106930
* Fix PathFragment to not use Java8-only static hashCode methods.Gravatar John Cater2016-12-15
| | | | | | | | Fixes #2247. -- PiperOrigin-RevId: 142143520 MOS_MIGRATED_REVID=142143520
* VFS: PathFragment is no longer aware of MSYS pathsGravatar Laszlo Csomor2016-10-27
| | | | | | | | | | | | | PathFragment no longer parses "/c/foo" as "C:/foo" on Windows, but as a driveletter-less absolute path. If such a PathFragment is used in creating a Path object, the WindowsPath.translatePath method will translate it correctly. Fixes https://github.com/bazelbuild/bazel/issues/1994 -- MOS_MIGRATED_REVID=137283176
* VFS: implement a Windows-specific Path subclassGravatar Laszlo Csomor2016-10-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change rolls forward commit e0d7a540e3c615c628f63fcaaaba0c47fca2cb25 and commit 8bb4299b28de14eed9d3b57bcaeb9350c81c7db3, and adds a bugfix: - FileSystem.PathFactory got a new translatePath method that WindowsFileSystem.PathFactory overrides to translate absolute Unix paths to MSYS-relative paths - Path.getCachedChildPath calls this translatePath method so the child path is registered with the correct (translated) parent and under the correct name (e.g. "C:" instead of say "c") Below is the rest of the original change description: The new subclass WindowsFileSystem.WindowsPath is aware of Windows drives. This change: - introduces a new factory for Path objects so FileSystems can return a custom implementation that instantiates filesystem-specific Paths - implements the WindowsPath subclass of Path that is aware of Windows drives - introduces the bazel.windows_unix_root JVM argument that defines the MSYS root, which defines the absolute Windows path that is the root of all Unix paths that Bazel creates (e.g. "/usr/lib" -> "C:/tools/msys64/usr/lib") except if the path is of the form "/c/foo" which is treated as "C:/foo" - removes all Windows-specific logic from Path PathFragment is still aware of drive letters and it has to remain so because it is unaware of file systems. WindowsPath restricts the allowed path strings to absolute Unix paths where the first segment, if any, is a volume specifier. From now on if Bazel attempts to create a WindowsPath from an absolute Unix path, Bazel will make it relative to WindowsPath.UNIX_ROOT, unless the first component is a single-letter name (e.g. "/c/foo" which is "C:/foo"). Subclassing Path is necessary because a Unix-style absolute path doesn't sufficiently define a full Windows path, as it may be relative to any drive. Fixes https://github.com/bazelbuild/bazel/issues/1463 -- MOS_MIGRATED_REVID=137149483
* Rollback of commit e0d7a540e3c615c628f63fcaaaba0c47fca2cb25.Gravatar Philipp Wollermann2016-10-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Suspected root cause for Windows bootstrap on Bazel CI breakage: java.lang.NullPointerException at com.google.devtools.build.lib.vfs.Path$1.run(Path.java:123) http://ci.bazel.io/view/Bazel%20bootstrap%20and%20maintenance/job/Bazel/922/JAVA_VERSION=1.8,PLATFORM_NAME=windows-x86_64/console *** Original change description *** VFS: implement a Windows-specific Path subclass The new subclass WindowsFileSystem.WindowsPath is aware of Windows drives. This change: - introduces a new factory for Path objects so FileSystems can return a custom implementation that instantiates filesystem-specific Paths - implements the WindowsPath subclass of Path that is aware of Windows drives - introduces the bazel.windows_unix_root JVM argument that defines the MSYS root, which defines the absolute Windows path that is the... *** -- MOS_MIGRATED_REVID=136583352
* Add file extension property to SkylarkGravatar Paul Roberts2016-10-18
| | | | | | | RELNOTES[NEW]: Files now have an "extension" property in Skylark. -- MOS_MIGRATED_REVID=136425934
* VFS: implement a Windows-specific Path subclassGravatar Laszlo Csomor2016-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new subclass WindowsFileSystem.WindowsPath is aware of Windows drives. This change: - introduces a new factory for Path objects so FileSystems can return a custom implementation that instantiates filesystem-specific Paths - implements the WindowsPath subclass of Path that is aware of Windows drives - introduces the bazel.windows_unix_root JVM argument that defines the MSYS root, which defines the absolute Windows path that is the root of all Unix paths that Bazel creates (e.g. "/usr/lib" -> "C:/tools/msys64/usr/lib") except if the path is of the form "/c/foo" which is treated as "C:/foo" - removes all Windows-specific logic from Path PathFragment is still aware of drive letters and it has to remain so because it is unaware of file systems. WindowsPath restricts the allowed path strings to absolute Unix paths where the first segment, if any, is a volume specifier. From now on if Bazel attempts to create a WindowsPath from an absolute Unix path, Bazel will make it relative to WindowsPath.UNIX_ROOT, unless the first component is a single-letter name (e.g. "/c/foo" which is "C:/foo"). Subclassing Path is necessary because a Unix-style absolute path doesn't sufficiently define a full Windows path, as it may be relative to any drive. Fixes https://github.com/bazelbuild/bazel/issues/1463 -- MOS_MIGRATED_REVID=136350304
* Expand $(location :label) to string unambiguously a pathGravatar Klaus Aehlig2016-10-14
| | | | | | | | | | | | | | | | | | | In genrules, cmd strings of the form "$(location :label) ..." are used with the assumption that the executable named by the label will be called. This holds true as long as $(location :label) expands to a string that is recognizable as a path, i.e., as long as :label does not refer to a file in the top-level directory. In the latter case, however, that string will be the plain file name and the shell will search for that name in the search path. This will fail, if '.' is not in the search path; even worse, if a file with that name is in the search path before '.', then that one will be called which is not what the user intended to do. Fix this unintended behavior by expanding $(location :label) to a string that unambiguously is a path. -- Change-Id: If8681039a8befae6234fbe0cbe3a0f75eedba7aa Reviewed-on: https://bazel-review.googlesource.com/#/c/6691 MOS_MIGRATED_REVID=136151500
* Making the PathFragment interned segments list public, to be used later inGravatar Googler2016-09-08
| | | | | | | generating the directory tree nodes efficiently. -- MOS_MIGRATED_REVID=132433991
* Remove not-quite necessary serialization bitsGravatar Michajlo Matijkiw2016-07-15
| | | | | | | What we really are doing here is formatting. -- MOS_MIGRATED_REVID=127481183
* Fix interning in PathFragment.create(char, bool, String[])Gravatar Michajlo Matijkiw2016-06-24
| | | | | -- MOS_MIGRATED_REVID=125721556
* Remove extraneous space added by commit 5e34a3d4ea30525971e320ce283ba8cd67c74e3cGravatar Nathan Harmata2016-05-17
| | | | | -- MOS_MIGRATED_REVID=122542339
* Use Bazel Preconditions variant which avoids varargs array creationGravatar Mark Schaller2015-12-10
| | | | | | | Reduces garbage. -- MOS_MIGRATED_REVID=109914243
* ASwB aspect: parse java packages during executionGravatar Googler2015-12-03
| | | | | -- MOS_MIGRATED_REVID=109305952
* C++ libraries in remote repos don't need to set include pathsGravatar Kristina Chodorow2015-11-12
| | | | | | | | | Fixes #445, based on https://github.com/bazelbuild/bazel/compare/master...ulfjack:cpp-include-path. RELNOTES: C++ libraries no longer need includes = ["."] (or similar copts) to include paths relative to a remote repository's root. -- MOS_MIGRATED_REVID=107593486
* Reduce memory churn while creating PathFragments.Gravatar Eric Fellheimer2015-10-27
| | | | | -- MOS_MIGRATED_REVID=106329484
* Rationalize copyright headersGravatar Damien Martin-Guillerez2015-09-25
| | | | | | | | | | | The headers were modified with `find . -type f -exec 'sed' '-Ei' 's|Copyright 201([45]) Google|Copyright 201\1 The Bazel Authors|' '{}' ';'` And manual edit for not Google owned copyright. Because of the nature of ijar, I did not modified the header of file owned by Alan Donovan. The list of authors were extracted from the git log. It is missing older Google contributors that can be added on-demand. -- MOS_MIGRATED_REVID=103938715
* Description redacted.Gravatar Michajlo Matijkiw2015-08-24
| | | | | -- MOS_MIGRATED_REVID=101221537
* Add comments about subtle benign race in PathFragment#hashCode.Gravatar Nathan Harmata2015-08-11
| | | | | -- MOS_MIGRATED_REVID=100285918
* Fix up some faulty documentation.Gravatar Googler2015-07-20
| | | | | -- MOS_MIGRATED_REVID=98507575
* Extract, reuse excluded directory assertionGravatar Mark Schaller2015-06-23
| | | | | | | Also adds tests for it. -- MOS_MIGRATED_REVID=96572991
* Some cleanup changes.Gravatar Ulf Adams2015-03-05
| | | | | -- MOS_MIGRATED_REVID=87821306
* Skylark: enable relative paths in load statements. Only paths with 1 segment ↵Gravatar Googler2015-02-09
| | | | | | | | | are treated as relative paths. Obsolete tests are removed from ASTFileLookupFunctionTest. -- MOS_MIGRATED_REVID=85885578
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-06 17:02:51 +0000