Add basic checks for well-formedness of `fn`/`fn_mut` lang items
This pull request fixes#83471. Lang items are never actually checked for well-formedness (#9307). This means that one can get an ICE quite easily, e.g. as follows:
```rust
#![feature(lang_items)]
#[lang = "fn"]
trait MyFn {
const call: i32 = 42;
}
fn main() {
(|| 42)();
}
```
or this:
```rust
#![feature(lang_items)]
#[lang = "fn"]
trait MyFn {
fn call(i: i32, j: i32);
}
fn main() {
(|| 42)();
}
```
Ideally, there should probably be a more comprehensive strategy for checking lang items for well-formedness, but for the time being, I have added some rudimentary well-formedness checks that prevent #83471 and similar issues.
Enable "generate-link-to-definition" option on rust tools docs as well
Just realized that we enable the option for the compiler crates, but we don't have it for rustdoc and the other tools documentation...
Part of https://github.com/rust-lang/rust/issues/89095.
cc ``@rust-lang/rustdoc``
r? ``@Mark-Simulacrum``
Add missing time complexities to linked_list.rs
Most functions in LinkedList have time complexities in their description:
Like push front:
```
Adds an element first in the list.
This operation should compute in O(1) time.
```
Time complexities were missing for the following, so I've added them in this PR:
contains: O(n)
front: O(1)
front_mut: O(1)
back: O(1)
back_mut: O(1)
[rfc 2229] Drop fully captured upvars in the same order as the regular drop code
Currently, with the new 2021 edition, if a closure captures all of the
fields of an upvar, we'll drop those fields in the order they are used
within the closure instead of the normal drop order (the definition
order of the fields in the type).
This changes that so we sort the captured fields by the definition order
which causes them to drop in that same order as well.
Fixesrust-lang/project-rfc-2229#42
r? `@nikomatsakis`
Avoid a couple of Symbol::as_str calls in cg_llvm
This should improve performance a tiny bit. Also remove `Symbol::len` and make `SymbolIndex` private.
Be explicit about using Binder::dummy
This is somewhat of a late followup to the binder refactor PR. It removes `ToPredicate` and `ToPolyTraitImpls` that hide the use of `Binder::dummy`. While this does make code a bit more verbose, it allows us be more careful about where we create binders.
Another alternative here might be to add a new trait `ToBinder` or something with a `dummy()` fn. Which could still allow grepping but allows doing something like `trait_ref.dummy()` (but I also wonder if longer-term, it would be better to be even more explicit with a `bind_with_vars(ty::List::empty())` *but* that's not clear yet.
r? ``@nikomatsakis``
Add 1.56.0 release notes
Notable things:
* Rustdoc section currently absent, for lack of things to call out that I could find. It seems like https://github.com/rust-lang/rust/pull/87451 is the only potential candidate, but that seems like more of a bugfix and doesn't seem to warrant inclusion to me. But we can add it if desired.
As with the 1.55.0 release notes, my intent is to leave this open for approximately 1-2 weeks at the early part of the cycle, and then merge it in (after fixing any feedback). Further iteration can happen in subsequent issues (and PRs).
[Rendered](https://github.com/Mark-Simulacrum/rust/blob/relnotes/RELEASES.md)
The `Option<Module>` version is supported for the case where we don't know whether the `DefId` refers to a module or not.
Non-local traits and enums are also correctly found now.
Make `Duration` respect `width` when formatting using `Debug`
When printing or writing a `std::time::Duration` using `Debug` formatting, it previously completely ignored any specified `width`. This is unlike types like integers and floats, which do pad to `width`, for both `Display` and `Debug`, though not all types consider `width` in their `Debug` output (see e.g. #30164). Curiously, `Duration`'s `Debug` formatting *did* consider `precision`.
This PR makes `Duration` pad to `width` just like integers and floats, so that
```rust
format!("|{:8?}|", Duration::from_millis(1234))
```
returns
```
|1.234s |
```
Before you ask "who formats `Debug` output?", note that `Duration` doesn't actually implement `Display`, so `Debug` is currently the only way to format `Duration`s. I think that's wrong, and `Duration` should get a `Display` implementation, but in the meantime there's no harm in making the `Debug` formatting respect `width` rather than ignore it.
I chose the default alignment to be left-aligned. The general rule Rust uses is: numeric types are right-aligned by default, non-numeric types left-aligned. It wasn't clear to me whether `Duration` is a numeric type or not. The fact that a formatted `Duration` can end with suffixes of variable length (`"s"`, `"ms"`, `"µs"`, etc.) made me lean towards left-alignment, but it would be trivial to change it.
Fixes issue #88059.
Temporarily rename int_roundings functions to avoid conflicts
These functions are unstable, but because they're inherent they still
introduce conflicts with stable trait functions in crates. Temporarily
rename them to fix these conflicts, until we can resolve those conflicts
in a better way.
Run `no_core` rustdoc tests only on Linux
I don't think this is really worth investigating further so I just disabled them.
They currently fail like this:
```
error: linking with `cc` failed: exit status: 1
|
= note: "cc" "-Wl,-exported_symbols_list,/var/folders/pg/gjhzdz7n361f0pv665d0723w0000gn/T/rustcPUsMpx/list" "-arch" "arm64" "/Users/hans/dev/rust/build/aarch64-apple-darwin/test/rustdoc/intra-doc/prim-methods-external-core/auxiliary/my-core.my_core.9f3c60de-cgu.0.rcgu.o" "/Users/hans/dev/rust/build/aarch64-apple-darwin/test/rustdoc/intra-doc/prim-methods-external-core/auxiliary/my-core.50fu2g9urkmisdsg.rcgu.o" "-L" "/Users/hans/dev/rust/build/aarch64-apple-darwin/native/rust-test-helpers" "-L" "/Users/hans/dev/rust/build/aarch64-apple-darwin/test/rustdoc/intra-doc/prim-methods-external-core/auxiliary" "-L" "/Users/hans/dev/rust/build/aarch64-apple-darwin/stage1/lib/rustlib/aarch64-apple-darwin/lib" "-L" "/Users/hans/dev/rust/build/aarch64-apple-darwin/stage1/lib/rustlib/aarch64-apple-darwin/lib" "-o" "/Users/hans/dev/rust/build/aarch64-apple-darwin/test/rustdoc/intra-doc/prim-methods-external-core/auxiliary/libmy_core.dylib" "-Wl,-dead_strip" "-dynamiclib" "-Wl,-dylib" "-Wl,-install_name" "-Wl,``@rpath/libmy_core.dylib"`` "-nodefaultlibs"
= note: ld: dynamic main executables must link with libSystem.dylib for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
r? ``@jyn514``
Add a better error message for #39364
There is a known bug in the implementation of mpsc channels in rust.
This adds a clearer error message when the bug occurs, so that developers don't lose too much time looking for the origin of the bug.
See https://github.com/rust-lang/rust/issues/39364
Revise never type fallback algorithm
This is a rebase of https://github.com/rust-lang/rust/pull/84573, but dropping the stabilization of never type (and the accompanying large test diff).
Each commit builds & has tests updated alongside it, and could be reviewed in a more or less standalone fashion. But it may make more sense to review the PR as a whole, I'm not sure. It should be noted that tests being updated isn't really a good indicator of final behavior -- never_type_fallback is not enabled by default in this PR, so we can't really see the full effects of the commits here.
This combines the work by Niko, which is [documented in this gist](https://gist.github.com/nikomatsakis/7a07b265dc12f5c3b3bd0422018fa660), with some additional rules largely derived to target specific known patterns that regress with the algorithm solely derived by Niko. We build these from an intuition that:
* In general, fallback to `()` is *sound* in all cases
* But, in general, we *prefer* fallback to `!` as it accepts more code, particularly that written to intentionally use `!` (e.g., Result's with a Infallible/! variant).
When evaluating Niko's proposed algorithm, we find that there are certain cases where fallback to `!` leads to compilation failures in real-world code, and fallback to `()` fixes those errors. In order to allow for stabilization, we need to fix a good portion of these patterns.
The final rule set this PR proposes is that, by default, we fallback from `?T` to `!`, with the following exceptions:
1. `?T: Foo` and `Bar::Baz = ?T` and `(): Foo`, then fallback to `()`
2. Per [Niko's algorithm](https://gist.github.com/nikomatsakis/7a07b265dc12f5c3b3bd0422018fa660#proposal-fallback-chooses-between--and--based-on-the-coercion-graph), the "live" `?T` also fallback to `()`.
The first rule is necessary to address a fairly common pattern which boils down to something like the snippet below. Without rule 1, we do not see the closure's return type as needing a () fallback, which leads to compilation failure.
```rust
#![feature(never_type_fallback)]
trait Bar { }
impl Bar for () { }
impl Bar for u32 { }
fn foo<R: Bar>(_: impl Fn() -> R) {}
fn main() {
foo(|| panic!());
}
```
r? `@jackh726`
Currently, with the new 2021 edition, if a closure captures all of the
fields of an upvar, we'll drop those fields in the order they are used
within the closure instead of the normal drop order (the definition
order of the fields in the type).
This changes that so we sort the captured fields by the definition order
which causes them to drop in that same order as well.
Fixes https://github.com/rust-lang/project-rfc-2229/issues/42
