Too many compiler warnings about links HOT 7 CLOSED

@SimonJF, how actively are you working on this? I am currently familiarising myself with overall structure of the source code and I could fix warnings as I go. Just wouldn't want to get in your way with this.

from links.

I watched „What's new in OCamls 4.03” video from this year's ICFP and, according to it, warnings regarding in-place modification of strings will turn into errors at some point in the future.

from links.

While eliminating warnings I found this:

    method private with_rec_env recenv =
      {< rec_env = rec_env >}

The warning is that recenv is unused. Quite rightly! I assume the intended meaning was:

    method private with_rec_env rec_env =
      {< rec_env = rec_env >}

A good example why we should pay attention to warnings.

from links.

I started to silence the warnings but it's quite a lot of work and haven't even got halfway. My work is on silence-warnings branch. It is based off the appserver2 branch, so it should be easy to merge it into sessions once the appserver branch is merged. In fact, this is just one large commit so you can just cherry-pick (but please amend the commit message!)

git cherry-pick 75ced6c16062598c2e5f579a420472d8f1efb506
git commit --amend

@slindley said he'll be aiming to have this work finished before a release, so some things to keep in mind:

• some functions have unused parameters. Remove those parameters rather than replace them with _ - it often turns out that some value is computed and passed down through several calls only to be discarded
• when dealing with non-exhaustive pattern matches try to enumerate all the possible values rather than add a catch-all pattern. This is a much better thing to do in case a data type gets new constructors in the future.
• sometimes there are lambdas that do a pattern-match on some particular constructor and this generate a warning about non-exhaustive patterns. Here's an example how I decide to deal with that. And here is another
• You will sometimes see warnings about implicit elimination of optional arguments. Here's my solution

from links.

Now that the appserver2 branch has been squash-merged into sessions the silence-warnings branch doesn't cleanly sync with it any more (lots of spurious merge conflicts). To sort this out, Garrett and I just created a silence-warnings2 branch which is in sync with sessions and includes @jstolarek's one large commit. This is where further work on silencing warning will be carried out - in the next day or two.

from links.

I'm going through a couple of these; one thing I'm finding a bit is the "unused module" warning. This is generally due to currently-unused instances exported by deriving, which may (or may not) end up being used eventually. In Haskell for example, it's not an issue not to used a derived instance.

These are benign. I'm tempted to suggest suppressing the unused module warning; do people have opinions on this?

Edit: For now, I think I'm going to comment out the spurious instances, so they're easy to add back in if needed.

from links.

from links.