Totality check failed via case. 0.3.0-42d4c3683

Steps to Reproduce

filter0 : (a -> Bool) -> List a -> List a
filter0 p       []  = []
filter0 p (x :: xs) = if p x then x :: filter0 p xs else filter0 p xs

filter0' : (a -> Bool) -> List a -> List a
filter0' p = \case
  [] => []
  x :: xs => if p x
    then x :: filter0' p xs
    else      filter0' p xs

Observed Behavior

filter0' is not total, possibly not terminating due to recursive path Main.filter0' -> Main.filter0' -> Main.filter0'

I changed my https://github.com/gipfelen/vaporLinuxLeak such that it uses jemalloc instead of malloc. But after a single call of http://localhost:8080/hello it uses more than 800MB of RAM, and it doesn't get freed (even after 5min +).

Ok, this new behavior is now behind an experimental flag (-Xcheck-hashes)

There is still a need for a windows Idris-dev since I don't have a windows machine and removing the escape didn't solve the issue. (I could leave the windows version unimplemented and leave a constant string in place but that would be less than ideal. UnU)

50 %default total (1 was a %default covering) and 21 %default covering.

Edit: Thanks to @buzden 54 %default total (5 were %default covering) and 17 %default covering.

Yeah I was just wating for @buzden 's comment on the interface change, let's just merge it for now, nothing too controversial here

Hey @andrevidela, I am confident that this PR is not over 1% slowdown and totality checking would be desirable. Though if there is another benchmark you would want me to run I would be more than happy to run them.

I had a similar issue, memory use increased over time using Linux until the app crashed while the same code had no issues on macOS. I was able to solve this by implementing jemalloc in my container

Deployed my Vapor Docker Container on CloudFoundry with 1GB RAM allocated. Since last week I tested my code under production conditions, decoding an 15MB-ish JSON every hour and writing this data to an internal Fluent SQLite DB. I noticed that now over time more and more RAM was used until the container crashed. @Lukasa mentioned jemalloc, hence I googled a bit and found that some other communities had similar issues and overcame them by using this allocator. Using jemalloc my RAM is looking great, after 24hours at about 80MB used. Previously it would have crashed 3 times by now.

My Dockerfile: [...]

================================

Run image

================================

FROM swift:5.4-focal-slim

Make sure all system packages are up to date.

RUN export DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true &&
apt-get -q update && apt-get -q dist-upgrade -y && apt-get -y install libjemalloc2 && rm -r /var/lib/apt/lists/*

ENV LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so**

[...]

Merginig would be great, yeah I could have done that wraping/unwrapping but then the 2 line wrapColor helper would have ended shorter than using Control.ANSI. unu

We can open a PR to improve the ANSI API and add the change there. On the matter of the API, you can already have bolded and colored text, but you have to construct or unwrap DecoratedString manually. We can probably add a function that merges the decoration annotations of multiple helpers like bolden or colored, just for ergonomics.

Yes

Well, not gonna bikeshed the use of bold so this could be merged with only the color changes.

I didn't realise that, maybe that's also the opportunity to revise the ANSI api. I think @ShinKage was the one to write it. What do you think @ShinKage ? should we open an issue to update the ANSI API to allow colored and bolded text?

I am having issues mixing up bolden and colored together since

bolden : String -> DecoratedString
colored : Color -> String -> DecoratedString

And the only DecoratedString -> other is a field accesor or show = escapeSGR dstr.sgr ++ dstr.str ++ escapeSGR [Reset]

Will use Control.ANSI without bold for the time being; pushed the changes.

module LinearVoid

foo : (1 _ : Char) -> (x : Maybe (Int -> Void)) -> Char
foo v Nothing = v
foo v (Just y) = void (y 5)

The above doesn't typecheck with: While processing right hand side of foo. There are 0 uses of linear name v.

void should work regardless if in a linear context or not.

This looks like correct behaviour to me. v isn't used in the second clause, and there's nothing magical about void that would make the linearity checker know it can ignore v. So, I'm going to close this one.

#1539 seems to have introduced a regression: everything works with the previous master commit ec1e7c0d, but unexpected behaviour is shown on the next commit 663a8381.

Steps to Reproduce

This module sets up the bounded Nat called Size, and declares a fromInteger that coerces anything over the upperbound to its max value.

On its own, this works as expected.

module Size

import Data.Maybe
import Data.Nat

MaxSizeNat : Nat
MaxSizeNat = 100

public export
record Size where
  constructor MkSize
  size : Nat
  0 sizeOk : LTE n MaxSizeNat

mkSize : (n : Nat) -> {auto 0 ok : LTE n MaxSizeNat} -> Size
mkSize n = MkSize n ok

maxSize : Size
maxSize = mkSize MaxSizeNat {ok=lteRefl}

export
mkSizeMay : Nat -> Maybe Size
mkSizeMay k with (isLTE k MaxSizeNat)
  mkSizeMay k | (Yes prf) = Just $ mkSize k
  mkSizeMay k | (No contra) = Nothing

export
fromInteger : Integer -> Size
fromInteger = fromMaybe maxSize . mkSizeMay . fromInteger

The issue arises when idris2 tries to build this:

module Usage

import Size

upperbound : Size
upperbound = 400

explicit : Size
explicit = fromInteger 42

-- elaborated : Size
-- elaborated = 42

Expected Behavior

All three cases behave identically.

Historically, they all pass, without requiring Usage to import Data.Maybe and Data.Nat.

Observed Behavior

elaborated fails when uncommented, with Error: While processing right hand side of elaborated. Undefined name Data.Maybe.fromMaybe.

I'm going to close this since I think the behaviour now is as good as it can be - I moved it to LHS only. Though at some point I'll see if we can make linearity checking possible in more cases, without knowing the types of unimported things (maybe if there's no linear bindings, for example).

One to improve elaboration of fromInteger so we only fully normalise on the LHS. Another to fix #1510 and properly check whether LHS patterns are polymorphic enough.

Steps to Reproduce

tupleBug : ((), a) -> ()
tupleBug (_, _, _) = ()

Expected Behavior

Should error

Observed Behavior

No error

Phew, that turned out to be quite a rabbit hole. But I've changed the way we check whether LHS arguments are polymorphic enough now, to make sure we check all of them, not just the ones that happen to be checkable on a first pass.

One to improve elaboration of fromInteger so we only fully normalise on the LHS. Another to fix #1510 and properly check whether LHS patterns are polymorphic enough.