### Integration Tests
This commit introduces some new fixtures to the `run-make-fulldeps`
test suite.
* c-unwind-abi-catch-panic: Exercise unwinding a panic. This
catches a panic across an FFI boundary and downcasts it into
an integer.
* c-unwind-abi-catch-lib-panic: This is similar to the previous
`*catch-panic` test, however in this case the Rust code that
panics resides in a separate crate.
### Add `rust_eh_personality` to `#[no_std]` alloc tests
This commit addresses some test failures that now occur in the
following two tests:
* no_std-alloc-error-handler-custom.rs
* no_std-alloc-error-handler-default.rs
Each test now defines a `rust_eh_personality` extern function, in
the same manner as shown in the "Writing an executable without
stdlib" section of the `lang_items` documentation here:
https://doc.rust-lang.org/unstable-book/language-features/lang-items.html#writing-an-executable-without-stdlib
Without this change, these tests would fail to compile due to a
linking error explaining that there was an "undefined reference
to `rust_eh_personality'."
### Updated hash
* update 32-bit hash in `impl1` test
### Panics
This commit uses `panic!` macro invocations that return a string,
rather than using an integer as a panic payload.
Doing so avoids the following warnings that were observed during
rollup for the `*-msvc-1` targets:
```
warning: panic message is not a string literal
--> panic.rs:10:16
|
10 | panic!(x); // That is too big!
| ^
|
= note: `#[warn(non_fmt_panic)]` on by default
= note: this is no longer accepted in Rust 2021
help: add a "{}" format string to Display the message
|
10 | panic!("{}", x); // That is too big!
| ^^^^^
help: or use std::panic::panic_any instead
|
10 | std::panic::panic_any(x); // That is too big!
| ^^^^^^^^^^^^^^^^^^^^^
warning: 1 warning emitted
```
See: https://github.com/rust-lang-ci/rust/runs/1992118428
As these errors imply, panicking without a format string will be
disallowed in Rust 2021, per #78500.
Upgrade to LLVM 12
This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far.
r? `@cuviper`
We previously used -Os to disable this pass, but since
https://reviews.llvm.org/D91673 this no longer works. Explicitly
disable it using -Cllvm-args instead.
Set path of the compile unit to the source directory
As part of the effort to implement split dwarf debug info, we ended up
setting the compile unit location to the output directory rather than
the source directory. Furthermore, it seems like we failed to remap the
prefixes for this as well!
The desired behaviour is to instead set the `DW_AT_GNU_dwo_name` to a
path relative to compiler's working directory. This still allows
debuggers to find the split dwarf files, while not changing the
behaviour of the code that is compiling with regular debug info, and not
changing the compiler's behaviour with regards to reproducibility.
Fixes#82074
cc `@alexcrichton` `@davidtwco`
Update the bootstrap compiler
This updates the bootstrap compiler, notably leaving out a change to enable semicolon in macro expressions lint, because stdarch still depends on the old behavior.
Improve assert_eq! and assert_ne!
This PR improves `assert_eq!` and `assert_ne!` by moving the panicking code in an external function.
It does not change the fast path, but the move of the formatting in the cold path (the panic) may have a positive effect on in instruction cache use and with inlining.
Moreover, the use of trait objects instead of generic may improve compile times for `assert_eq!`-heavy code.
Godbolt link: ~~https://rust.godbolt.org/z/TYa9MT~~ \
Updated: https://rust.godbolt.org/z/bzE84x
Ensures `make` tests run under /bin/dash (if available), like CI, and fixes a Makefile
Note: This cherrypicks #81688 (`@pnkfelix)`
Updates `tools.mk` to explicitly require `SHELL := /bin/dash`, since CI uses `dash` but other environments (including developer local machines) may default to `bash`.
Replaces bash-specific shell command in one Makefile with a dash-compatible alternative, and re-enables the affected Makefile test.
Removes apparently redundant definition of `UNAME`.
Also see: [zulip discussion thread](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/how.20to.20run.2Fbless.20src.2Ftest.2Frun-make-fulldeps.2Fcoverage.20.3F)
r? `@pnkfelix`
FYI: `@wesleywiser` `@tmandry`
Updates `tools.mk` to explicitly require `SHELL := /bin/dash`, since CI
uses `dash` but other environments (including developer local machines)
may default to `bash`.
Replaces bash-specific shell command in one Makefile with a
dash-compatible alternative, and re-enables the affected Makefile test.
Removes apparently redundant definition of `UNAME`.
Fix derived PartialOrd operators
The derived implementation of `partial_cmp` compares matching fields one
by one, stopping the computation when the result of a comparison is not
equal to `Some(Equal)`.
On the other hand the derived implementation for `lt`, `le`, `gt` and
`ge` continues the computation when the result of a field comparison is
`None`, consequently those operators are not transitive and inconsistent
with `partial_cmp`.
Fix the inconsistency by using the default implementation that fall-backs
to the `partial_cmp`. This also avoids creating very deeply nested
closures that were quite costly to compile.
Fixes#81373.
Helps with #81278, #80118.
Revert 78373 ("dont leak return value after panic in drop")
Short term resolution for issue #80949.
Reopen#47949 after this lands.
(We plan to fine-tune PR #78373 to not run into this problem.)
Use `# min-llvm-version: 11.0` to force a minimum LLVM version
Use `# min-llvm-version: 11.0` to force a minimum LLVM version, rather than ad-hoc internal solution.
In particular: the specific code to define LLVM_VERSION_11_PLUS here was, for some reason, using `$(shell ...)` with bash-specific variable replacement code. On non-bash platforms like dash, that `shell` invocation would fail, and the
LLVM_VERSION_11_PLUS check would always fail, the test would always be ignored, and thus be treated as a "success" (in the sense that `--bless` would never do anything).
* Note in particular that GNU Make treats the SHELL variable as a very special case: it does not inherit the value of SHELL from the user's environment. Except on Windows. See more explanation in the [GNU Make docs](https://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html).
* The effect of this is that these tests end up using `/bin/sh` (except on Windows) for their `$(shell ...)` invocations, and thus we see differing behaviors depending on whether your `/bin/sh` links to `/bin/dash` or to `/bin/bash`.
This was causing me a lot of pain.
(Test was silently ignored on Linux CI prior to parent commit that switched to
using `# min-llvm-version`. But the switch made the ignoring stop, exposing
other brokenness in the form of bash-dependent syntax in the `$(shell ...)`
invocations.)
In particular: the specific code to define LLVM_VERSION_11_PLUS here was, for
some reason, using `$(shell ...)` with bash-specific variable replacement code.
On non-bash platforms like dash, that `shell` invocation would fail, and the
LLVM_VERSION_11_PLUS check would always fail, the test would always be ignored,
and thus be treated as a "success" (in the sense that `--bless` would never do
anything).
This was causing me a lot of pain.
Implement Rust 2021 panic
This implements the Rust 2021 versions of `panic!()`. See https://github.com/rust-lang/rust/issues/80162 and https://github.com/rust-lang/rfcs/pull/3007.
It does so by replacing `{std, core}::panic!()` by a bulitin macro that expands to either `$crate::panic::panic_2015!(..)` or `$crate::panic::panic_2021!(..)` depending on the edition of the caller.
This does not yet make std's panic an alias for core's panic on Rust 2021 as the RFC proposes. That will be a separate change: c5273bdfb2 That change is blocked on figuring out what to do with https://github.com/rust-lang/rust/issues/80846 first.
This commit adds a new stable codegen option to rustc,
`-Csplit-debuginfo`. The old `-Zrun-dsymutil` flag is deleted and now
subsumed by this stable flag. Additionally `-Zsplit-dwarf` is also
subsumed by this flag but still requires `-Zunstable-options` to
actually activate. The `-Csplit-debuginfo` flag takes one of
three values:
* `off` - This indicates that split-debuginfo from the final artifact is
not desired. This is not supported on Windows and is the default on
Unix platforms except macOS. On macOS this means that `dsymutil` is
not executed.
* `packed` - This means that debuginfo is desired in one location
separate from the main executable. This is the default on Windows
(`*.pdb`) and macOS (`*.dSYM`). On other Unix platforms this subsumes
`-Zsplit-dwarf=single` and produces a `*.dwp` file.
* `unpacked` - This means that debuginfo will be roughly equivalent to
object files, meaning that it's throughout the build directory
rather than in one location (often the fastest for local development).
This is not the default on any platform and is not supported on Windows.
Each target can indicate its own default preference for how debuginfo is
handled. Almost all platforms default to `off` except for Windows and
macOS which default to `packed` for historical reasons.
Some equivalencies for previous unstable flags with the new flags are:
* `-Zrun-dsymutil=yes` -> `-Csplit-debuginfo=packed`
* `-Zrun-dsymutil=no` -> `-Csplit-debuginfo=unpacked`
* `-Zsplit-dwarf=single` -> `-Csplit-debuginfo=packed`
* `-Zsplit-dwarf=split` -> `-Csplit-debuginfo=unpacked`
Note that `-Csplit-debuginfo` still requires `-Zunstable-options` for
non-macOS platforms since split-dwarf support was *just* implemented in
rustc.
There's some more rationale listed on #79361, but the main gist of the
motivation for this commit is that `dsymutil` can take quite a long time
to execute in debug builds and provides little benefit. This means that
incremental compile times appear that much worse on macOS because the
compiler is constantly running `dsymutil` over every single binary it
produces during `cargo build` (even build scripts!). Ideally rustc would
switch to not running `dsymutil` by default, but that's a problem left
to get tackled another day.
Closes#79361
handle generic trait methods in coverage-report tests
also make the generic function pattern more specific and remove the extra $ that fails the matching.
r? `@wesleywiser`
as this was failing the test of #76896