Hi, please also fix clippy warnings

Hi, not entirely sure, but the clippy errors don't seem to stem from my changes. Therefore I am not sure how to fix them ? Could there be an issue with clippy/rust nightly ?

Or do you mean that I should change the code snippets that clippy is showing even though they don't have any immediate connection to my PR?

I fixed the warnings in #791, now everything should be fine.

It also took me a long time to overread the code, but it seems to me that you have written everything correctly. The iteration order is something that may change one day in the future, but since users prefer to see a note about the iteration order, we really should make some efforts to maintain clarity.

So (to prove the words about the iteration order), I suggest writing the some tests:

1. one small test for each case;
2. randomized tests for each case on graphs with ~20 vertices and ~20-200 edges (including multiple edges and loops).

Since this is a fairly large job, I will transfer this PR to milestone 0.8.3.

Yes, that is a good idea :) I will add those tests then and reopen the PR once they are done 👍

Could you maybe specify a bit more what you had in mind for the randomized tests? Just to make sure that I include everything you are imagining :)

Could you maybe specify a bit more what you had in mind for the randomized tests?

I mean the tests where we create a graph and remember the order of edge insertion, then iterate over the edges/neighbors comparing the orders. Repeat each such check several times, processing a new random graph each time.
To generate random graphs, there are functions in petgraph or graphalgs. Feel free to adopt it.

Okay, I see, I am just hesitant with combining the randomness and remembering the order of edge insertion, but I'll work something out I guess 👍

Okay, so I added unit tests for Graph and StableGraph, both directed and undirected. I tried to come up with Quickchecks, but nothing seemed very sensible in my opinion.

The problem being that one does not know what edges the arbitrary graph has. And this will definitely influence the order in which neighbors may appear in the different iterators. I tried adding fixed edges to the arbitrary graphs and then checking their order, but these edges might already exist which would confuse the ordering. Of course, one could select certain pairs of nodes, remove existing edges between them and then add edges there and check their order, but at that point it seems somewhat useless to use quickcheck in the first place 🤔

What do you think @starovoid ? Do you have a specific idea on how the quickchecks should look like or would you also be fine with "just" having unit tests, which test for the iteration order of the different functions ?

What do you think @starovoid ? Do you have a specific idea on how the quickchecks should look like or would you also be fine with "just" having unit tests, which test for the iteration order of the different functions ?

Hi! Unit tests look great, I think it makes no sense to overcomplicate the task using quickcheck.
+1330 lines of code, I'm impressed 😃

Oops, just messed something up with the rebase I guess 🤔

This is failing because of #878, could you have a look at the other PR such that we can fix the errors in our CI @starovoid :)?