fmt: set force_multiline_blocks=true
This is an experiment, I am not yet sure if I like it... but it does prevent rustfmt from putting stuff after the `=>` in a `match` (unless the entire arm fits there), which IMO is a big plus. What do others think?
(I also tried setting `match_arm_blocks` back to its default of `true`, but that adds too many braces for my taste.)
Btw, `@calebcartwright` is the interaction of `match_arm_blocks = false` and `force_multiline_blocks = true` as can be seen here expected? I think I like it, but it it is not at all what I expected from the docs which describe `force_multiline_blocks = true` as "Force multiline closure and match arm bodies to be wrapped in a block" -- but here that is not the effect it has, there are no new blocks being added.
sync license files with rustc repo
`@Mark-Simulacrum` pointed out that our license files are slightly different from those in rustc. This syncs them.
The question is... is this a thing we can just do?^^
Use `miri` inside the target directory used by rustc as Miri's target directory
Resolves#1311.
This PR makes Miri use `miri` inside the rustc target directory as its target directory, by letting `cargo-miri` get the rustc target directory by calling `cargo metadata`, append `miri` to it, and pass it with `--target-dir` to Cargo.
Getting the rustc target directory accurately requires calling `cargo metadata` as far as I know, because the `target-dir` can be set in config files in various places that are hard for `cargo-miri` to find.
I also considered https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#custom-named-profiles, but it looks like that requires adding `cargo-features = ["named-profiles"]` to **`Cargo.toml`**, which would be tricky for `cargo-miri`:
```
$ cargo +nightly-2021-06-23 test --config 'profile.miri.inherits="release"' --profile=miri -Z named-profiles -Z unstable-options
error: config profile `miri` is not valid (defined in `--config cli option`)
Caused by:
feature `named-profiles` is required
consider adding `cargo-features = ["named-profiles"]` to the manifest
```
Filter out items other than non-generic functions and statics in our version of `exported_symbols`
[`#[no_mangle]` on a `use` item](https://docs.rs/brotli-decompressor/2.3.1/src/brotli_decompressor/ffi/mod.rs.html#3-5) can make Miri ICE when compiling a dependency (rust-lang/rust#86261):
```rs
#[no_mangle]
use std::{thread,panic, io, boxed, any, string};
```
<details>
```
error: internal compiler error: compiler/rustc_middle/src/ty/mod.rs:1650:13: item_name: no name for DefPath { data: [DisambiguatedDefPathData { data: Misc, disambiguator: 14 }], krate: crate0 }
thread 'rustc' panicked at 'Box<dyn Any>', compiler/rustc_errors/src/lib.rs:1007:9
stack backtrace:
0: std::panicking::begin_panic
1: std::panic::panic_any
2: rustc_errors::HandlerInner::bug
3: rustc_errors::Handler::bug
4: rustc_middle::ty::context::tls::with_opt
5: rustc_middle::util:🐛:opt_span_bug_fmt
6: rustc_middle::util:🐛:bug_fmt
7: rustc_middle::ty::<impl rustc_middle::ty::context::TyCtxt>::item_name
8: rustc_symbol_mangling::symbol_name_provider
9: rustc_query_impl::<impl rustc_query_system::query::config::QueryAccessors<rustc_query_impl::plumbing::QueryCtxt> for rustc_query_impl::queries::symbol_name>::compute
10: rustc_query_system::query::plumbing::get_query_impl
11: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::symbol_name
12: rustc_middle::middle::exported_symbols::ExportedSymbol::symbol_name_for_local_instance
13: rustc_codegen_ssa:🔙:symbol_export::symbol_name_for_instance_in_crate
14: rustc_codegen_ssa:🔙:linker::exported_symbols
15: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
16: rustc_codegen_ssa:🔙:linker::LinkerInfo::new
17: rustc_codegen_ssa:🔙:write::start_async_codegen
18: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::backend::CodegenBackend>::codegen_crate
19: rustc_interface::passes::QueryContext::enter
20: rustc_interface::queries::Queries::ongoing_codegen
21: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
22: rustc_span::with_source_map
23: rustc_interface::interface::create_compiler_and_run
24: rustc_span::with_session_globals
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md
note: rustc 1.54.0-nightly (a50d72158 2021-06-08) running on x86_64-unknown-linux-gnu
note: compiler flags: -C embed-bitcode=no -C debuginfo=1 --crate-type lib
note: some of the compiler flags provided by cargo are hidden
query stack during panic:
#0 [symbol_name] computing the symbol for `{misc#14}`
end of query stack
```
</details>
This might be because in #1776, we override the `exported_symbols` query, and our version of `exported_symbols` can return a `use` item which don't have a name if the `use` item is tagged with `#[no_mangle]`, and then:
- `rustc_codegen_ssa:🔙:symbol_export::symbol_name_for_instance_in_crate` is called for for every `exported_symbols`: fb3ea63d9b/compiler/rustc_codegen_ssa/src/back/linker.rs (L1300-L1304)
- it calls `rustc_middle::middle::exported_symbols::ExportedSymbol::symbol_name_for_local_instance`: fb3ea63d9b/compiler/rustc_codegen_ssa/src/back/symbol_export.rs (L412)
- which calls `rustc_symbol_mangling::symbol_name_provider`: fb3ea63d9b/compiler/rustc_middle/src/middle/exported_symbols.rs (L37-L44)
- which calls `item_name`: fb3ea63d9b/compiler/rustc_symbol_mangling/src/lib.rs (L216), which triggers the ICE
It might also be problematic for d39f0c64b8/src/shims/foreign_items.rs (L165) which also uses `item_name`, but Miri cannot compile the dependency, so that code can't be reached.
Therefore, this PR makes `exported_symbols` filter out all items that are not functions or statics, so all items returned will have a name, which avoids the ICE (I have tested it in the https://github.com/jorgecarleitao/arrow2 repository).
(This PR also includes a commit that fixes a small (unrelated) bug for `#[no_mangle]` on associated functions -- I found that because I notice `#[no_mangle]` is supported on associated functions and they should not be filtered out in `exported_symbols`.)
Fixes (when the submodule is bumped) rust-lang/rust#86261.
Report an error if a `#[no_mangle]`/`#[export_name = ...]` function has the same symbol name as a built-in shim
Implements https://github.com/rust-lang/miri/pull/1776#issuecomment-821322605.
The error looks like this:
```
error: found `malloc` symbol definition that clashes with a built-in shim
--> tests/compile-fail/function_calls/exported_symbol_shim_clashing.rs:12:9
|
12 | malloc(0);
| ^^^^^^^^^ found `malloc` symbol definition that clashes with a built-in shim
|
help: the `malloc` symbol is defined here
--> tests/compile-fail/function_calls/exported_symbol_shim_clashing.rs:2:1
|
2 | / extern "C" fn malloc(_: usize) -> *mut std::ffi::c_void {
3 | | //~^ HELP the `malloc` symbol is defined here
4 | | unreachable!()
5 | | }
| |_^
= note: inside `main` at tests/compile-fail/function_calls/exported_symbol_shim_clashing.rs:12:9
```
This does not implement "better error messages than we do currently for arg/ABI mismatches" in https://github.com/rust-lang/miri/pull/1776#issuecomment-821343175 -- I failed to remove all `check_arg_count()` and `check_abi()` (they are still used in `src/shims/intrinsics.rs` and `call_dlsym()`) and they don't receive the name of the shim.
