JSON backend experimental impl #75114

P1n3appl3 · 2020-08-03T17:49:24Z

This is for preliminary code review of the in progress implementation of RFC 2963.

rust-highfive · 2020-08-03T17:49:28Z

r? @GuillaumeGomez

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

tmandry

Looks pretty good! Left some comments.

src/librustdoc/json/mod.rs

tmandry · 2020-08-04T01:18:02Z

src/librustdoc/json/mod.rs

+        match item.inner.clone() {
+            StructItem(s) => s.fields.into_iter().for_each(|i| self.insert(i, cache)),
+            UnionItem(u) => u.fields.into_iter().for_each(|i| self.insert(i, cache)),
+            VariantItem(clean::Variant { kind: clean::VariantKind::Struct(v) }) => {
+                v.fields.into_iter().for_each(|i| self.insert(i, cache));
+            }
+            EnumItem(e) => e.variants.into_iter().for_each(|i| self.item(i, cache).unwrap()),
+            TraitItem(t) => t.items.into_iter().for_each(|i| self.insert(i, cache)),
+            ImplItem(i) => i.items.into_iter().for_each(|i| self.insert(i, cache)),
+            _ => {}
+        }


I think it would be better to have this knowledge inside a method on ItemEnum itself, either returning an iterator of inner items or taking a closure.

Also, a problem with using a wildcard here is that a new kind of item with children could be added, and this match could be forgotten. So it's actually safer to list everything out.

tmandry · 2020-08-04T01:20:15Z

src/librustdoc/json/mod.rs

