`unreachable-pub` lint (as authorized by RFC 2126)
To whom it may concern:
RFC 2126 commissions the creation of a lint for `pub` items that are not visible from crate root (#45521). We understand (but seek confirmation from more knowledgable compiler elders) that this can be implemented by linting HIR items that are _not_ ~~`cx.access_levels.is_exported`~~ `cx.access_levels.is_reachable` but have a `vis` (-ibility) field of `hir::Visibility::Public`.
The lint, tentatively called ~~`unexported-pub`~~ `unreachable-pub` (with the understanding that much could be written on the merits of various names, as it is said of the colors of bicycle-sheds), suggests `crate` as a replacement for `pub` if the `crate_visibility_modifier` feature is enabled (see #45388), and `pub(crate)` otherwise. We also use help messaging to suggest the other potential fix of exporting the item; feedback is desired as to whether this may be confusing or could be worded better.
As a preview of what respecting the proposed lint would look like (and to generate confirmatory evidence that this implementation doesn't issue false positives), ~~we take its suggestions for `libcore`~~ (save one, which is deferred to another pull request because it brings up an unrelated technical matter). I remain your obedient servant.
r? @petrochenkov
ci: Fix broken link in `build-powerpc64le-toolchain.sh`
r? @rust-lang/infra
This is just an emergency fix to keep bors running for another week. I think the numbers will be broken soon. Can we verify if this statement is still true later?
> First, download the CentOS7 glibc.ppc64le and relevant header files.
> (upstream ppc64le support wasn't added until 2.19, which el7 backported.)
typeck: suggest use of match_default_bindings feature
Fixes#45383.
Updates #42640.
r? @nikomatsakis
cc @tschottdorf
This needs a UI test, but thought I'd get some early feedback.
Improve display of error E0308
Ref. Forgetting to call a variant constructor causes a confusing error message #35241.
This PR modifies [`note_type_err`](b7041bfab3/src/librustc/infer/error_reporting/mod.rs (L669-L674)) to display a `help` message when a `TyFnPtr` or `TyFnDef` are found and the return type, of the function or function pointer, is the same as the type that is expected.
The output of compiling
```rust
struct Foo(u32);
fn test() -> Foo { Foo }
fn main() {}
```
is now
```bash
$ rustc src/test/ui/issue-35241.rs
error[E0308]: mismatched types
--> src/test/ui/issue-35241.rs:13:20
|
13 | fn test() -> Foo { Foo }
| --- ^^^ expected struct `Foo`, found fn item
| |
| expected `Foo` because of return type
|
= help: did you mean `Foo { /* fields */ }`?
= note: expected type `Foo`
found type `fn(u32) -> Foo {Foo::{{constructor}}}`
error: aborting due to previous error
```
Bring back slice::ref_slice as slice::from_ref.
These functions were deprecated and removed in 1.5, but such simple
functionality shouldn't require using unsafe code, and it isn't
cluttering libstd too much.
The original removal was quite contentious (see #27774), since then
we've had precedent for including such nuggets of functionality (see rust-lang/rfcs#1789),
and @nikomatsakis has provided a lot of use cases in https://github.com/rust-lang/rfcs/pull/1789#issuecomment-314640034.
Hence this PR.
I'm not too sure what to do with stability, feel free to correct me.
It seems pointless to go through stabilization for these functions though.
cc @aturon
