bors [Mon, 30 May 2022 17:39:58 +0000 (17:39 +0000)]
Auto merge of #97480 - conradludgate:faster-format-literals, r=joshtriplett
improve format impl for literals
The basic idea of this change can be seen here https://godbolt.org/z/MT37cWoe1.
Updates the format impl to have a fast path for string literals and the default path for regular format args.
This change will allow `format!("string literal")` to be used interchangably with `"string literal".to_owned()`.
This would be relevant in the case of `f!"string literal"` being legal (https://github.com/rust-lang/rfcs/pull/3267) in which case it would be the easiest way to create owned strings from literals, while also being just as efficient as any other impl
Dylan DPC [Mon, 30 May 2022 12:33:53 +0000 (14:33 +0200)]
Rollup merge of #97545 - thomcc:sip-comment-safety, r=Dylan-DPC
Reword safety comments in core/hash/sip.rs
In https://rust-lang.zulipchat.com/#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/Is.20there.20any.20way.20to.20soundly.20do.20a.20masked.20out-of-bounds.20read.3F/near/284329248 it came up that this is using an atypical (and somewhat vague) phrasing of the safety requirement, so this slightly rewords it.
Dylan DPC [Mon, 30 May 2022 12:33:50 +0000 (14:33 +0200)]
Rollup merge of #97504 - JohnTitor:cleanup-deps, r=davidtwco
Ensure source file present when calculating max line number
Resubmission of #89268, fixes #71363
The behavior difference of `simulate-remapped-rust-src-base` is not something we should take into account here, so limiting targets to run the test makes sense, I think.
r? `@davidtwco,` and `@estebank,` you might be interested in this change
Dylan DPC [Mon, 30 May 2022 12:33:49 +0000 (14:33 +0200)]
Rollup merge of #97499 - est31:master, r=Dylan-DPC
Remove "sys isn't exported yet" phrase
The oldest occurence is from 9e224c2bf18ebf8f871efb2e1aba43ed7970ebb7,
which is from the pre-1.0 days. In the years since then, std::sys still
hasn't been exported, and the last attempt was met with strong criticism:
https://github.com/rust-lang/rust/pull/97151
Thus, removing the "yet" part makes a lot of sense.
Dylan DPC [Mon, 30 May 2022 12:33:48 +0000 (14:33 +0200)]
Rollup merge of #97494 - est31:remove_box_alloc_tests, r=Dylan-DPC
Use Box::new() instead of box syntax in library tests
The tests inside `library/*` have no reason to use `box` syntax as they have 0 performance relevance. Therefore, we can safely remove them (instead of having to use alternatives like the one in #97293).
est31 [Sat, 28 May 2022 23:00:24 +0000 (01:00 +0200)]
Remove "sys isn't exported yet" phrase
The oldest occurence is from 9e224c2bf18ebf8f871efb2e1aba43ed7970ebb7,
which is from the pre-1.0 days. In the years since then, std::sys still
hasn't been exported, and the last attempt was met with strong criticism:
https://github.com/rust-lang/rust/pull/97151
Thus, removing the "yet" part makes a lot of sense.
bors [Mon, 30 May 2022 09:19:03 +0000 (09:19 +0000)]
Auto merge of #96964 - oli-obk:const_trait_mvp, r=compiler-errors
Replace `#[default_method_body_is_const]` with `#[const_trait]`
pulled out of #96077
related issues: #67792 and #92158
cc `@fee1-dead`
This is groundwork to only allowing `impl const Trait` for traits that are marked with `#[const_trait]`. This is necessary to prevent adding a new default method from becoming a breaking change (as it could be a non-const fn).
bors [Sun, 29 May 2022 23:25:51 +0000 (23:25 +0000)]
Auto merge of #97538 - compiler-errors:rollup-zp3ukke, r=compiler-errors
Rollup of 4 pull requests
Successful merges:
- #97493 (Use `type_is_copy_modulo_regions` check in intrisicck)
- #97518 (Fix order of closing HTML elements in rustdoc output)
- #97530 (Add more eslint checks)
- #97536 (Remove unused lifetimes from expand_macro)
bors [Sun, 29 May 2022 16:28:21 +0000 (16:28 +0000)]
Auto merge of #97214 - Mark-Simulacrum:stage0-bump, r=pietroalbini
Finish bumping stage0
It looks like the last time had left some remaining cfg's -- which made me think
that the stage0 bump was actually successful. This brings us to a released 1.62
beta though.
This now brings us to cfg-clean, with the exception of check-cfg-features in bootstrap;
I'd prefer to leave that for a separate PR at this time since it's likely to be more tricky.
cc https://github.com/rust-lang/rust/pull/97147#issuecomment-1132845061
bors [Sun, 29 May 2022 14:12:42 +0000 (14:12 +0000)]
Auto merge of #94214 - nikic:rust-opaque-pointers, r=cuviper
Prepare Rust for opaque pointers
Fix one codegen bug with opaque pointers, and update our IR tests to accept both typed pointer and opaque pointer IR. This is a bit annoying, but unavoidable if we want decent test coverage on both LLVM 14 and LLVM 15.
This prepares Rust for when LLVM will enable opaque pointers by default.
bors [Sun, 29 May 2022 05:56:09 +0000 (05:56 +0000)]
Auto merge of #96687 - jyn514:download-rustc, r=Mark-Simulacrum
Move download-rustc from python to rustbuild
- Remove download-rustc handling from bootstrap.py
- Allow a custom `pattern` in `builder.unpack()`
- Only download rustc once another part of bootstrap depends on it.
This is somewhat necessary since the download functions rely on having a full
`Builder`, which isn't available until after config parsing finishes.
Helps with https://github.com/rust-lang/rust/issues/94829.
bors [Sun, 29 May 2022 00:40:45 +0000 (00:40 +0000)]
Auto merge of #97500 - GuillaumeGomez:rollup-ms1bvps, r=GuillaumeGomez
Rollup of 5 pull requests
Successful merges:
- #96950 (Add regression test for #96395)
- #97028 (Add support for embedding pretty printers via `#[debugger_visualizer]` attribute)
- #97478 (Remove FIXME on `ExtCtxt::fn_decl()`)
- #97479 (Make some tests check-pass)
- #97482 (ptr::invalid is not equivalent to a int2ptr cast)
Guillaume Gomez [Sat, 28 May 2022 23:12:33 +0000 (01:12 +0200)]
Rollup merge of #97482 - RalfJung:ptr-invalid, r=thomcc
ptr::invalid is not equivalent to a int2ptr cast
I just realized I forgot to update these docs when adding `from_exposed_addr`.
Right now the docs say `invalid` and `from_exposed_addr` are both equivalent to a cast, and that is clearly not what we want.
Guillaume Gomez [Sat, 28 May 2022 23:12:30 +0000 (01:12 +0200)]
Rollup merge of #97478 - JohnTitor:fixme-fn-decl, r=compiler-errors
Remove FIXME on `ExtCtxt::fn_decl()`
`ExtCtxt::fn_decl()` is used like `self.fn_decl(..)` or `self.cx.fn_decl(..)`, coverting it to an assoc fn, for example, makes it inconvenience (e.g. `self.cx.fn_decl(..)` would be longer to represent). Given that, it doesn't seem a "FIXME" thing and unused `self` is okay, I think.
Guillaume Gomez [Sat, 28 May 2022 23:12:30 +0000 (01:12 +0200)]
Rollup merge of #97028 - ridwanabdillahi:pretty-printer, r=michaelwoerister
Add support for embedding pretty printers via `#[debugger_visualizer]` attribute
Initial support for [RFC 3191](https://github.com/rust-lang/rfcs/pull/3191) in PR https://github.com/rust-lang/rust/pull/91779 was scoped to supporting embedding NatVis files using a new attribute. This PR implements the pretty printer support as stated in the RFC mentioned above.
This change includes embedding pretty printers in the `.debug_gdb_scripts` just as the pretty printers for rustc are embedded today. Also added additional tests for embedded pretty printers. Additionally cleaned up error checking so all error checking is done up front regardless of the current target.
Guillaume Gomez [Sat, 28 May 2022 23:12:29 +0000 (01:12 +0200)]
Rollup merge of #96950 - JohnTitor:issue-96395, r=compiler-errors,oli-obk
Add regression test for #96395
Closes #96395
This repeats "fixed" and "ICE", see https://github.com/rust-lang/glacier/pull/1243#issuecomment-1123768138
I think it's good to add a test before regressing again.
r? ``@compiler-errors`` for quick reviiew
cc ``@oli-obk`` you might want to check as you're familiar with MIR
bors [Sat, 28 May 2022 22:24:53 +0000 (22:24 +0000)]
Auto merge of #97472 - cuviper:rebase-rustc-rayon, r=Mark-Simulacrum
Update to rebased rustc-rayon 0.4
In rayon-rs/rayon#938, miri uncovered a race in `rustc-rayon-core` that had already been fixed in the regular `rayon-core`. I have now rebased that fork onto the latest rayon branch, and published as 0.4. I also updated `indexmap` to bump the dependency.
Bryysen [Fri, 27 May 2022 13:42:15 +0000 (15:42 +0200)]
Improve error message for E0081
Previously whenever a duplicate discriminant was detected for an Enum,
we would print the discriminant bits in the diagnostic without any
casting. This caused us to display incorrect values for negative
discriminants. After this PR we format the discriminant signedness
correctly. Also reworded some of the original error
messages.
bors [Sat, 28 May 2022 16:49:52 +0000 (16:49 +0000)]
Auto merge of #97461 - eddyb:proc-macro-less-payload, r=bjorn3
proc_macro: don't pass a client-side function pointer through the server.
Before this PR, `proc_macro::bridge::Client<F>` contained both:
* the C ABI entry-point `run`, that the server can call to start the client
* some "payload" `f: F` passed to that entry-point
* in practice, this was always a (client-side Rust ABI) `fn` pointer to the actual function the proc macro author wrote, i.e. `#[proc_macro] fn foo(input: TokenStream) -> TokenStream`
In other words, the client was passing one of its (Rust) `fn` pointers to the server, which was passing it back to the client, for the client to call (see later below for why that was ever needed).
I was inspired by `@nnethercote's` attempt to remove the `get_handle_counters` field from `Client` (see https://github.com/rust-lang/rust/pull/97004#issuecomment-1139273301), which combined with removing the `f` ("payload") field, could theoretically allow for a `#[repr(transparent)]` `Client` that mostly just newtypes the C ABI entry-point `fn` pointer <sub>(and in the context of e.g. wasm isolation, that's *all* you want, since you can reason about it from outside the wasm VM, as just a 32-bit "function table index", that you can pass to the wasm VM to call that function)</sub>.
<hr/>
So this PR removes that "payload". But it's not a simple refactor: the reason the field existed in the first place is because monomorphizing over a function type doesn't let you call the function without having a value of that type, because function types don't implement anything like `Default`, i.e.:
```rust
extern "C" fn ffi_wrapper<A, R, F: Fn(A) -> R>(arg: A) -> R {
let f: F = ???; // no way to get a value of `F`
f(arg)
}
```
That could be solved with something like this, if it was allowed:
```rust
extern "C" fn ffi_wrapper<
A, R,
F: Fn(A) -> R,
const f: F // not allowed because the type is a generic param
>(arg: A) -> R {
f(arg)
}
```
Instead, this PR contains a workaround in `proc_macro::bridge::selfless_reify` (see its module-level comment for more details) that can provide something similar to the `ffi_wrapper` example above, but limited to `F` being `Copy` and ZST (and requiring an `F` value to prove the caller actually can create values of `F` and it's not uninhabited or some other unsound situation).
<hr/>
Hopefully this time we don't have a performance regression, and this has a chance to land.
bors [Sat, 28 May 2022 14:30:25 +0000 (14:30 +0000)]
Auto merge of #97383 - dingxiangfei2009:restore-region-scope-tree-query, r=dingxiangfei2009
Try to cache region_scope_tree as a query
This PR will attempt to restore `region_scope_tree` as a query so that caching works again. It seems that `region_scope_tree` could be re-computed for nested items after all, which could explain the performance regression introduced by #95563.
cc `@Mark-Simulacrum` `@pnkfelix` I will try to trigger a perf run here.
bors [Sat, 28 May 2022 11:49:42 +0000 (11:49 +0000)]
Auto merge of #97158 - JakobDegen:dse, r=tmiasko,cjgillot
Split dead store elimination off dest prop
This splits off a part of #96451 . I've added this in as its own pass for now, so that it actually runs, can be tested, etc. In the dest prop PR, I'll stop invoking this as its own pass, so that it doesn't get invoked twice.
Dylan DPC [Sat, 28 May 2022 06:45:52 +0000 (08:45 +0200)]
Rollup merge of #97327 - davidtwco:diagnostic-translation-compile-time-validation, r=oli-obk
macros: introduce `fluent_messages` macro
Adds a new `fluent_messages` macro which performs compile-time validation of the compiler's Fluent resources (i.e. that the resources parse and don't multiply define the same messages) and generates constants that make using those messages in diagnostics more ergonomic.
For example, given the following invocation of the macro..
```fluent
typeck-field-multiply-specified-in-initializer =
field `{$ident}` specified more than once
.label = used more than once
.label-previous-use = first use of `{$ident}`
```
...then the macro parse the Fluent resource, emitting a diagnostic if it fails to do so...
```text
error: could not parse Fluent resource
--> $DIR/test.rs:35:28
|
LL | missing_message => "./missing-message.ftl",
| ^^^^^^^^^^^^^^^^^^^^^^^
|
= help: see additional errors emitted
error: expected a message field for "missing-message"
--> ./missing-message.ftl:1:1
|
1 | missing-message =
| ^^^^^^^^^^^^^^^^^^
|
```
...or generating the following code if it succeeds:
I'd like to reduce the verbosity of referring to labels/notes/helps with this scheme (though it wasn't much better before), but I'll leave that for a follow-up.
Dylan DPC [Sat, 28 May 2022 06:45:51 +0000 (08:45 +0200)]
Rollup merge of #97034 - fee1-dead-contrib:layout-hash, r=dtolnay
Implement `Hash` for `core::alloc::Layout`
This was brought up on [reddit](https://www.reddit.com/r/rust/comments/uoypui/the_standard_library_types_are_good_except_when/), and I don't see why Layout shouldn't implement `Hash`. Feel free to comment if I am wrong though :)
Dylan DPC [Sat, 28 May 2022 06:45:50 +0000 (08:45 +0200)]
Rollup merge of #94640 - Pointerbender:issue-71146-partial-stabilization, r=yaahc
Partially stabilize `(const_)slice_ptr_len` feature by stabilizing `NonNull::len`
This PR partially stabilizes features `const_slice_ptr_len` and `slice_ptr_len` by only stabilizing `NonNull::len`. This partial stabilization is tracked under features `slice_ptr_len_nonnull` and `const_slice_ptr_len_nonnull`, for which this PR can serve as the tracking issue.
To summarize the discussion from #71146 leading up to this partial stabilization request:
It's currently a bit footgunny to obtain the length of a raw slice pointer, stabilization of `NonNull:len` will help with removing these footguns. Some example footguns are:
```rust
/// # Safety
/// The caller must ensure that `ptr`:
/// 1. does not point to memory that was previously allocated but is now deallocated;
/// 2. is within the bounds of a single allocated object;
/// 3. does not to point to a slice for which the length exceeds `isize::MAX` bytes;
/// 4. points to a properly aligned address;
/// 5. does not point to uninitialized memory;
/// 6. does not point to a mutably borrowed memory location.
pub unsafe fn ptr_len<T>(ptr: core::ptr::NonNull<[T]>) -> usize {
(&*ptr.as_ptr()).len()
}
```
A slightly less complicated version (but still more complicated than it needs to be):
```rust
/// # Safety
/// The caller must ensure that the start of `ptr`:
/// 1. does not point to memory that was previously allocated but is now deallocated;
/// 2. must be within the bounds of a single allocated object.
pub unsafe fn ptr_len<T>(ptr: NonNull<[T]>) -> usize {
(&*(ptr.as_ptr() as *const [()])).len()
}
```
This PR does not stabilize `<*const [T]>::len` and `<*mut [T]>::len` because the tracking issue #71146 list a potential blocker for these methods, but this blocker [does not apply](https://github.com/rust-lang/rust/issues/71146#issuecomment-808735714) to `NonNull::len`.
We should probably also ping the [Constant Evaluation WG](https://github.com/rust-lang/const-eval) since this PR includes a `#[rustc_allow_const_fn_unstable(const_slice_ptr_len)]`. My instinct here is that this will probably be okay because the pointer is not actually dereferenced and `len()` does not touch the address component of the pointer, but would be best to double check :)
One potential down-side was raised that stabilizing `NonNull::len` could lead to encouragement of coding patterns like:
which unnecessarily assert non-nullness. However, these are much less of a footgun than the above examples and this should be resolved when `slice_ptr_len` fully stabilizes eventually.
bors [Sat, 28 May 2022 04:04:29 +0000 (04:04 +0000)]
Auto merge of #97284 - b-naber:constraint-dyn-impl-suggestion, r=estebank
Add suggestion for relaxing static lifetime bounds on dyn trait impls in NLL
This PR introduces suggestions for relaxing static lifetime bounds on impls of dyn trait items for NLL similar to what is already available in lexical region diagnostics.
bors [Fri, 27 May 2022 23:17:18 +0000 (23:17 +0000)]
Auto merge of #97468 - matthiaskrgr:rollup-8cu0hqr, r=matthiaskrgr
Rollup of 6 pull requests
Successful merges:
- #95214 (Remove impossible panic note from `Vec::append`)
- #97411 (Print stderr consistently)
- #97453 (rename `TyKind` to `RegionKind` in comment in rustc_middle)
- #97457 (Add regression test for #81899)
- #97458 (Modify `derive(Debug)` to use `Self` in struct literal to avoid redundant error)
- #97462 (Add more eslint rules)
I tried to follow what I perceived as the general consensus for error messages in boostrap i.e messages that were ..
* resulting from an Err(...) =>
* literally called as "Error: ...."
* by the end of the block scope forced to run a panic! or process::exit with a guaranteed non-zero error code.