Comments (23)
Seems like I have more luck with the release of happy-1.20.1.1
: https://github.com/BNFC/bnfc/actions/runs/3924987003/jobs/7112323965#step:17:46
Completed happy-1.20.1.1 (exe:happy)
from happy.
Next try, folks: https://hackage.haskell.org/package/happy-1.20.1.1
Fingers crossed, I hope I don't awake to a sh*t storm tomorrow again! ;-)
from happy.
Not sure how this happened.
If you look at the diff between 1.20.1 and 1.20.0, no bug was introduced: 1.20.0...1.20.1
Also I successfully built happy from the candidate tarball for 1.20.1.
There might be a non-standard release procedure for happy
that I did not follow.
I'll have a look.
from happy.
@andreasabel I reported this initially on IRC, and in the same environment where 1.20.1 failed 1.20.1.1 candidate builds fine. There's a bunch of
-Wincomplete-uni-patterns
though.
@ulysses4ever : Thanks for testing!
Maybe we should switch off the -Wincomplete-uni-patterns
warning, to annoy users less. This release would be a chance to do so.
from happy.
@andreasabel I think it makes sense to turn off the warning for release. I also think it makes sense to turn it on in development and clean up the code when possible—it's always good to have a place to document why those cases shouldn't be able to happen.
from happy.
We're getting hit by this right now too. Anyone had any luck fixing?
from happy.
Since happy
is an executable dependency (not a library), I don't know how to pin a specific version. The following worked for us:
$ cabal update hackage.haskell.org,2023-02-06T10:26:33Z
$ cabal freeze
Since that index does not include happy
1.20.1. Recent indices here
from happy.
Uhoh, I'm getting the build failure in an unrelated CI: https://github.com/Mikolaj/horde-ad/actions/runs/4108216346/jobs/7088650067#step:17:45
from happy.
@Ericson2314, @andreasabel ^^^
from happy.
It's very likely because the CI script uses cabal update
, and that the version of happy is not pinned. My fix above should work for you @Mikolaj
from happy.
@santiweight: thank you! With some luck, a deprecation on Hackage is coming RSN, which should solve it.
from happy.
The new version seems to have been deprecated now. I don't know how something like that made it to release.
from happy.
@treeowl I am wondering too because this was a bugfix on a release branch.
from happy.
CI cache kept the file that was not in a repo? Or repo kept a file that was not in .cabal (and CI did not include a build from unzipped cabal dist
that haskell-ci normally does IIRC)?
from happy.
@Mikolaj the non-master version had a....manually computed sdist. Maybe we forgot that step.
from happy.
@Mikolaj I checked their CI script (generated by Haskell-CI): it seems to only cache the store. That shouldn't bring the problem you're alluding to, I think. John has a good guess, perhaps.
from happy.
@ulysses4ever: you are right: on master branch they seem to cd
to the directory created when unpacking cabal sdist
and they do cabal check
there and build there [edit; I'm not clear about "build" any more: they seem to remove the project file by that point]. So that should catch the problem. I haven't checked the non-master version though.
from happy.
@andreasabel Did you upload the make sdist
tarball or the one cabal
produces?
from happy.
@Ericson2314 wrote:
Did you upload the
make sdist
tarball or the onecabal
produces?
Yeah, seems my blunder was that I went with the cabal sdist
one...
@ffaf1 wrote:
Build failure reported on #cabal irc channel:
/data/artem/cabal/ci-falls-2023-02/happy-1.20.1/dist-newstyle/build/x86_64-linux/ghc-9.2.5/happy-1.20.1/x/happy/build/happy/happy-tmp/AttrGrammarParser.hs:494:5: error: Not in scope: ‘Bits.testBit’ No module named ‘Bits’ is imported. | 494 | Bits.testBit (Happy_GHC_Exts.I# (indexShortOffAddr arr ((unbox_int bit) `Happy_GHC_Exts.iShiftRA#` 4#))) (bit `Prelude.mod` 16)
I cannot reproduce this error. (Maybe this one happens if you try to bootstrap happy-1.20.1
with an old happy not in sync with the GHC version.)
See CI.
This reports an error I can reproduce:
The program 'happy' is required but it could not be found
So the problem of happy-1.20.1
seems to be that it cannot bootstrap. It needs happy
installed already.
I have uploaded a new candidate: https://hackage.haskell.org/package/happy-1.20.1.1/candidate
This one seems to bootstrap, according to my testing.
However, I should be prudent and wait for some independent verification this time...
Anyone up to testing the new RC (in hostile environment)?
from happy.
@andreasabel I reported this initially on IRC, and in the same environment where 1.20.1 failed 1.20.1.1 candidate builds fine. There's a bunch of -Wincomplete-uni-patterns
though.
from happy.
Maybe we should switch off the
-Wincomplete-uni-patterns
warning,
I did this and updated the candidate.
from happy.
@andreasabel are those warnings in happy
itself or the generated code?
from happy.
These are in happy
itself and look like this:
[ 9 of 19] Compiling Grammar ( src/Grammar.lhs, /Users/abel/tmp/happy-1.20.1/dist-newstyle/build/x86_64-osx/ghc-9.2.5/happy-1.20.1/x/happy/build/happy/happy-tmp/Grammar.o )
src/Grammar.lhs:503:33: warning: [-Wincomplete-uni-patterns]
Pattern match(es) are non-exhaustive
In a lambda abstraction:
Patterns of type ‘AgRule’ not matched:
SelfAssign _ _
RightmostAssign _ _
Conditional _
|
503 | > map (\(SubAssign (i,ident) toks) -> (i,(ident,toks))) $ subRules
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The warning -Wincomplete-uni-patterns
is new in GHC 9.2 and I think it does not make sense to report it on code that has been written for ancient GHCs and been stable for a long time.
from happy.
Related Issues (20)
- Not-unreasonable grammar takes 17min to compile with GHC2021 HOT 3
- Is there a way to revise broken build-plans for older `happy`s? HOT 1
- Should `happy-1.21.0` be revised to become unbuildable? HOT 10
- website (bad link) HOT 2
- inclarity in threaded lexer docs leads to confusing failure HOT 3
- Documentation: Constraints on Parser Monad
- Implement "Principled parsing for indentation-sensitive languages" HOT 5
- Build failures with mtl-2.3 HOT 7
- Upload packages to hackage HOT 5
- Split up CLI into packages
- Incremental parsing
- Internal Happy errors are not helpful
- Idea: Backend for generating railroad diagrams HOT 3
- Please release 1.20.1 from release-1.20 branch HOT 17
- Support LLVM >=14 HOT 1
- haskell-src-exts: Name mismatch in signature and definition HOT 2
- Readthedocs.org requires a config file for the happy documentation
- Happy refactoring (happy-1.21): either move forward or take it back HOT 6
- Grammar that bison/byacc reports 35 reduce/reduce conflicts but happy none HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from happy.