This commit fixes a bug where a crate could fail to compile depending on the
order of `extern crate` directives at the top of the crate. Specifically, if the
same crate is found at two locations, then if it's loaded first via `--extern`
it will not emit a duplicate warning, but if it's first loaded transitively
via a dep and *then* via `--extern` an error will be emitted.
The loader was tweaked to catch this scenario and coalesce the loading of these
two crates to prevent errors from being emitted.
This commit fixes a bug where a crate could fail to compile depending on the
order of `extern crate` directives at the top of the crate. Specifically, if the
same crate is found at two locations, then if it's loaded first via `--extern`
it will not emit a duplicate warning, but if it's first loaded transitively
via a dep and *then* via `--extern` an error will be emitted.
The loader was tweaked to catch this scenario and coalesce the loading of these
two crates to prevent errors from being emitted.
This patch implements the plan described in https://internals.rust-lang.org/t/privacy-and-its-interaction-with-docs-lints-and-stability/2880 with one deviation.
It turns out, that rustdoc needs the "directly public" set for its docs inlining logic, so the privacy pass have to produce three sets and not two. Three is arguably too many, so I merged them in one map:
`public_items/exported_items/reachable_items: NodeSet => access_levels: NodeMap<AccessLevel>`
r? @alexcrichton
What this patch does:
- Stability annotations are now based on "exported items" supplied by rustc_privacy and not "public items". Exported items are as accessible for external crates as directly public items and should be annotated with stability attributes.
- Trait impls require annotations now.
- Reexports require annotations now.
- Crates themselves didn't require annotations, now they do.
- Exported macros are annotated now, but these annotations are not used yet.
- Some useless annotations are detected and result in errors
- Finally, some small bugs are fixed - deprecation propagates from stable deprecated parents, items in blocks are traversed correctly (fixes https://github.com/rust-lang/rust/issues/29034) + some code cleanup.
the const evaluator has a bool constant value, no need to use integers
the `fromb` function is very old. It took me a while of git-blame until i found where it was created. I think it was just a hack. All tests still pass.
I also forbade `&&` and `||` on integral types
[breaking change]
I'm not sure if those renames are ok. [TokenType::Tt* to TokenType::*](https://github.com/rust-lang/rust/pull/29582) was obvious, but for all those Item-enums it's less obvious to me what the right way forward is due to the underscore.
f357d55 caused a regression by retrieving item names from metadata, while previously using the last element of its absolute path (which in the case of a root module is the prefixed crate name since the stored path in metadata is empty)
fixes#28927
* Delete `sys::unix::{c, sync}` as these are now all folded into libc itself
* Update all references to use `libc` as a result.
* Update all references to the new flat namespace.
* Moves all windows bindings into sys::c
Allow the changing of `target_family` through flexible configuration. The whole computing world isn't just a binary of *nix and Windows! Makes porting `libstd` and co to new platforms a lot less painful.
Handle them in `middle::reachable` instead (no optimizations so far, just drop all trait impl items into the reachable set, as before). Addresses the concerns from https://github.com/rust-lang/rust/pull/29291#discussion_r43672413
\+ In `middle::reachable` don't treat impls of `Drop` specially, they are subsumed by the general impl treatment.
\+ Add some tests checking reachability of trait methods written in UFCS form
\+ Minor refactoring in the second commit
r? @alexcrichton
Introduce a `SwitchInt` and restructure pattern matching to collect integers and characters into one master switch. This is aimed at #29227, but is not a complete fix. Whereas before we generated an if-else-if chain and, at least on my machine, just failed to compile, we now spend ~9sec compiling `rustc_abuse`. AFAICT this is basically just due to a need for more micro-optimization of the matching process: perf shows a fair amount of time just spent iterating over the candidate list. Still, it seemed worth opening a PR with this step alone, since it's a big step forward.
