bors [Mon, 2 Dec 2019 11:43:50 +0000 (11:43 +0000)]
Auto merge of #66874 - RalfJung:miri-assert-panic, r=oli-obk
Miri engine: proper support for `Assert` MIR terminators
This puts down the basis for https://github.com/rust-lang/miri/issues/1070, and I also did some clean-up. The Miri side of this is at https://github.com/rust-lang/miri/pull/1084.
In order to set --cap-lints warn however, I need bootstrap.py not to clobber RUSTFLAGS. (This worked previously, not sure if it was broken intentionally but we would like support for it.)
Ralf Jung [Mon, 2 Dec 2019 08:34:14 +0000 (09:34 +0100)]
Rollup merge of #66827 - RalfJung:miri-missing-ret-place, r=oli-obk
handle diverging functions forwarding their return place
Fixes https://github.com/rust-lang/miri/issues/1075: the shim around diverging closures turned into function pointers actually "obtains" a return place inside a diverging function, but just uses it as the return place for a diverging callee. Handle this by using NULL places.
This is kind of a hack as it breaks our invariant that all places are dereferencable, but we'd eventually let raw pointers break that anyway I assume so that seems fine.
Const-checking relied on `HasMutInterior` to forbid `&mut` in a const context. This was strange because all we needed to do was look for an `Rvalue::Ref` with a certain `BorrowKind`, whereas the `Qualif` traits are specifically meant to get the qualifs for a *value*. This PR removes that logic from `HasMutInterior` and moves it into `check_consts::Validator`.
As a result, we can now properly handle qualifications for `static`s, which had to be ignored previously since you can e.g. borrow a static `Cell` from another `static`. We also remove the `derived_from_illegal_borrow` logic, since it is no longer necessary; we give good errors for subsequent reborrows/borrows of illegal borrows.
Ralf Jung [Mon, 2 Dec 2019 08:34:09 +0000 (09:34 +0100)]
Rollup merge of #66245 - tmiasko:cfg-sanitize, r=oli-obk
Conditional compilation for sanitizers
Configure sanitize option when compiling with a sanitizer to make
it possible to execute different code depending on whether given
sanitizer is enabled or not.
bors [Mon, 2 Dec 2019 03:09:36 +0000 (03:09 +0000)]
Auto merge of #66944 - Centril:rollup-ojsszx6, r=Centril
Rollup of 7 pull requests
Successful merges:
- #66346 (Replace .unwrap() with ? in std::os::unix::net)
- #66789 (rustc: move mir::SourceScopeLocalData to a field of SourceScopeData.)
- #66850 (rustc: hide HirId's fmt::Debug output from -Z span_free_formats.)
- #66905 (rustc_plugin: Remove some remaining plugin features)
- #66907 (rustc: don't just show raw DefIndex's in BrNamed's fmt::Debug impl.)
- #66918 (Add crc and crypto to target feature whitelist on arm)
- #66926 (add reusable MachineStop variant to Miri engine error enum)
Rollup merge of #66907 - eddyb:br-nicer-named, r=oli-obk
rustc: don't just show raw DefIndex's in BrNamed's fmt::Debug impl.
Context: these `fmt::Debug` impls only get used with `-Z verbose` (which some tests use).
I was going to print the path like in #66850 (or rather, use `DefId`'s `fmt::Debug`, which is close but not as nice), but then I realized that most of the `DefId`s were `crate0:DefIndex(0)`, i.e. the crate root.
As the crate root is not a lifetime, they're clearly dummies of some sort, and we don't have to print anything other than the name for them.
This means that out of all the tests, there's only 5 instances of `BrNamed` that now print the full path to the lifetime parameter, and everything else is shorter instead, which doesn't feel too bad.
Rollup merge of #66905 - petrochenkov:rmplugin2, r=Centril
rustc_plugin: Remove some remaining plugin features
- Plugin arguments (`#![plugin(my_plugin(args))]`) are no longer supported.
- Registering additional plugins from command line (`-Z extra-plugins=my_plugin`) is no longer supported, `-Z crate-attr=plugin(my_plugin)` can be used instead.
- Lint `plugin_as_library` is removed as mostly useless now, when plugins exist as a compatibility feature with greatly reduced functionality.
- Plugins registering additional LLVM passes (`Registry::register_llvm_pass`) are no longer supported, `-C passes=my_passes` can be used instead.
Rollup merge of #66850 - eddyb:span-free-formats, r=oli-obk
rustc: hide HirId's fmt::Debug output from -Z span_free_formats.
This replaces the only occurrences of `HirId {...}` from tests with paths, i.e.:
```rust
[closure@HirId { owner: DefIndex(4), local_id: 15 } q:&i32, t:&T]
```
becomes, after this PR:
```rust
[closure@foo<T>::{{closure}}#0 q:&i32, t:&T]
```
Rollup merge of #66789 - eddyb:mir-source-scope-local-data, r=oli-obk
rustc: move mir::SourceScopeLocalData to a field of SourceScopeData.
By having one `ClearCrossCrate<SourceScopeLocalData>` for each scope, as opposed to a single `ClearCrossCrate` for all the `SourceScopeLocalData`s, we can represent the fact that some scopes have `SourceScopeLocalData` associated with them, and some don't.
This is useful when doing MIR inlining across crates, because the `ClearCrossCrate` will be `Clear` for the cross-crate MIR scopes and `Set` for the local ones.
Also see https://github.com/rust-lang/rust/pull/66203#issuecomment-555589574 for some context around this approach.
Tomasz Miąsko [Tue, 22 Oct 2019 00:00:00 +0000 (00:00 +0000)]
Conditional compilation for sanitizers
Configure sanitize option when compiling with a sanitizer to make
it possible to execute different code depending on whether given
sanitizer is enabled or not.
Rollup merge of #66890 - dtolnay:fmt4, r=Dylan-DPC
Format liballoc with rustfmt
Same strategy as #66691 -- as with my previous formatting PRs, I am avoiding causing merge conflicts in other PRs by only touches those files that are not involved in any currently open PR. Files that appear in new PRs between when this PR is opened and when it makes it to the top of the bors queue will be reverted from this PR.
The list of files involved in open PRs is determined by querying GitHub's GraphQL API [with this script](https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8).
With the list of files from the script in outstanding_files, the relevant commands were:
Rollup merge of #66726 - CAD97:miri-recursion-limit, r=RalfJung
Use recursion_limit for const eval stack limit
cc https://github.com/rust-lang/miri/issues/643 @orium @RalfJung
I'm really not certain how exactly to handle this change, but it looks like it's that simple.
Reuse `recursion_limit` ("The maximum recursion limit for potentially infinitely recursive operations such as auto-dereference and monomorphization") which is configurable by the user for the const evaluation stack frame limit.
The other option is to make `const_eval_stack_frame_limit` configurable in the same way as `recursion_limit` (but I'm not sure how to do that and it'd be a bigger change).
Rollup merge of #66679 - mark-i-m:fix-anon-lifetime-errors, r=matthewjasper
Improve lifetime errors with implicit trait object lifetimes
r? @matthewjasper
cc @estebank
I still think the ideal solution would be to construct a `BrAnon`, but that seems like a more invasive change, and can be done later. This at least gets rid of the hack in `OutliveSuggestion` and is slightly more principled.
Rollup merge of #66503 - thomasetter:panic-error-msg, r=joshtriplett
More useful test error messages on should_panic(expected=...) mismatch
Fixes #66304
r? @gilescope
Shows both the actual as well as the expected panic value when a test with `should_panic(expected=...)` fails.
This makes `should_panic` more consistent with `assert_eq`.
I am not sure whether printing the `Any::type_id()` is useful, is there something better that we could print for non-string panic values?
Rollup merge of #66895 - Centril:rustc_feature, r=oli-obk
Feature gating *declarations* => new crate `rustc_feature`
This PR moves the data-oriented parts of feature gating into its own crate, `rustc_feature`.
The parts consist of some data types as well as `accepted`, `active`, `removed`, and `builtin_attrs`.
Feature gate checking itself remains in `syntax::feature_gate::check`. The parts which define how to emit feature gate errors could probably be moved to `rustc_errors` or to the new `rustc_session` crate introduced in #66878. The visitor itself could probably be moved as a pass in `rustc_passes` depending on how the dependency edges work out.
The PR also contains some drive-by cleanup of feature gate checking. As such, the PR probably best read commit-by-commit.
Make python-generated source files compatible with rustfmt
This PR adjusts the generators for src/libcore/num/dec2flt/table.rs, src/libcore/unicode/printable.rs, and src/libcore/unicode/tables.rs to make it so running `rustfmt` on the generated files no longer needs to apply any changes.
This involves tweaking the python scripts where reasonable to better match rustfmt's style, and adding `#[rustfmt::skip]` to big constant tables that there's no point having rustfmt rewrap.
Rollup merge of #66883 - eddyb:we-cant-have-nice-things, r=oli-obk
rustc_typeck: gate AnonConst's generics on feature(const_generics).
This PR employs the fix for #43408 when `#![feature(const_generics)]` is enabled, making the feature-gate the opt-in for all the possible breakage this may incur.
For example, if this PR lands, this will cause a cycle error (due to #60471):
```rust
#![feature(const_generics)]
fn foo<T: Into<[u8; 4]>>() {}
```
And so will anything with type-level const expressions, in its bounds.
Surprisingly, `impl`s don't seem to be affected (if they were, even libcore wouldn't compile).
One thing I'm worried about is not knowing how much unstable code out there, using const-generics, will be broken. But types like `Foo<{N+1}>` never really worked, and do after this PR, just not in bounds - so ironically, it's type-level const expressions that don't depend on generics, which will break (in bounds).
Also, if we do this, we'll have effectively blocked stabilization of const generics on #60471.
Rollup merge of #66705 - pitdicker:atomic_mut_ptr, r=KodrAus
Atomic as_mut_ptr
I encountered the following pattern a few times: In Rust we use some atomic type like `AtomicI32`, and an FFI interface exposes this as `*mut i32` (or some similar `libc` type).
It was not obvious to me if a just transmuting a pointer to the atomic was acceptable, or if this should use a cast that goes through an `UnsafeCell`. See https://github.com/rust-lang/rust/issues/66136#issuecomment-557802477
Transmuting the pointer directly:
```rust
let atomic = AtomicI32::new(1);
let ptr = &atomic as *const AtomicI32 as *mut i32;
unsafe {
ffi(ptr);
}
```
A dance with `UnsafeCell`:
```rust
let atomic = AtomicI32::new(1);
unsafe {
let ptr = (&*(&atomic as *const AtomicI32 as *const UnsafeCell<i32>)).get();
ffi(ptr);
}
```
Maybe in the end both ways could be valid. But why not expose a direct method to get a pointer from the standard library?
An `as_mut_ptr` method on atomics can be safe, because only the use of the resulting pointer is where things can get unsafe. I documented its use for FFI, and "Doing non-atomic reads and writes on the resulting integer can be a data race."
The standard library could make use this method in a few places in the WASM module.
cc @RalfJung as you answered my original question.
bors [Sat, 30 Nov 2019 12:42:44 +0000 (12:42 +0000)]
Auto merge of #66887 - dtolnay:rollup-uxowp8d, r=Centril
Rollup of 4 pull requests
Successful merges:
- #66818 (Format libstd/os with rustfmt)
- #66819 (Format libstd/sys with rustfmt)
- #66820 (Format libstd with rustfmt)
- #66847 (Allow any identifier as format arg name)
David Tolnay [Sat, 30 Nov 2019 02:46:09 +0000 (18:46 -0800)]
Rollup merge of #66847 - dtolnay:_fmt, r=joshtriplett
Allow any identifier as format arg name
Previously:
```console
error: invalid format string: invalid argument name `_x`
--> src/main.rs:2:16
|
2 | println!("{_x}", _x=0);
| ^^ invalid argument name in format string
|
= note: argument names cannot start with an underscore
```
Not supporting identifiers starting with underscore appears to have been an arbitrary limitation from 2013 in code that was most likely never reviewed: https://github.com/rust-lang/rust/pull/8245/files#diff-0347868ef389c805e97636623e4a4ea6R277
The error message was dutifully improved in #50610 but is there any reason that leading underscore would be a special case?
This commit updates the format_args parser to accept identifiers with leading underscores.
David Tolnay [Sat, 30 Nov 2019 02:46:08 +0000 (18:46 -0800)]
Rollup merge of #66820 - dtolnay:fmt3, r=Dylan-DPC
Format libstd with rustfmt
(Same strategy as #66691.)
This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd *that are not involved in any currently open PR* to minimize merge conflicts, and are not part of libstd/os (#66818) or libstd/sys (#66819). The list of files involved in open PRs was determined by querying GitHub's GraphQL API [with this script](https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8).
With the list of files from the script in outstanding_files, the relevant commands were:
David Tolnay [Sat, 30 Nov 2019 02:46:06 +0000 (18:46 -0800)]
Rollup merge of #66819 - dtolnay:fmt2, r=kennytm
Format libstd/sys with rustfmt
(Same strategy as #66691.)
This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd/sys *that are not involved in any currently open PR* to minimize merge conflicts. The list of files involved in open PRs was determined by querying GitHub's GraphQL API [with this script](https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8).
With the list of files from the script in outstanding_files, the relevant commands were:
David Tolnay [Sat, 30 Nov 2019 02:46:05 +0000 (18:46 -0800)]
Rollup merge of #66818 - dtolnay:fmt1, r=Dylan-DPC
Format libstd/os with rustfmt
(Same strategy as #66691.)
This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd/os *that are not involved in any currently open PR* to minimize merge conflicts. The list of files involved in open PRs was determined by querying GitHub's GraphQL API [with this script](https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8).
With the list of files from the script in outstanding_files, the relevant commands were:
David Tolnay [Wed, 27 Nov 2019 18:29:00 +0000 (10:29 -0800)]
Format libstd with rustfmt
This commit applies rustfmt with rust-lang/rust's default settings to
files in src/libstd *that are not involved in any currently open PR* to
minimize merge conflicts. THe list of files involved in open PRs was
determined by querying GitHub's GraphQL API with this script:
https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8
With the list of files from the script in outstanding_files, the
relevant commands were:
David Tolnay [Wed, 27 Nov 2019 18:28:39 +0000 (10:28 -0800)]
Format libstd/sys with rustfmt
This commit applies rustfmt with rust-lang/rust's default settings to
files in src/libstd/sys *that are not involved in any currently open PR*
to minimize merge conflicts. THe list of files involved in open PRs was
determined by querying GitHub's GraphQL API with this script:
https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8
With the list of files from the script in outstanding_files, the
relevant commands were:
David Tolnay [Wed, 27 Nov 2019 18:28:21 +0000 (10:28 -0800)]
Format libstd/os with rustfmt
This commit applies rustfmt with rust-lang/rust's default settings to
files in src/libstd/os *that are not involved in any currently open PR*
to minimize merge conflicts. THe list of files involved in open PRs was
determined by querying GitHub's GraphQL API with this script:
https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8
With the list of files from the script in outstanding_files, the
relevant commands were:
projects / rust.git / log