| Commit message (Collapse) | Author | Age |
|
|
|
| |
PiperOrigin-RevId: 187397314
|
|
|
|
|
|
| |
More information: https://github.com/junit-team/junit5/issues/531
PiperOrigin-RevId: 186900384
|
|
|
|
|
|
| |
(Des|S)erializationContext.
PiperOrigin-RevId: 185547740
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
declaration.
PiperOrigin-RevId: 184304653
|
|
|
|
| |
PiperOrigin-RevId: 183677348
|
|
|
|
|
|
|
| |
An upcoming replacement to PathFragment will not have efficient segment semantics, causing code to become unnecessarily inefficient.
RELNOTES: None
PiperOrigin-RevId: 182553098
|
|
|
|
|
|
| |
path class.
PiperOrigin-RevId: 182526427
|
|
|
|
|
|
|
|
| |
An absolute root accepts any absolute path fragments and simply returns it.
This concept replaces the FileSystem root directory concept.
PiperOrigin-RevId: 182400471
|
|
|
|
|
|
|
|
|
|
|
| |
This class represents a root (such as a package path or an output root) used for file lookups and artifacts. It is meant to be as opaque as possible in order to hide the user's environment from sky keys and sky functions.
Roots are used by RootedPaths and ArtifactRoots.
This CL attempts to make the minimum number of modifications necessary to change RootedPath and ArtifactRoot to use these fields. Deprecated methods and invasive accessors are permitted to minimise the risk of any observable changes.
RELNOTES: None
PiperOrigin-RevId: 182271759
|
|
|
|
| |
PiperOrigin-RevId: 181686136
|
|
|
|
|
|
|
| |
* Creates an enum for cpu transformer, which is easier to serialize than an opaque function. This also means moving FakeCPU to avoid introducing a circular dependency.
* Adds a CODEC to Path using InjectingObjectCodec.
PiperOrigin-RevId: 181445911
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Rolling forward after the underlying issue has been fixed.
*** Original change description ***
Automated rollback of commit 6a54339bb943702bd7dffc43f85267dac98dc355.
*** Reason for rollback ***
b/71442447
*** Original change description ***
Call through to Path#createDirectoryAndParents from FileUtils.
This CL removes a method that due to its implementation causes threading difficulties for Path#createDirectory.
The tests for the method are brought across to FileSystemTests since the methods are now implemented natively by the FileSystem classes. The tests were also cleaned up.
The test revealed an edge c...
***
PiperOrigin-RevId: 181367850
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
b/71442447
*** Original change description ***
Call through to Path#createDirectoryAndParents from FileUtils.
This CL removes a method that due to its implementation causes threading difficulties for Path#createDirectory.
The tests for the method are brought across to FileSystemTests since the methods are now implemented natively by the FileSystem classes. The tests were also cleaned up.
The test revealed an edge case bug in JavaIoFileSystem, so fix this.
In two cases some code was using the return value from the old method. Returning "f...
***
ROLLBACK_OF=179864042
PiperOrigin-RevId: 180946251
|
|
|
|
|
|
| |
Eg. 'C:foo' was previously "the directory 'foo' relative to the current directory of drive 'C:\'". Now it is simple interpreted as "the relative path fragment 'C:foo'".
PiperOrigin-RevId: 180936012
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL removes a method that due to its implementation causes threading difficulties for Path#createDirectory.
The tests for the method are brought across to FileSystemTests since the methods are now implemented natively by the FileSystem classes. The tests were also cleaned up.
The test revealed an edge case bug in JavaIoFileSystem, so fix this.
In two cases some code was using the return value from the old method. Returning "false" essentially means that the directory already existed, and the code doesn't look racy, so we can replace it with an existence check.
PiperOrigin-RevId: 179864042
|
|
|
|
|
|
|
|
| |
A native implementation of this (instead of using FileSystemUtils, which can only use public interfaces) should be more efficient and more easy to make correct.
In particular, it should allow removing FileSystemUtils#createDirectoriesAndParents, which has poor thread safety characteristics. The latter method has a lot of logic that forces certain unnatural atomicity guarantees on createDirectory, and it also has logic that is conditional on sub-string content of exception messages.
PiperOrigin-RevId: 179819623
|
|
|
|
| |
PiperOrigin-RevId: 179588512
|
|
|
|
| |
PiperOrigin-RevId: 179584358
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #4322, #4306.
*** Reason for rollback ***
Introduces a deadlock (see https://github.com/bazelbuild/bazel/issues/4322)
*** Original change description ***
Make FileSystem operate on LocalPath instead of Path.
PiperOrigin-RevId: 179549866
|
|
|
|
| |
PiperOrigin-RevId: 179082062
|
|
|
|
|
|
|
|
| |
This path type is a local file path as a wrapper around a string. It works much the same as java.io.File, but without its file operations.
For the most part, FilePath shouldn't add much overhead compared to using plain strings. Strings do get normalised on the way in, but no extra objects are allocated unless the path actually needs normalisation.
PiperOrigin-RevId: 178798497
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 178426166
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 177326265
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
file/directory names instead of paths.
This is a small isolated change that can be done ahead of the big refactoring.
PiperOrigin-RevId: 173124518
|
|
|
|
|
|
| |
It now correctly delegates to the right file system.
PiperOrigin-RevId: 172916854
|
|
|
|
|
|
|
|
| |
Nobody sets a delegate anymore, meaning it should be fine to crash hard if we try to resolve a file outside scope.
The CL was created by inlining ScopeEscapableFileSystem into InMemoryFileSystem, making it impossible to return an outOfScope file status (instead throwing an exception), then trivially fixing the code.
PiperOrigin-RevId: 172886769
|
|
|
|
|
|
|
|
| |
This works better with UnionFileSystem, as (eg.) different mapped file systems might not agree on whether they are read-only.
No actual code changes have been made that actually uses this argument, so this should be a behaviour no-op.
PiperOrigin-RevId: 172782759
|
|
|
|
|
|
| |
the tool setup we do in tests doesn't necessarily have to be copied if we copy a workspace over.
PiperOrigin-RevId: 171864170
|
|
|
|
| |
PiperOrigin-RevId: 171221156
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
RELNOTES: The Build Event Protocol's File.uri field is now properly
encoded according to RFC2396.
PiperOrigin-RevId: 168674865
|
|
|
|
|
|
|
|
|
| |
Split collect, concurrent, vfs, windows into package-level BUILD files.
Move clock classes out of "util", into their own Java package.
Move CompactHashSet into its own Java package to break a dependency cycle.
Give nestedset and inmemoryfs their own package-level BUILD files.
PiperOrigin-RevId: 167702127
|
|
|
|
|
|
|
|
|
|
|
|
| |
PR #2679 allowed parentheses ("(" and ")") in globs, but other bracket
style characters were not allowed at the time. It was decided in
issues #2583 and #3048 that other bracket characters should be allowed
as well, since there is no apparent historical reason for disallowing
them in the first place.
Closes #3166.
PiperOrigin-RevId: 159691498
|
|
|
|
|
|
|
|
|
| |
the currently defined hash function for blobs. Some refactoring. Adding an option to set the hash function in the remote worker, defaulting to the current behavior (unfortunately it is a build option, have not found a clean way to specify it at runtime).
BUG=62622420
TESTED=remote worker
RELNOTES: none
PiperOrigin-RevId: 159473116
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 157685150
|
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 157446717
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[]
This change has been automatically generated by an Error Prone check that
detects incorrect argument ordering on calls to assertEquals-style methods. See
[]
Cleanup change automatically generated by javacflume/refactory
Refactoring: third_party/java_src/error_prone/project/core/src/main/java/com/google/errorprone/bugpatterns/argumentselectiondefects:AssertEqualsArgumentOrderChecker_refactoring
Tested:
TAP --sample for global presubmit queue
[]
PiperOrigin-RevId: 156539781
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
latter swallows all filesystem failures, and does not disambiguate missing files from filesystem problems.
The syscall cache now tracks IOExceptions if they are present, just as it does with readdir().
RELNOTES: None
PiperOrigin-RevId: 153185433
|
|
|
|
|
|
|
| |
drive letters.
RELNOTES: None
PiperOrigin-RevId: 152944088
|
|
|
|
|
|
|
| |
More info here #2583
Closes #2679.
PiperOrigin-RevId: 152685327
|
|
|
|
|
|
|
|
|
|
|
|
| |
'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
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 148749485
MOS_MIGRATED_REVID=148749485
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the new CreateJunction in the Windows JNI code
every time we need to create junctions. This means
updating WindowsFileOperations and related tests.
Add test for WindowsFileSystem.createSymbolicLink.
See https://github.com/bazelbuild/bazel/issues/2238
--
Change-Id: I5827e2e70e8e147f5f102fabf95fa9a148b3bcdc
Reviewed-on: https://cr.bazel.build/8896
PiperOrigin-RevId: 147598107
MOS_MIGRATED_REVID=147598107
|
|
|
|
|
|
|
|
| |
implementation for integration tests.
--
PiperOrigin-RevId: 146114082
MOS_MIGRATED_REVID=146114082
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TL;DR: resolve "C:/progra~1" style paths, don't
cache failed resolutions in the parent's
Path.children
When creating WindowsPath objects, resolve the
"C:/progra~1" style paths to "C:/program files".
This enables us to correctly compare paths on
Windows. Without this canonicalization we
incorrectly determine "C:/progra~1" and
"C:/program files" to be different when they are
actually the same.
We only attempt to resolve such paths if the name
looks like it's an abbreviated path.
If resolution fails, probably due to the path not
existing, then we don't cache this Path object in
the parent's `children` list. This avoids stale
cache entries in case the path springs into
existence later in the server's lifetime.
Fixes https://github.com/bazelbuild/bazel/issues/2145
We also need to rectify https://github.com/bazelbuild/bazel/issues/2173
--
PiperOrigin-RevId: 143442134
MOS_MIGRATED_REVID=143442134
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 142664504
MOS_MIGRATED_REVID=142664504
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement a JNI method that can resolve 8dot3
style paths. This is necessary because we need to
be able to compare 8dot3 style paths and long
paths [1], and because implementing this correctly
in Java seems to be impossible [2].
This change also adds tests for the JNI isJunction
implementation.
See https://github.com/bazelbuild/bazel/issues/2101
[1] https://github.com/bazelbuild/bazel/issues/2145
[2] https://github.com/bazelbuild/bazel/issues/2145#issuecomment-266766716
--
PiperOrigin-RevId: 142123750
MOS_MIGRATED_REVID=142123750
|