In addition to defining and handling the new option, we also add a
method on librustc::Session for determining the necessity of overflow
checks. This method provides a single point to sort out the three (!)
different ways for turning on overflow checks: -C debug-assertions, -C
overflow-checks, and -Z force-overflow-checks.
Fixes#33134.
Report full details of inference errors
When the old suggestion machinery was removed by @brson in https://github.com/rust-lang/rust/pull/37057, it was not completely removed. There was a bit of code that had the job of going through errors and finding those for which suggestions were applicable, and it remained, causing us not to emit the full details of such errors. This PR removes that.
I've also added various lifetime tests to the UI test suite (so you can also see the before/after there). I have some concrete thoughts on how to improve these cases and am planning on writing those up in some mentoring issues (@CengizIO has expressed interest in working on those changes, so I plan to work with him on it, at least to start).
cc @jonathandturner
erase late bound regions in `get_vtable_methods()`
Higher-ranked object types can otherwise cause late-bound regions to
sneak into the substs, leading to the false conclusion that some method
is unreachable.
r? @arielb1, who wrote the heart of this patch anyhow
Fixes#39292
These are some samples that I have been focusing on improving over
time. In this PR, I mainly want to stem the bleeding where we in some
cases we show an error that gives you no possible way to divine the
problem.
Higher-ranked object types can otherwise cause late-bound regions to
sneak into the substs, leading to the false conclusion that some method
is unreachable. The heart of this patch is from @arielb1.
Adding compile fail test for staged_api feature
Issue #39059
r? @est31
@est31 running the tests for this feature fails. Is that expected since this is the `compile-fail`suite?
I copied this test from the run-pass suite: `rust/src/test/run-pass/reachable-unnameable-type-alias.rs`. What are the differences between these suites in operation and why they are used?
[MIR] SwitchInt Everywhere
Something I've been meaning to do for a very long while. This PR essentially gets rid of 3 kinds of conditional branching and only keeps the most general one - `SwitchInt`. Primary benefits are such that dealing with MIR now does not involve dealing with 3 different ways to do conditional control flow. On the other hand, constructing a `SwitchInt` currently requires more code than what previously was necessary to build an equivalent `If` terminator. Something trivially "fixable" with some constructor methods somewhere (MIR needs stuff like that badly in general).
Some timings (tl;dr: slightly faster^1 (unexpected), but also uses slightly more memory at peak (expected)):
^1: Not sure if the speed benefits are because of LLVM liking the generated code better or the compiler itself getting compiled better. Either way, its a net benefit. The CORE and SYNTAX timings done for compilation without optimisation.
```
AFTER:
Building stage1 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 31.50 secs
Finished release [optimized] target(s) in 31.42 secs
Building stage1 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 439.56 secs
Finished release [optimized] target(s) in 435.15 secs
CORE: 99% (24.81 real, 0.13 kernel, 24.57 user); 358536k resident
CORE: 99% (24.56 real, 0.15 kernel, 24.36 user); 359168k resident
SYNTAX: 99% (49.98 real, 0.48 kernel, 49.42 user); 653416k resident
SYNTAX: 99% (50.07 real, 0.58 kernel, 49.43 user); 653604k resident
BEFORE:
Building stage1 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 31.84 secs
Building stage1 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 451.17 secs
CORE: 99% (24.66 real, 0.20 kernel, 24.38 user); 351096k resident
CORE: 99% (24.36 real, 0.17 kernel, 24.18 user); 352284k resident
SYNTAX: 99% (52.24 real, 0.56 kernel, 51.66 user); 645544k resident
SYNTAX: 99% (51.55 real, 0.48 kernel, 50.99 user); 646428k resident
```
cc @nikomatsakis @eddyb
macros: fix inert attributes from `proc_macro_derives` with `#![feature(proc_macro)]`
This PR refactors collection of `proc_macro_derive` invocations to fix#39347.
After this PR, the input to a `#[proc_macro_derive]` function no longer sees `#[derive]`s on the underlying item. For example, consider:
```rust
extern crate my_derives;
use my_derives::{Trait, Trait2};
#[derive(Copy, Clone)]
#[derive(Trait)]
#[derive(Trait2)]
struct S;
```
Today, the input to the `Trait` derive is `#[derive(Copy, Clone, Trait2)] struct S;`, and the input to the `Trait2` derive is `#[derive(Copy, Clone)] struct S;`. More generally, a `proc_macro_derive` sees all builtin derives, as well as all `proc_macro_derive`s listed *after* the one being invoked.
After this PR, both `Trait` and `Trait2` will see `struct S;`.
This is a [breaking-change], but I believe it is highly unlikely to cause breakage in practice.
r? @nrc
rustdoc: Show attributes on all item types
Currently attributes are only shown for structs, unions and enums but
they should be shown for all items. For example it is useful to know if a
function is `#[no_mangle]`.
improve error message when two-arg assert_eq! receives a trailing comma
Previously, `assert_eq!(left, right,)` (respectively, `assert_ne!(left,
right,)`; note the trailing comma) would result in a confusing "requires
at least a format string argument" error. In reality, a format string is
optional, but the trailing comma puts us into the "match a token tree of
zero or more tokens" branch of the macro (in order to support the
optional format string), and passing the empty token tree into
`format_args!` results in the confusing error. If instead we match a
token tree of one or more tokens, we get a much more sensible
"unexpected end of macro invocation" error.
While we're here, fix up a stray space before a comma in the match
guards.
Resolves#39369.
-----
**Before:**
```
$ rustc scratch.rs
error: requires at least a format string argument
--> scratch.rs:2:5
|
2 | assert_eq!(1, 2,);
| ^^^^^^^^^^^^^^^^^^
|
= note: this error originates in a macro outside of the current crate
error: aborting due to previous error
```
**After:**
```
$ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc scratch.rs
error: unexpected end of macro invocation
--> scratch.rs:2:20
|
2 | assert_eq!(1, 2,);
| ^
```
remove wrong packed struct test
This UB was found by running the test under [Miri](https://github.com/solson/miri) which rejects these unsafe unaligned loads. 😄