+    fn after_krate(&mut self, krate: &clean::Crate, cache: &Cache) -> Result<(), Error> {
+        debug!("Done with crate");
+        let mut index = (*self.index).clone().into_inner();
+        let trait_items = cache.traits.iter().filter_map(|(id, trait_item)| {


nit: this could be extracted to a function instead of happening directly in after_krate

tmandry · 2020-08-04T01:23:48Z

src/librustdoc/json/types.rs

+    #[serde(rename = "trait")]
+    pub trait_: Option<Type>,
+    #[serde(rename = "for")]
+    pub for_: Type,


I wonder if we'd ever want to create an index of Types so we could de-duplicate them. This could be an open question on the RFC to consider before stabilizing.

In some sense they're already partially de-duplicated because they refer to IDs for the structs/enums/traits instead of containing their definitions. It doesn't seem to me that another level of indirection is worth it in general, but it would be nice for the purpose of easily comparing deeply nested types.

Good point. I think experience will tell if this is worth it or not, but I suspect you're right.

betamos

This CL is great, essentially self-explanatory, thanks to the prior refactor. My comments are mainly minor docstrings and naming. Looking forward to the tests.

src/librustdoc/json/types.rs

betamos · 2020-08-06T06:28:20Z

src/librustdoc/json/types.rs

+
+#[derive(Clone, Debug, Serialize, Deserialize)]
+pub struct Item {
+    /// This can be used as a key to the `external_crates` map of [`Crate`][] to see which crate


Can be? Perhaps just state that the crate_num here corresponds to Crate.id?

Also if not too late, perhaps using crate_id is a better name unless they number and id are different.

src/librustdoc/json/types.rs

betamos · 2020-08-06T06:55:38Z

src/librustdoc/json/types.rs

+
+#[serde(rename_all = "snake_case")]
+#[derive(Clone, Debug, Serialize, Deserialize)]
+pub enum GenericArgs {


Here and below it would be helpful with the same level of docs as in the first part of the file. They are very helpful.

betamos · 2020-08-06T06:57:50Z

src/librustdoc/json/types.rs

+    ResolvedPath {
+        name: String,
+        id: Id,
+        args: Box<Option<GenericArgs>>,


Swap wrapping? Also, curious about the boxing, what's the purpose?

It's purely to satisfy the compiler because otherwise the Type enum is self referential due to GenericArgs containing other types.

betamos · 2020-08-06T07:06:55Z

src/librustdoc/json/types.rs

+    pub blanket_impl: Option<Type>,
+}
+
+// TODO: this is currently broken because imports have the same ID as the module that contains


In what way? Do imports not show up at all, is there a race? Perhaps imports could be omitted until this is resolved?

Yep there was a race. Still working on fixing it, but since re-exports aren't going to be part of the first PR it's not blocking for a little bit.

The comment has since been removed. Is this still relevant?

src/librustdoc/json/conversions.rs

betamos · 2020-08-06T07:12:54Z

src/librustdoc/clean/types.rs

@@ -1405,6 +1405,11 @@ impl Path {
    pub fn last_name(&self) -> &str {
        self.segments.last().expect("segments were empty").name.as_str()
    }
+
+    pub fn whole_name(&self) -> String {


Is this contextually dependent? What's the difference towards a fully qualified path?

Shouldn't be contextually dependent, it is just the fully qualified path.

P1n3appl3 · 2020-08-12T17:34:09Z

src/test/run-make-fulldeps/rustdoc-json/check_missing_items.py

+# local IDs have to be in `index`, external ones can sometimes be in `index` but otherwise have
+# to be in `paths`
+def valid_id(item_id):
+    return item_id in crate["index"] or item_id[0] != "0" and item_id in crate["paths"]


This is really the bare minimum level of testing for the output. We just check that the blob doesn't contain any invalid IDs (ones that aren't present in index or paths. This doesn't handle the case where neither the ID nor the item itself end up in the output, or really anything about the structure of the output itself.

Originally I'd planned to write tests that simply compared the output to a known-good version for some minimal examples, but without writing a fuzzy differ to only look at the fields we care about that turns out to be quite difficult due to the large output size and potentially brittle to small changes in the compiler and stdlib.

jyn514 · 2020-08-14T00:08:10Z

IMO I would rather merge this sooner rather than later and do the cleanup in later PRs. That would let people test things out on nightly - I expect any bugs in the implementation not to have too much impact on the design itself.

@P1n3appl3 the CI failures are saying to change TODO to FIXME: https://github.com/rust-lang/rust/pull/75114/files#diff-94e97fcd5e773cae8edd0781d7bd5411R443 seems like it could be a FIXME but https://github.com/rust-lang/rust/pull/75114/files#diff-94e97fcd5e773cae8edd0781d7bd5411R104 should be implemented before we merge I think.

I'm ok with leaving macros for a follow-up PR.

tmandry · 2020-08-14T03:13:59Z

@GuillaumeGomez ^ what do you think?

GuillaumeGomez · 2020-08-14T08:28:45Z

The code looks good, so I think we're getting close to a merge. However, I agree with @jyn514: please implement https://github.com/rust-lang/rust/pull/75114/files#diff-94e97fcd5e773cae8edd0781d7bd5411R104 before. :)

GuillaumeGomez · 2020-08-14T08:44:43Z

Just thought: we need tests too. Probably a new test suite (I can add that if needed) to be sure that every need PR on this feature won't bring regressions alongside.

bors · 2020-08-24T01:21:31Z

☔ The latest upstream changes (presumably #74489) made this pull request unmergeable. Please resolve the merge conflicts.

jyn514 · 2020-09-01T02:15:49Z

To avoid having this perpetually in limbo, can we delay the test suite until stabilization? The best test suite will be people using it ;) and it's going to be at least as much work as this PR if not more.

@P1n3appl3 FYI @nmccarty has volunteered to finish up the implementation on this PR if you're busy with work/school/life.

src/test/run-make-fulldeps/rustdoc-json/compare.py

P1n3appl3 · 2020-09-01T02:42:58Z

Sorry I should have updated here: I've been on vacation visiting family for the past 2 weeks and was mostly offline but I've got some time now before school ramps up so I'm planning to finish/fix up the implementation.

@robinkrahl has been testing out the backend in its current state and has found several bugs that I'm still working on (doc-hidden wasn't being respected, and there are issues where serde incorrectly deserializes fields due to using untagged enums). There are some smaller things that I can just open issues for once this is merged, but I want to get the big ones fixed so it's usable on release.

I also have been trying to write up tests and I agree that it's best left for another PR (especially given the size of this one already). I would love some help from @nmccarty on coming up with those as well as fixing the known bugs. I'm "Pineapple" on the rust discord or just email me and I can show you the remaining TODOs.

GuillaumeGomez · 2020-09-01T08:22:09Z

To avoid having this perpetually in limbo, can we delay the test suite until stabilization?

I don't ask for an extensive list of tests, just at least one. Always useful to at least avoid regressions. Then more will be added once new bugs are fixed and so on.

tmandry · 2020-10-14T01:27:08Z

The code in this PR has several tests and I think it's fine to merge as-is, once conflicts are resolved and failing tests are fixed.

@GuillaumeGomez What do you think?

@P1n3appl3 I think this is basically done. Are you able to push this over the finish line? I'd also be happy to rebase and fix it up.

P1n3appl3 · 2020-10-14T06:08:16Z

Yup @jyn514 already offered to help clean up some WIP bugfixes and minor changes that I haven't pushed yet so he can do the rebase i think. After that it should be good to merge.

jyn514 · 2020-10-14T22:26:18Z

src/librustdoc/json/types.rs

+    /// Whether this item is meant to be omitted from the generated documentation due to `#doc(hidden)`,
+    /// because it is private, or because it was inlined.
+    pub stripped: bool,


I still prefer to omit stripped items altogether. I won't block on it because I really want to see this in nightly 😆 but it should be removed before stabilization; rustdoc should not have a stable way to introspect private items from other crates.

--document-private-items is really useful for generating internal docs, and I think this feature should support it, even though it technically provides a way to do what you say.

If you pass --document-private-items, the items won't be stripped (and in fact you'll lose the ability to distinguish between private and public items). This is more like 'unconditionally document private items'.

jyn514 · 2020-10-15T00:30:40Z

 Traceback (most recent call last):
  File "compare.py", line 106, in <module>
    main(sys.argv[1], sys.argv[2])
  File "compare.py", line 98, in main
    check_subset(expected_main, actual_main)
  File "compare.py", line 65, in check_subset
    _check_subset(expected_main["root"], actual_main["root"], [])
  File "compare.py", line 62, in _check_subset
    _check_subset(expected_index.get(expected, {}), actual_index.get(actual, {}), trace)
  File "compare.py", line 46, in _check_subset
    new_trace = trace.copy()
AttributeError: 'list' object has no attribute 'copy'

jyn514 · 2020-10-15T00:31:07Z

I think you want copy.deepcopy(trace).

src/librustdoc/json/mod.rs

removing them creates dangling references

This way it doesn't have to build rustc twice. Eventually it should probably get its own suite, like rustdoc-js, but that can be fixed in a follow-up.

jyn514 · 2020-11-08T19:47:54Z

src/librustdoc/clean/types.rs

+            | PrimitiveItem(_)
+            | AssocConstItem(_, _)
+            | AssocTypeItem(_, _)
+            | StrippedItem(_)


I don't think this is correct? StrippedItem always has an inner item: https://doc.rust-lang.org/nightly/nightly-rustc/rustdoc/clean/types/enum.ItemEnum.html#variant.StrippedItem

src/librustdoc/json/conversions.rs

jyn514 · 2020-11-08T19:50:31Z

src/librustdoc/json/conversions.rs

+    fn from(deprecation: clean::Deprecation) -> Self {
+        Deprecation { since: deprecation.since, note: deprecation.note }
+    }


Let's make this exhaustive to avoid missing new fields.

Suggested change

fn from(deprecation: clean::Deprecation) -> Self {

Deprecation { since: deprecation.since, note: deprecation.note }

}

fn from(deprecation: clean::Deprecation) -> Self {

let clean::Deprecation { since, note } = deprecation;

Deprecation { since, note }

}

jyn514 · 2020-11-08T19:51:35Z

src/librustdoc/json/conversions.rs

+            Inherited => Visibility::Default,
+            Crate => Visibility::Crate,
+            Restricted(did, path) => {
+                Visibility::Restricted { parent: did.into(), path: path.whole_name() }


Does this need to have both the path and the ID? I think the path can be looked up by the id.

jyn514 · 2020-11-08T20:02:41Z

src/librustdoc/json/types.rs

+    /// For the most part items are private by default. The exceptions are associated items of
+    /// public traits and variants of public enums.
+    Default,
+    Crate,


Does pub(crate) need to be treated specially? It's the same as pub(in crate), i.e. a restricted path.

jyn514 · 2020-11-08T20:04:58Z

src/librustdoc/json/types.rs

+    pub blanket_impl: Option<Type>,
+}
+
+// TODO: this is currently broken because imports have the same ID as the module that contains


The comment has since been removed. Is this still relevant?

This fully halves the size of the emitted JSON.

jyn514

Is it ok if I change some of the output to differ from the eRFC? Some of this info really shouldn't be duplicated.

jyn514 · 2020-11-08T20:06:47Z

src/librustdoc/clean/mod.rs

@@ -2314,7 +2314,7 @@ impl Clean<Vec<Item>> for doctree::Import<'_> {
            name: None,
            attrs: self.attrs.clean(cx),
            source: self.span.clean(cx),
-            def_id: DefId::local(CRATE_DEF_INDEX),
+            def_id: cx.tcx.hir().local_def_id(self.id).to_def_id(),


Why did this change?

jyn514 · 2020-11-08T20:09:51Z

src/librustdoc/json/conversions.rs

+impl From<clean::Struct> for Struct {
+    fn from(struct_: clean::Struct) -> Self {
+        let clean::Struct { struct_type, generics, fields, fields_stripped } = struct_;
+        Struct {
+            struct_type: struct_type.into(),
+            generics: generics.into(),
+            fields_stripped,
+            fields: fields.into_iter().map(|i| i.def_id.into()).collect(),
+            impls: Vec::new(), // Added in JsonRenderer::item
+        }
+    }
+}
+
+impl From<clean::Union> for Struct {
+    fn from(struct_: clean::Union) -> Self {
+        let clean::Union { struct_type, generics, fields, fields_stripped } = struct_;
+        Struct {
+            struct_type: struct_type.into(),
+            generics: generics.into(),
+            fields_stripped,
+            fields: fields.into_iter().map(|i| i.def_id.into()).collect(),
+            impls: Vec::new(), // Added in JsonRenderer::item
+        }
+    }
+}


These impls are exactly the same, which means that the JSON output doesn't distinguish between structs and unions. Is that intentional?

jyn514 · 2020-11-08T20:21:23Z

src/librustdoc/json/mod.rs

+                .iter()
+                .map(|(k, v)| {
+                    (
+                        k.as_u32(),


Having numeric keys seems annoying. Would it make more sense to instead have a list that you look up by index?

Concretely, currently the output looks like this:

{ "1": { "name": "std", "html_root_url": "https://doc.rust-lang.org/nightly/" }, "2": { "name": "core", "html_root_url": "https://doc.rust-lang.org/nightly/" }, ... }

and I'd prefer it to look like

[ { "name": "std", "html_root_url": "https://doc.rust-lang.org/nightly/" }, { "name": "core", "html_root_url": "https://doc.rust-lang.org/nightly/" } ... ]

src/librustdoc/json/mod.rs

jyn514 · 2020-11-08T20:23:03Z

src/librustdoc/json/mod.rs

+        let mut index = (*self.index).clone().into_inner();
+        index.extend(self.get_trait_items(cache));
+        let output = types::Crate {
+            root: types::Id(String::from("0:0")),


What is the point of this field?

jyn514 · 2020-11-08T20:23:39Z

src/librustdoc/json/conversions.rs

+            },
+            source: source.into(),
+            visibility: visibility.into(),
+            docs: attrs.collapsed_doc_value().unwrap_or_default(),


Should this instead be null if there are no docs?

jyn514 · 2020-11-08T20:31:11Z

src/librustdoc/json/mod.rs

+        let output = types::Crate {
+            root: types::Id(String::from("0:0")),
+            version: krate.version.clone(),
+            includes_private: cache.document_private,


Does this need to be included? The user will know if they passed --document-private-items.

jyn514 · 2020-11-08T20:41:01Z

src/librustdoc/json/mod.rs

+pub struct JsonRenderer {
+    /// A mapping of IDs that contains all local items for this crate which gets output as a top
+    /// level field of the JSON blob.
+    index: Rc<RefCell<FxHashMap<types::Id, types::Item>>>,


Making this a map makes it annoying to work with, and introduces duplicate information: now the ID is both a key and a field on the object. Instead, I think it makes sense to make it an array, and you have to look up the id in the object if you want it.

jyn514 · 2020-11-08T20:41:53Z

src/librustdoc/json/types.rs

+}
+
+#[derive(Clone, Debug, PartialEq, Eq, Hash, Serialize, Deserialize)]
+pub struct Id(pub String);


Currently this contains both the crate number and the item id. But the crate number is already part of Item. Do we need both? The Id is used to globally identify the item, so I think a better idea is to use a { crate_number, id } object, then remove the crate number from Item.

jyn514 · 2020-11-08T20:47:52Z

Also, it might be better to name this crate_version to avoid confusing with format_version.

Doesn't need to be fixed here, but 'source' is ambiguous, it could also be the code itself. I would rather call it span, like rustc (and I'd like to make the same change in rustdoc).

I've implemented these changes.

jyn514 · 2020-11-08T21:04:13Z

src/librustdoc/json/mod.rs

+                            docs: Default::default(),
+                            links: Default::default(),
+                            attrs: Default::default(),
+                            deprecation: Default::default(),


This doesn't look right: it shows Drop as having no docs at all.

jyn514 · 2020-11-08T23:41:52Z

It turns out that I broke the tests by moving them to rustdoc/, because now the makefile is being ignored and it just compiles structs.rs successfully instead of ever running the JSON backend. Rather than move them back to run-make-fulldeps, I think it makes more sense to have a full src/test/rustdoc-json folder which allows only building stage1 and not having to add rustdoc support to run-make.

bors · 2020-11-15T15:44:30Z

☔ The latest upstream changes (presumably #79070) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

jyn514 · 2020-11-30T22:52:04Z

Closing this in favor of #79539; I still want to address the points I brought up, but we can do that after the initial impl lands on nightly.

…illaumeGomez Rustdoc: JSON backend experimental impl, with new tests. Based on rust-lang#75114 by `@P1n3appl3` The first commit is all of rust-lang#75114, but squased to 1 commit, as that was much easier to rebase onto master. The git history is a mess, but I think I'll edit it after review, so it's obvious whats new. ## Still to do - [ ] Update docs. - [ ] Add bless option to tests. - [ ] Add test option for multiple files in same crate. - [ ] Decide if the tests should check for json to be equal or subset. - [ ] Go through the rest of the review for the original pr. (This is open because the test system is done(ish), but stuff like [not using a hashmap](rust-lang#75114 (comment)) and [using `CRATE_DEF_INDEX` ](rust-lang#75114 (comment)) hasn't) I'm also sure how many of these we need to do before landing on nightly, as it would be nice to get this in tree, so it isn't effected by churn like rust-lang#79125, rust-lang#79041, rust-lang#79061 r? `@jyn514`

Rustdoc: JSON backend experimental impl, with new tests. Based on rust-lang#75114 by `@P1n3appl3` The first commit is all of rust-lang#75114, but squased to 1 commit, as that was much easier to rebase onto master. The git history is a mess, but I think I'll edit it after review, so it's obvious whats new. ## Still to do - [ ] Update docs. - [ ] Add bless option to tests. - [ ] Add test option for multiple files in same crate. - [ ] Decide if the tests should check for json to be equal or subset. - [ ] Go through the rest of the review for the original pr. (This is open because the test system is done(ish), but stuff like [not using a hashmap](rust-lang#75114 (comment)) and [using `CRATE_DEF_INDEX` ](rust-lang#75114 (comment)) hasn't) I'm also sure how many of these we need to do before landing on nightly, as it would be nice to get this in tree, so it isn't effected by churn like rust-lang#79125, rust-lang#79041, rust-lang#79061 r? `@jyn514`

aDotInTheVoid · 2021-03-01T14:46:41Z

@rustbot modify labels: +A-rustdoc-json

rust-highfive assigned GuillaumeGomez Aug 3, 2020

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 3, 2020

ollie27 added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Aug 3, 2020

tmandry reviewed Aug 4, 2020

View reviewed changes

betamos reviewed Aug 6, 2020

View reviewed changes

jyn514 mentioned this pull request Aug 10, 2020

eRFC: Add JSON backend to Rustdoc rust-lang/rfcs#2963

Merged

P1n3appl3 commented Aug 12, 2020

View reviewed changes

P1n3appl3 force-pushed the json-mvp branch from e21e10a to 867ac8d Compare August 14, 2020 11:10

jyn514 reviewed Sep 1, 2020

View reviewed changes

src/test/run-make-fulldeps/rustdoc-json/compare.py Outdated Show resolved Hide resolved

jyn514 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 15, 2020

This was referenced Sep 19, 2020

Add type definitions for rustdoc JSON backend #76900

Closed

Tracking issue for RFC 2963: rustdoc JSON backend #76578

Open

jyn514 reviewed Oct 14, 2020

View reviewed changes

P1n3appl3 force-pushed the json-mvp branch from 5443fd1 to aea6226 Compare October 14, 2020 23:57

jyn514 reviewed Oct 15, 2020

View reviewed changes

src/librustdoc/json/mod.rs Outdated Show resolved Hide resolved

Add json backend

ac408e4

P1n3appl3 added 2 commits November 8, 2020 14:25

Mark stripped items

5ff33ca

removing them creates dangling references

Fix tests and update conversions

d99ec1d

jyn514 force-pushed the json-mvp branch from aea6226 to 8b75a27 Compare November 8, 2020 19:38

jyn514 added 2 commits November 8, 2020 14:52

Don't panic if JSON backend fails to create a file

9ca0856

Fix attribute error in JSON testsuite

99d4784

jyn514 force-pushed the json-mvp branch from 8b75a27 to 99d4784 Compare November 8, 2020 19:53

Move rustdoc-json to rustdoc/

a66a97a

This way it doesn't have to build rustc twice. Eventually it should probably get its own suite, like rustdoc-js, but that can be fixed in a follow-up.

jyn514 reviewed Nov 8, 2020

View reviewed changes

jyn514 added 3 commits November 8, 2020 15:14

Small cleanups

338acee

Don't prettify json before printing

47acf9a

This fully halves the size of the emitted JSON.

Add comments

cc85375

jyn514 reviewed Nov 8, 2020

View reviewed changes

[BREAKING CHANGE] rename version -> crate_version

9147fd7

jyn514 reviewed Nov 8, 2020

View reviewed changes

[BREAKING CHANGE] rename source -> span

463e8b8

jyn514 reviewed Nov 8, 2020

View reviewed changes

jyn514 added 2 commits November 8, 2020 16:05

Use exhaustive matches

ec7a660

Don't qualify imports for DefId

7ad40b5

jyn514 mentioned this pull request Nov 18, 2020

Better handling of relative links webern/cargo-readme#18

Open

aDotInTheVoid mentioned this pull request Nov 29, 2020

Rustdoc: JSON backend experimental impl, with new tests. #79539

Merged

5 tasks

jyn514 closed this Nov 30, 2020

rustbot added the A-rustdoc-json Area: Rustdoc JSON backend label Mar 1, 2021

JSON backend experimental impl #75114

JSON backend experimental impl #75114

Conversation

P1n3appl3 commented Aug 3, 2020

rust-highfive commented Aug 3, 2020

tmandry left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

betamos left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jyn514 commented Aug 14, 2020

tmandry commented Aug 14, 2020

GuillaumeGomez commented Aug 14, 2020

GuillaumeGomez commented Aug 14, 2020

bors commented Aug 24, 2020

jyn514 commented Sep 1, 2020 • edited Loading

P1n3appl3 commented Sep 1, 2020

GuillaumeGomez commented Sep 1, 2020

tmandry commented Oct 14, 2020

P1n3appl3 commented Oct 14, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jyn514 commented Oct 15, 2020

jyn514 commented Oct 15, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jyn514 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jyn514 commented Nov 8, 2020 • edited Loading

Choose a reason for hiding this comment

jyn514 commented Nov 8, 2020

bors commented Nov 15, 2020

jyn514 commented Nov 30, 2020

aDotInTheVoid commented Mar 1, 2021

jyn514 commented Sep 1, 2020 •

edited

Loading

P1n3appl3 commented Oct 14, 2020 •

edited

Loading

jyn514 commented Nov 8, 2020 •

edited

Loading