Case insensitivity can lead to lake builds which succeed when done "incrementally" but fail done together
Nobody has claimed this yet.
- Dominant language
- Lean
- Stars
- 9.2k
- Forks
- 990
- Avg merge
- 1d 17h
- Merged PRs (30d)
- 175
Description
Prerequisites
Please put an X between the brackets as you perform the following steps:
- Check that your issue is not already filed:
https://github.com/leanprover/lean4/issues - Reduce the issue to a minimal, self-contained, reproducible test case.
Avoid dependencies to Mathlib or Batteries. - Test your test case against the latest nightly release, for example on
https://live.lean-lang.org/#project=lean-nightly
(You can also use the settings there to switch to “Lean nightly”)
Description
Given a module Foobar/baz.lean, an import spelled import FooBar.Baz (instead of import Foobar.Baz) can produce either a confusing error message or a successful build if done in 2 parts.
Context
I typoed the name of my package, and misattributed why it wasn't building correctly due to the error message.
Steps to Reproduce
Here's a full reproducer, only confirmed macOS, but perhaps which reproduces on any case-insensitive filesystem:
rm -rf Casesensitive && \
lake new Casesensitive lib && \
printf 'import CaseSensitive.Basic\n' >>Casesensitive/Casesensitive/Boom.lean && \
printf 'Both imports, blows up:\n\n\n' && \
printf '\nimport Casesensitive.Boom\n' >>Casesensitive/Casesensitive.lean && \
(cd Casesensitive && \
rm -rf .lake && \
lake build); printf 'Good import then bad import, builds successfully:\n\n\n' && \
printf 'import Casesensitive.Basic\n' >Casesensitive/Casesensitive.lean && \
(cd Casesensitive && \
lake build && \
printf 'import Casesensitive.Boom\n' >Casesensitive.lean && \
lake build && \
printf '\nimport Casesensitive.Boom\n' >>Casesensitive.lean && \
lake build)
where what the reproducer does is:
- create a package
- typo an import
- first build the package with a
Casesensitive.leantarget containing both, which fails - then build it incrementally first with the working file then a second time with both imports in
Casesensitive.lean-- (in my "real scenario" this is precisely what happened, as the file I typoed was a new file I was adding and adding to my build)
Expected behavior: [Clear and concise description of what you expect to happen]
An import error saying CaseSensitive does not exist, even though I'm on a case insensitive filesystem, similar to the message produced on Linux which says CaseSensitive is an unknown prefix. (Ideally it could also hint that Casesensitive does, which could be used even for other minor typos and not just case sensitivity issues).
Actual behavior: [Clear and concise description of what actually happens]
A cryptic error: ././././Casesensitive/Boom.lean:1:0: object file '././.lake/build/lib/CaseSensitive/Basic.olean' of module CaseSensitive.Basic does not exist if the build is done simultaneously (this is cryptic because it's not clear to the user whose fault it is that that file doesn't exist)
If building incrementally, the build succeeds.
Versions
[Output of #eval Lean.versionString] 4.12.0, commit
[OS version, if not using live.lean-lang.org.] macOS 15.0
Additional Information
#2129 is related and may have the same underlying fix -- I've seen errors like that one as well when playing around a bit with ordering of the commands.
Impact
Add 👍 to issues you consider important. If others are impacted by this issue, please ask them to add 👍 to it.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Run the supplied macOS reproducer with lake build, comparing the clean build with the incremental sequence, and start by tracing module import resolution and Lake's build artifact handling for case-insensitive paths. Done means the typoed CaseSensitive.Basic import consistently reports an import error, including when builds are performed incrementally, without producing the missing-object-file error.
Written by the indexing model from the issue text.
Assessment
- Domain
- build-system, compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100