Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a graphviz crate for making .dot files to layout and render graphs. #13749

Merged
merged 3 commits into from
May 5, 2014

Conversation

pnkfelix
Copy link
Member

Add a graphviz crate for making .dot files to layout and render graphs.

(This is a precursor to other work to render control-flow graphs from within rustc itself; but this crate should be independently usable, since it abstracts over the client's graph-representation and labeling method.)

@pnkfelix
Copy link
Member Author

r? anyone (i don't think anyone needs to own review of this).

@lilyball
Copy link
Contributor

Is this something that belongs in the rust distribution, as opposed to being a separate project? graphviz seems a bit, well, niche.

@huonw
Copy link
Member

huonw commented Apr 25, 2014

At the moment there is no other feasible way to use a crate in the compiler, as @pnkfelix is aiming to do with control-flow graphs.

@brson
Copy link
Contributor

brson commented Apr 25, 2014

As much as I don't want to have a graphviz library, if rustc needs it then, like ebml, I guess we don't have a lot of choice.

@pnkfelix can you add #![experimental] to the entire crate?

html_favicon_url = "http://www.rust-lang.org/favicon.ico",
html_root_url = "http://static.rust-lang.org/doc/master")]

#![experimental]
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@brson is this not the right place to put the experimental directive?

(I admit, I was a little surprised that these headers all appear after the (long) documentation block; but that appears to be the pattern used in the other crates...)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is interesting, I had been spitting out graphviz dot files from "rust find".

@lilyball
Copy link
Contributor

I did not review for correctness (I'm not particularly familiar with graphviz), and I ignored the tests, but I've put comments on most everything else.

I would like to see ~[T] and ~str removed as much as possible here. ~[T] is used in the examples and tests, and I don't see why. Removing ~str will presumably require rewriting str::MaybeOwned to use StrBuf, which should perhaps happen as a different commit.

Given the issues surrounding MaybeOwned and MaybeOwnedVector, I'm inclined to say that we should solve those first in a different PR, and then rebase on this on top. I'm assuming, of course, that getting graphviz support into the compiler is not critical at the moment.

@lilyball
Copy link
Contributor

After thinking some more, I don't think we can change str::MaybeOwned yet, because there's still too much dependency on ~str in the libraries. But MaybeOwnedVector should still be put into libstd and have its API adjusted.

@pnkfelix
Copy link
Member Author

(i'll fix the other formatting issues that @kballard has pointed out; I decided I should stop spamming with the "will fix" notes on minor things like that.)

@pnkfelix
Copy link
Member Author

I don't see much point in trying to remove all occurrences of ~str. I can get rid of most of them, but for example, the StrSlice::escape_default method returns a ~str, not a StrBuf, and so I might as well have the LabelText::escape method likewise return ~str.

What I am trying to say is that there is a broader argument about whether to use ~str or StrBuf (and that discussion is taking place on #13717). Since I suspect that discussion will not be settled until sometime later than the point that I would like to land this, my plan for now is to avoid ~str where possible, but keep using it where natural (namely in the LabelText::escape method).

/// edges, as well as an identifier for the graph itself.
pub trait Labeller<'a,N,E> {
/// Must return a DOT compatible identifier naming the graph.
fn graph_id<'b>(&'a self) -> Id<'a>;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

argh, I just noticed these useless <'b> bounds, I need to get rid of those before this gets merged.

Namely:

 * Added conversion traits both to and from the various vector types,
   analogous to how `str::MaybeOwned` works with `str::IntoMaybeOwned`
   and `str::Str`.  This led me to add the `FixedLen` variant of
   `MaybeOwnedVector` for interoperability with `std::slice`.

 * Revised client example code to make use of `into_maybe_owned`

 * Added implementations of `Show` and `CloneableVector` for
   `MaybeOwnedVector`.

 * As suggested by kballard, added `into_vec` method that is analogous
   to `CloneableVector::into_owned` except it produces a `Vec` rather
   than a `~[T]`.
@pnkfelix
Copy link
Member Author

pnkfelix commented May 2, 2014

(push -f'ed a version that removes the aforementioned useless <'b> bindings.)

@pnkfelix
Copy link
Member Author

pnkfelix commented May 2, 2014

(... and apparently I clobbered the previous short discussion ... sorry all.... )

@pnkfelix
Copy link
Member Author

pnkfelix commented May 2, 2014

hmm I thought I had tested making the docs, but maybe not the way that bors does... (it looks to me like its interpreting my code block of dot formatted output as if it were rust code). Will fix.

@pnkfelix
Copy link
Member Author

pnkfelix commented May 5, 2014

(and I was inspired by this problem to file #13947 )

bors added a commit that referenced this pull request May 5, 2014
…chton

Add a `graphviz` crate for making .dot files to layout and render graphs.

(This is a precursor to other work to render control-flow graphs from within rustc itself; but this crate should be independently usable, since it abstracts over the client's graph-representation and labeling method.)
@bors bors closed this May 5, 2014
@bors bors merged commit 67307d4 into rust-lang:master May 5, 2014
arcnmx pushed a commit to arcnmx/rust that referenced this pull request Dec 17, 2022
…ustment_hints, r=Veykril

fix: Don't show duplicated adjustment hints for blocks, ifs and matches

Before:
![2022-12-09_21-10](https://user-images.githubusercontent.com/38225716/206761100-5511d91b-2543-4166-aa2c-abdb8bad3613.png)
After:
![2022-12-09_21-22](https://user-images.githubusercontent.com/38225716/206761113-c58dbb5a-8616-4287-a3b4-69c13703294d.png)

----

I want to improve adjustment hints, this is the first step :)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants