The compiler gets hopelessly confused on `enum S(usize);`

[jyn514]

I think the error speaks for itself.

Here is the change I made, applied to 025f0e649e3a9869e42148ee8cf3041e24a13e8c.

diff --git a/src/librustdoc/clean/types.rs b/src/librustdoc/clean/types.rs
index 26b630440a1..4c2f3b5ce43 100644
--- a/src/librustdoc/clean/types.rs
+++ b/src/librustdoc/clean/types.rs
@@ -1163,33 +1163,7 @@ fn def_id(&self) -> Option<DefId> {
 }
 
 #[derive(Clone, PartialEq, Eq, Hash, Copy, Debug)]
-crate enum PrimitiveType {
-    Isize,
-    I8,
-    I16,
-    I32,
-    I64,
-    I128,
-    Usize,
-    U8,
-    U16,
-    U32,
-    U64,
-    U128,
-    F32,
-    F64,
-    Char,
-    Bool,
-    Str,
-    Slice,
-    Array,
-    Tuple,
-    Unit,
-    RawPointer,
-    Reference,
-    Fn,
-    Never,
-}
+crate enum PrimitiveType(Symbol);
 
 #[derive(Clone, PartialEq, Eq, Hash, Copy, Debug)]
 crate enum TypeKind {

errors.log edit: this is the wrong logfile, see below

I think the main thing making this so awful (1429 errors) is that it continues to try and do name resolution afterwards. I would not expect any errors other than further syntax errors to be reported.

[jyn514]

Oh wait what, that's only 126 errors :( I'm not sure what changed between seeing them and opening the issue.

[jyn514]

I think most of these are actually reasonable errors coming from deleting the enum variants. Not sure why it had so many the first time, it has 126 consistently now :/

[jyn514]

Oh, I applied the wrong diff - that was with crate struct instead of crate enum. So that's good actually, it gives a baseline: I would not expect this to give more than 130 errors or so. Here is the full log from using crate enum instead:
enum-errors.log

[estebank]

I believe the underlying ask here is to silence resolve errors if they reference modules that have had parse errors. The easiest way to accomplish that would be something like #116904.

CC #74863.

[estebank]

#133937 will mitigate this case, but I don't think it will propagate the "this mod failed to parse" bit through re-exports, which the original issue was a case of.

[estebank]

After looking at this again with fresh eyes, I suspect this might be able to be closed after #133937 (I'm unable to find a case where these kind of errors wouldn't be caught by it).

[estebank]

The current output for that change in the codebase is much shorter, but still too verbose IMO at ~1k lines (better than the ~17k lines from the report).

errors.log

We don't propagate a signal that a module is re-exporting symbols from a module that had a parse error.