Tweaks to invalid ctor messages
- Do not suggest using a constructor that isn't accessible
- Suggest the appropriate syntax (`()`/`{}` as appropriate)
- Add note when trying to use `Self` as a ctor
CC #22488, fix#47085.
check_match: fix handling of privately uninhabited types
the match-checking code used to use TyErr for signaling "unknown,
inhabited" types for a long time. It had been switched to using the
exact type in #38069, to handle uninhabited types.
However, in #39980, we discovered that we still needed the "unknown
inhabited" logic, but I used `()` instead of `TyErr` to handle that.
Revert to using `TyErr` to fix that problem.
Fixes#46964.
r? @nikomatsakis
remove bogus assertion and comments
The code (incorrectly) assumed that constants could not have generics
in scope, but it's not really a problem if they do.
Fixes#47153
r? @pnkfelix
Closure argument mismatch tweaks
- use consistent phrasing for expected and found arguments
- suggest changing arguments to tuple if possible
- suggest changing single tuple argument to arguments if possible
Fix#44150.
Give TargetOptions::linker a sane default value for CloudABI.
Though some parts of rust use cc-rs to invoke a compiler/linker, Cargo
seems to make use of the TargetOptions::linker property. Make the out of
the box experience for CloudABI a bit better by using the same compiler
name as cc-rs.
Fix the "Github - About Pull Requests" link in CONTRIBUTING.md
Previously the text that is supposed to link to the Github Pull Requests page, instead linked to the same file (CONTRIBUTING.md).
add target/ to ignored tidy dirs
Sometimes you get a target directory from running cargo in the rust repo (the root is `src/`), and it contains generated files. Just whitelist it since it causes tidy to spew warnings uncontrollably.
add Rust By Example to the bookshelf
cc #46194
With #46196 freshly merged, we should add a link to the main docs distribution so people can find it! We discussed this at the docs team meeting today and decided to go ahead with adding it to the bookshelf.
Add transpose conversions for nested Option and Result
These impls are useful when working with combinator
methods that expect an option or a result, but you
have a `Result<Option<T>, E>` instead of an `Option<Result<T, E>>`
or vice versa.
add kbd style tag to main.css in rustdoc
Added css style for kbd tags so they actually look like keys.
Result preview and discussion was going on in #46900 .
It is currently allowed to perform such assignments when not making use
of NLL. NLL already does this right, but let's add a test in place to
ensure it never regresses.
Rename std::ptr::Shared to NonNull and stabilize it
This implements the changes proposed at https://github.com/rust-lang/rust/issues/27730#issuecomment-352800629:
> * Rename `Shared<T>` to `NonNull<T>` and stabilize it. (Being in the `ptr` module is enough to say that it’s a pointer. I’m not very attached to this specific name though.)
> * Rename `Box<T>` methods ~~`from_unique`~~/`into_unique` to ~~`from_nonnull`~~/`into_nonnull` (or whatever names are deemed appropriate), replace `Unique<T>` with `NonNull<T>` in their signatures, and stabilize them.
> * Replace `Unique<T>` with `NonNull<T>` in the signatures of methods of the `Alloc` trait.
> * Mark `Unique` “permanently-unstable” by replacing remaining occurrences of `#[unstable(feature = "unique", issue = "27730")]` with:
>
> ```rust
> #[unstable(feature = "ptr_internals", issue = "0", reason = "\
> use NonNull instead and consider PhantomData<T> (if you also use #[may_dangle]), \
> Send, and/or Sync")]
> ```
>
> (Maybe the `reason` string is only useful on the struct definition.) Ideally it would be made private to some crate instead, but it needs to be used in both liballoc and libstd.
> * (Leave `NonZero` and `Zeroable` unstable for now, and subject to future bikeshedding.)
Thew `_raw` prefix is included because the fact that `Box`’s ownership
semantics are "dissolved" or recreated seem more important than the exact
parameter type or return type.
- use consistent phrasing for expected and found arguments
- suggest changing arugments to tuple if possible
- suggest changing single tuple argument to arguments if possible
LLVM <= 4.0 used a non-standard interpretation of `DW_OP_plus`. In the
DWARF standard, this adds two items on the expressions stack. LLVM's
behavior was more like DWARF's `DW_OP_plus_uconst` -- adding a constant
that follows the op. The patch series starting with [D33892] switched
to the standard DWARF interpretation, so we need to follow.
[D33892]: https://reviews.llvm.org/D33892
