| Age | Commit message (Collapse) | Author |
|---|
|
The stub token search compared every 18-byte window of the file case
insensitively. The token starts with a byte that ASCII case folding
leaves alone, so memchr can pick out the candidate offsets and leave
only those to the case-insensitive compare.
Over the 35 MB executable, finding the token in the embedded bundle
stub drops from 2.3 ms to 0.1 ms, and a scan that finds nothing drops
from 24 ms to 3.6 ms.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
|
checkComposerAudit reported success instead of auditing anything, because
the binary ships no vendor/composer/installed.json on disk. It reads the one
in the embedded Composer PHP runtime now, and Composer's warning for a
missing installed.json is back.
Only that file leaves the bundle, into a temporary directory that goes away
with the handle; the runtime is unpacked whole only for a worker that cannot
read the bundle in place. Phar::extractTo's $files argument selects it,
which the shim ignored so far.
SHIRABE_COMPOSER_PHP_DIR moves into composer_runtime, so the worker and a
reader on the Rust side resolve the runtime through the same branch.
DiagnoseCommandTest::testCmdSuccess is ignored: packagist has advisories
against composer/composer 2.9.7, the version Composer::VERSION reports, so
diagnose exits 1 where the test expects 0. Upstream Composer 2.9.7 reports
the same advisories.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
|
`__halt_compiler` is a PHP keyword, so a stub may spell the token in any
letter case. The native phar reader compared the bytes exactly and rejected
such an archive, and the lint that keeps a second token out of the
executable missed lowercase ones, which would shadow the embedded bundle.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
|
Plugins and scripts need the real `Composer\` classes and the packages
Composer depends on, which so far came from a checkout found through
SHIRABE_COMPOSER_PHP_DIR or a path next to the workspace. Neither exists
for a distributed binary.
The build script now archives those PHP sources into a phar the way
Compiler.php does and the executable carries it. The worker maps it with
Phar::loadPhar and reads a content-addressed sentinel back to tell a
bundle it can use from one it cannot; where its PHP cannot open the phar,
the bundle is unpacked once into the cache directory and autoloaded from
there. SHIRABE_COMPOSER_PHP_DIR still overrides both for development.
PHP locates a phar's manifest by the first __HALT_COMPILER(); token in
the file, so the executable must hold no other copy of it: phar.rs builds
the token at run time, and a linter keeps further literals out of the
sources that reach the binary.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
|
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
|
Ported exceptions were flat structs reached with `downcast_ref`, so
Composer's `catch (\RuntimeException $e)` only matched the exact leaf
type and `get_class($e)` had nothing to report. Each exception now
embeds an instance of the class it extends and travels inside an
`AnyThrowable`; `Catch::catch`/`catch_mut` walk that chain, and
`PhpClass::php_class_name` yields the PHP FQCN.
Dropping the `std::error::Error` impls from the exception types leaves
`AnyThrowable` as the only route into an `anyhow::Error`, so the walk
cannot be bypassed. A `no_exception_downcast` linter catches the
`downcast::<X>()` calls that would now silently answer `None`.
Three sites change behavior as a result: the `TransportException`
exit-code override reaches `MaxFileSizeExceededException`, the
`catch (\LogicException)` in findSimilar() reaches its subclasses, and
rendered exception titles carry the real class name rather than a
guess. `get_class_err()` is no longer a `todo!()`, which re-enables
FilesystemRepositoryTest::testCorruptedRepositoryFile.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
|
The shim's filesystem entry points took `&str` even though each one resolves
to a local path through `std::fs` or a syscall, so callers holding a `PathBuf`
had to stringify it at the call site. They now take `impl AsRef<Path>`, the
form `file_exists`, `is_dir`, `unlink` and the rest of the already-converted
set use.
`Phar`, `PharData` and `ZipArchive` keep their archive path as a `PathBuf`.
`PharData::compress` names the compressed sibling by appending the suffix to
the file name rather than formatting the path into a `String`.
Arguments PHP resolves through a stream wrapper (`fopen`, `file_put_contents`,
`include`) still take `&str`, as do the byte-string operations (`dirname`,
`basename`, `pathinfo`) and archive-internal entry names, which are `/`-joined
logical names rather than OS paths.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
|
Phar::running has its only Composer call site in SelfUpdateCommand, and
self-update will not go through a phar in Shirabe. The .phar writing API
(and the SHA512 constant it takes) is only used by Composer's Compiler,
which packages composer.phar and has no counterpart in a native binary.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
|
Adopt the tar, flate2, and bzip2 crates to fill in the phar.rs and
compress.rs todos: PharData tar/zip reading, building, and whole-archive
compression, plus a native .phar reader that follows the php.net
file-format manual and verifies hash-based signatures. Callers now
propagate the constructor/extract errors PHP throws, and fwrite accepts
byte strings so gzread no longer needs lossy UTF-8.
The native .phar writing API stays todo!() (no call sites; Composer's
Compiler is not ported) and OPENSSL phar signatures are accepted
unverified (TODO(phase-c)).
This unblocks Tar::getComposerJson and the tar/phar/gzip downloaders;
tar_test (7), artifact_repository_test (2), and phar_archiver_test zip
(1) are un-ignored. The archive command itself still panics because
ArchiveManager::archive always generates glob excludes whose look-ahead
regexes the regex crate cannot compile; converting those patterns to
regex-compatible ones is a separate, still-undecided work item.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
|
|
|
|
