update kotlin 2.4#2265
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d10cae3653
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| java = "25" | ||
| agp = "9.2.1" | ||
| kotlin = "2.3.21" | ||
| kotlin = "2.4.0" |
There was a problem hiding this comment.
Pin module names before running KSP
With the default Gradle group unset, Kotlin 2.4 changes multiplatform module names to include Gradle path colons (see Kotlin's consistent-module-names-across-platforms note), while this same catalog still uses KSP 2.3.9 and the repo has many internal KSP inputs such as internal interface ...Api Ktorfit services and internal @Single providers. KSP 2.3.9 has an open build-blocking bug where those colon-containing module names are copied into generated identifiers for internal declarations and fail with Can't escape identifier ... : ... (google/ksp#2964), so this version bump needs a convention-level compilerOptions.moduleName(project.name)/sanitized module name before KSP tasks run.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 94a1c8ae35
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| XML.v1 { | ||
| policy { |
There was a problem hiding this comment.
Preserve lenient repeated RSS element parsing
With feeds that repeat a known scalar RSS element, for example WordPress/podcast feeds with multiple <enclosure> tags, this XML.v1 policy inherits xmlutil 1.0's repeated-element checks and throws because Feed.Rss20.Item.enclosure is still a single value; the old defaultPolicy builder defaulted repeated elements to lenient handling, so those feeds kept parsing. Please either restore lenient repeated-element handling in this parser policy or model the remaining repeatable RSS fields as lists, otherwise one duplicate enclosure makes the entire RSS source fail to load.
Useful? React with 👍 / 👎.
No description provided.