Graph Changes

[Havvy]

General cleanup and adding a few methods that I want to use in Clippy.

Need somebody to bikeshed names.

[rust-highfive]

r? @eddyb

(rust_highfive has picked a reviewer for you, use r? to override)

[eddyb]

Missing newline at the end of the file.

[Havvy]

Added newline.

[eddyb]

cc @nikomatsakis Are we fine with such additions?

[bluss]

here it comes: Using the convention of naming the iterator struct exactly like the method that creates it would be good. I see that the existing outgoing_edges doesn't do that, but it's not too late for new additions to do so.

[ranma42]

This should probably become

 // A --> B --> C

(i.e. '+' should become '-')

[Havvy]

Oh whoops. I noticed that the comment was wrong in general about the placement of f, so moved it to be correct, but forgot to update the + there. Also fixed in the other comment where I just removed F.

[Havvy]

@bluss So based on that, what names are you thinking? Because I think you're thinking nodes_iter_enumerated or nodes_iter_enumerated_by_index.

[bluss]

@Havvy Well I didn't propose anything about that, only that the struct should be named like the method or vice versa. So for example AllNodesEnumerated with the current patch.

Spontaneously, maybe fn enumerated_nodes(&self) -> EnumeratedNodes<N> and so on?

[Havvy]

I like those method names better, and went with them, and also made the Iterator structs match the method names.

[nikomatsakis]

I have no objection to extending the graph API, but I would say we have no intention of supporting it. It'd probably be better for clippy to use petgraph or something on crates.io.

[eddyb]

@nikomatsakis This is for using rustc::cfg directly. Maybe I should've suggested MIR, but #37400 hadn't landed yet at that time.

[nikomatsakis]

@eddyb it'd probably be better for clippy to recreate the graph in petgraph then =)

[nikomatsakis]

but yeah I'm fine w/ landing these changes, particularly since cfg's time is limited.

[Havvy]

Is rustc_data_structures::graph also going away when cfg goes away? If not, these are still probably useful.

[alexcrichton]

@Havvy thoughts about extracting this data structure to crates.io, perhaps build on petgraph? If what @nikomatsakissays is correct then this is soon to be deleted anyway.

[Havvy]

There's a similar lint already in the compiler (infinitely recursive functions) as to what I am attempting to do (though I've put in on hold for a couple days because, yay trying to figure out what's staying and what's changing), so I can just use what that lint uses. I don't need cfg if there's an alternative way and I'd rather not maintain or force to be maintained for clippy a version of cfg outside of the Rust repository.

So my question is, is the Graph structure used outside of cfg. If so, these commits are still probably useful (except probably the last one), but if not, there's no point merging this and it should be closed. So, what is the future of Graph?

[nikomatsakis]

To be clear, I have no objection to landing this PR for the time being. I just want to be clear that there are no promises of backwards compatibility etc.

[eddyb]

@bors r+

[bors]

📌 Commit 9ddbb91 has been approved by eddyb