rustdoc: Fix a few issues with associated consts
* Make sure private consts are stripped.
* Don't show a code block for the value if there is none.
* Make sure default values are shown in impls.
* Make sure docs from the trait are used if the impl has no docs.
assert_eq failure message easier to read
By having the left and right strings aligned with one another it helps spot the difference between the two far quicker than if they are on the same line.
E.g.
Before:
```
thread 'tests::test_safe_filename' panicked at 'assertion failed: `(left == right)` left: `"-aandb--S123.html"` right: `"-aandb-S123.html"`',
```
After:
```
thread 'tests::test_safe_filename' panicked at 'assertion failed: `(left == right)`
left: `"-aandb--S123.html"`
right: `"-aandb-S123.html"`',
```
When the strings are both on the same line it take a lot longer to spot the difference. It is a small change but the small time savings add up with repetition. This would help Rust be an excellent language to write tests in out of the box.
Closes https://github.com/rust-lang/rust/issues/41615
This change allows the user to add an `#[allow_fail]` attribute to
tests that will cause the test to compile & run, but if the test fails
it will not cause the entire test run to fail. The test output will
show the failure, but in yellow instead of red, and also indicate that
it was an allowed failure.
- Point out the origin of a type requirement when it is the return type
of a method
- Point out possibly missing semicolon when the return type is () and
the implicit return makes sense as a statement
- Suggest changing the return type of methods with default return type
- Don't suggest changing the return type on fn main()
- Don't suggest changing the return type on impl fn
Previously, conflicting forbid/allow attributes for a lint group would
result in a separate "allow(L) overruled by outer forbid(L)" error for
every lint L in the group. This was needlessly and annoyingly verbose;
we prefer to just have one error pointing out the conflicting
attributes.
Resolves#42873.
* Make sure private consts are stripped.
* Don't show a code block for the value if there is none.
* Make sure default values are shown in impls.
* Make sure docs from the trait are used if the impl has no docs.
Print the two types in the span label for transmute errors.
Fixes#37157. I'm not entirely happy with the changes here but overall it's better in my opinion; we certainly avoid the odd language in that issue, which changes to:
```
error[E0512]: transmute called with differently sized types: <C as TypeConstructor<'a>>::T (size can vary because of <C as TypeConstructor>::T) to <C as TypeConstructor<'b>>::T (size can vary because of <C as TypeConstructor>::T)
--> test.rs:8:5
|
8 | ::std::mem::transmute(x)
| ^^^^^^^^^^^^^^^^^^^^^ transmuting between <C as TypeConstructor<'a>>::T and <C as TypeConstructor<'b>>::T
error: aborting due to previous error(s)
```
Change the for-loop desugar so the `break` does not affect type inference. Fixes#42618
Rewrite the `for` loop desugaring to avoid contaminating the inference results. Under the older desugaring, `for x in vec![] { .. }` would erroneously type-check, even though the type of `vec![]` is unconstrained. (written by @nikomatsakis)
Integrate jobserver support to parallel codegen
This commit integrates the `jobserver` crate into the compiler. The crate was
previously integrated in to Cargo as part of rust-lang/cargo#4110. The purpose
here is to two-fold:
* Primarily the compiler can cooperate with Cargo on parallelism. When you run
`cargo build -j4` then this'll make sure that the entire build process between
Cargo/rustc won't use more than 4 cores, whereas today you'd get 4 rustc
instances which may all try to spawn lots of threads.
* Secondarily rustc/Cargo can now integrate with a foreign GNU `make` jobserver.
This means that if you call cargo/rustc from `make` or another
jobserver-compatible implementation it'll use foreign parallelism settings
instead of creating new ones locally.
As the number of parallel codegen instances in the compiler continues to grow
over time with the advent of incremental compilation it's expected that this'll
become more of a problem, so this is intended to nip concurrent concerns in the
bud by having all the tools to cooperate!
Note that while rustc has support for itself creating a jobserver it's far more
likely that rustc will always use the jobserver configured by Cargo. Cargo today
will now set a jobserver unconditionally for rustc to use.
mark calls in the unwind path as !noinline
The unwind path is always cold, so that should not have bad performance
implications. This avoids catastrophic exponential inlining, and also
decreases the size of librustc.so by 1.5% (OTOH, the size of `libstd.so`
increased by 0.5% for some reason).
Fixes#41696.
r? @nagisa
This commit integrates the `jobserver` crate into the compiler. The crate was
previously integrated in to Cargo as part of rust-lang/cargo#4110. The purpose
here is to two-fold:
* Primarily the compiler can cooperate with Cargo on parallelism. When you run
`cargo build -j4` then this'll make sure that the entire build process between
Cargo/rustc won't use more than 4 cores, whereas today you'd get 4 rustc
instances which may all try to spawn lots of threads.
* Secondarily rustc/Cargo can now integrate with a foreign GNU `make` jobserver.
This means that if you call cargo/rustc from `make` or another
jobserver-compatible implementation it'll use foreign parallelism settings
instead of creating new ones locally.
As the number of parallel codegen instances in the compiler continues to grow
over time with the advent of incremental compilation it's expected that this'll
become more of a problem, so this is intended to nip concurrent concerns in the
bud by having all the tools to cooperate!
Note that while rustc has support for itself creating a jobserver it's far more
likely that rustc will always use the jobserver configured by Cargo. Cargo today
will now set a jobserver unconditionally for rustc to use.
Memoize types in `is_representable` to avoid exponential worst-case
I could have made representability a cached query, but that would have
been added complexity for not much benefit - outside of the exponential
worst-case, this pass is fast enough already.
Fixes#42747.
r? @eddyb
Remove in-tree flate/getopts crates
Remove `src/libflate` in favor of `flate2` on crates.io and `src/libgetopts` in favor of `getopts` on crates.io. The replacements have slightly different APIs and the usage in the compiler has been updated to reflect this.
This uncovered an unfortunate limitation of the compiler today to deal with linking everything correctly, and the workaround can be found documented in `src/librustc/Cargo.toml`.
Clearer Error Message for Duplicate Definition
Clearer use of the error message and span labels to communicate duplication definitions/imports.
fixes#42061
This commit deletes the in-tree `getopts` crate in favor of the crates.io-based
`getopts` crate. The main difference here is with a new builder-style API, but
otherwise everything else remains relatively standard.
The unwind path is always cold, so that should not have bad performance
implications. This avoids catastrophic exponential inlining, and also
decreases the size of librustc.so by 1.5% (OTOH, the size of `libstd.so`
increased by 0.5% for some reason).
Fixes#41696.
