The public set is expanded with trait items, impls and their items, foreign items, exported macros, variant fields, i.e. all the missing parts. Now it's a subset of the exported set.
This is needed for https://github.com/rust-lang/rust/pull/29083 because stability annotation pass uses the public set and all things listed above need to be annotated.
Rustdoc can now be migrated to the public set as well, I guess.
Exported set is now slightly more correct with regard to exported items in blocks - 1) blocks in foreign items are considered and 2) publicity is not inherited from the block's parent - if a function is public it doesn't mean structures defined in its body are public.
r? @alexcrichton or maybe someone else
These commits revert https://github.com/rust-lang/rust/pull/28504 and add a regression test pointed out by @petrochenkov, it's not immediately clear with the regression that the accessibility check should be removed, so for now preserve the behavior on stable by default.
r? @nrc
were returned, either the trait or the *self type itself*, were not
particularly representative of what the Def is (a type parameter).
Rewrite paths to handle this case specially, just as they handle the
primitive case specifically. This entire `def_id` codepath is kind of a
mess.
this simplifies the code while reducing the size of libcore.rlib by
3.3 MiB (~1M of which is bloat a separate patch of mine removes
too), while reducing rustc memory usage on small crates by 18MiB.
This also simplifies the code considerably.
Part of https://github.com/rust-lang/rust/issues/6993
This patch replaces `Ident`s with `Name`s in data structures of HIR and updates the dependent crates to compile and pass `make check`.
Some HIR structures still use `Ident`s, namely `PathSegment`, `PatIdent`, `ExprWhile`, `ExprLoop`, `ExprBreak` and `ExprAgain`, they need them for resolve (but `PathSegment` is special, see https://github.com/rust-lang/rust/issues/6993#issuecomment-141256292).
r? @nrc
Fixes#16264 / #18241.
As far as I can tell, it should be impossible for a trait to be inaccessible if it's in scope, so this check is unnecessary. Are there any cases where this check is actually needed?
