Skip to content

Fix the YAML linter crashing on a file that isn't UTF-8 - #1240

Open
lyrixx wants to merge 1 commit into
phpro:v2.xfrom
lyrixx:fix-yaml-parse-exception-nullable
Open

lyrixx wants to merge 1 commit into
phpro:v2.xfrom
lyrixx:fix-yaml-parse-exception-nullable

Conversation

@lyrixx

@lyrixx lyrixx commented Nov 7, 2026

Copy link
Copy Markdown
Contributor
Q A
Branch v2.x
Bug fix? yes
New feature? no
BC breaks? YamlLintError::fromParseException() takes the file name, like PhpParserError::fromParseException()
Deprecations? no
Documented? no
Fixed tickets

symfony/yaml throws a ParseException without snippet for some errors, like a file that isn't
UTF-8. Its recent versions (6.4.50, 7.4.23, 8.1.11) return null from getSnippet() and
getParsedFile() (symfony/symfony@54bbbdf1), where getSnippet() threw a TypeError before:
the constructor of YamlLintError throws it now. The nullable getters also make Psalm fail on the
highest and lowest jobs.

The lock gets symfony/yaml 7.4.23, so that the new test runs on the lock jobs too. It also fixes
CVE-2026-109413.

@lyrixx
lyrixx marked this pull request as ready for review November 7, 2026 22:38
} catch (ParseException $exception) {
$exception->setParsedFile($file->getPathname());
$errors[] = YamlLintError::fromParseException($exception);
$errors[] = YamlLintError::fromParseException($exception, $file->getPathname());

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Line 67 always sets the parsed file name, so in theory it could be null, but it will never be null.
Not sure it's worth breaking the YamlLintError contract for that purpose.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants