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 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.
bors [Fri, 27 May 2022 18:28:12 +0000 (18:28 +0000)]
Auto merge of #96790 - lqd:update_jemalloc, r=Mark-Simulacrum
Update jemalloc to v5.3
Now that `jemalloc` version 5.3 has been released, this PR updates `tikv-jemalloc-sys` to the corresponding release.
The crates.io publishing issue seems to have been resolved for the `jemalloc-sys` package, and version 5.3.0 is now also available under the historical name (and should become the preferred crate to be used). Therefore, this PR also switches back to using `jemalloc-sys` instead of `tikv-jemalloc-sys`.
bors [Fri, 27 May 2022 08:50:51 +0000 (08:50 +0000)]
Auto merge of #97442 - hafeoz:master, r=GuillaumeGomez
Fix multiline attributes processing in doctest
Fixes #97440.
It seems like the call to `check_if_attr_is_complete` is not provided with the correct argument: the pending attribute should be passed, while the current line is actually being passed. This causes any attribute with more than 2 lines to fail and produces ICE when running through doctest.
Matthias Krüger [Thu, 26 May 2022 18:59:42 +0000 (20:59 +0200)]
Rollup merge of #97354 - GuillaumeGomez:browser-ui-test-update, r=notriddle
Updates to browser-ui-test
I took the commits from #97317. Since the ubuntu 22.04 version, you either need to use `--no-sandbox` or use another binary to run the GUI tests. I couldn't find out why the chromium used by `browser-ui-test` isn't working anymore on this ubuntu version.
Matthias Krüger [Thu, 26 May 2022 18:59:40 +0000 (20:59 +0200)]
Rollup merge of #96033 - yaahc:expect-elaboration, r=scottmcm
Add section on common message styles for Result::expect
Based on a question from https://github.com/rust-lang/project-error-handling/issues/50#issuecomment-1092339937
~~One thing I haven't decided on yet, should I duplicate this section on `Option::expect`, link to this section, or move it somewhere else and link to that location from both docs?~~: I ended up moving the section to `std::error` and referencing it from both `Result::expect` and `Option::expect`'s docs.
I think this section, when combined with the similar update I made on [`std::panic!`](https://doc.rust-lang.org/nightly/std/macro.panic.html#when-to-use-panic-vs-result) implies that we should possibly more aggressively encourage and support the "expect as precondition" style described in this section. The consensus among the libs team seems to be that panic should be used for bugs, not expected potential failure modes. The "expect as error message" style seems to align better with the panic for unrecoverable errors style where they're seen as normal errors where the only difference is a desire to kill the current execution unit (aka erlang style error handling). I'm wondering if we should be providing a panic hook similar to `human-panic` or more strongly recommending the "expect as precondition" style of expect message.
bors [Thu, 26 May 2022 15:29:01 +0000 (15:29 +0000)]
Auto merge of #97046 - conradludgate:faster-ascii-case-conv-path, r=thomcc
improve case conversion happy path
Someone shared the source code for [Go's string case conversion](https://github.com/golang/go/blob/19156a54741d4f353c9e8e0860197ca95a6ee6ca/src/strings/strings.go#L558-L616).
It features a hot path for ascii-only strings (although I assume for reasons specific to go, they've opted for a read safe hot loop).
I've borrowed these ideas and also kept our existing code to provide a fast path + seamless utf-8 correct path fallback.
(Naive) Benchmarks can be found here https://github.com/conradludgate/case-conv
For the cases where non-ascii is found near the start, the performance of this algorithm does fall back to original speeds and has not had any measurable speed loss
bors [Thu, 26 May 2022 11:15:15 +0000 (11:15 +0000)]
Auto merge of #97168 - SparrowLii:accesses, r=cjgillot
omit `record_accesses` function when collecting `MonoItem`s
This PR fixes the FIXME in the impl of `record_accesses` function.
[Edit] We can call `instantiation_mode` when push the `MonoItem` into `neighbors`. This avoids extra local variables `accesses: SmallVec<[_; 128]>`
`imported_source_files` adjusts lots of file positions, and then calls
`new_imported_source_file`, which then adjust them all again. This
commit combines the two adjustments into one, for a small perf win.
Guillaume Gomez [Wed, 25 May 2022 22:32:12 +0000 (00:32 +0200)]
Rollup merge of #97407 - ehuss:update-books, r=ehuss
Update books
## reference
6 commits in 8e36971959ff238b5aa2575fbc7a2e09e1313e82..b74825d8f88b685e239ade00f00de68ba4cd63d4
2022-05-09 17:20:59 -0700 to 2022-05-20 14:30:30 -0700
- Inline assembly: Clarify references to quoted regs (rust-lang/reference#1191)
- Add tile registers to inline-assembly documentation (rust-lang/reference#1220)
- Upper bound on hashes in raw string literals (rust-lang/reference#1180)
- Remove footnote on warning about lifetime shadowing labels.
- Makes explanation for Spans in "Procedural Macros" clearer (rust-lang/reference#1219)
- Update "Match Expressions" to remove 'cold' (rust-lang/reference#1216)
## book
18 commits in d9415b7cbfcb4b24062683f429bd0ff535396362..b4dd5f00b87190ad5ef42cbc2a88a783c6ae57ef
2022-05-09 09:10:44 -0400 to 2022-05-24 21:37:06 -0400
- Snapshot of appendices for nostarch
- Update rust-analyzer URLs and make links less repetitive
- Correct byte string literal type. Fixes rust-lang/book#2631.
- Fix verb agreement. Fixes rust-lang/book#3176
- Propagate ch19 edits to src
- Edits to chapter 19 from nostarch
- Propagate ch18 edits to src
- Edits to ch18 from nostarch
- Propagate tech review edits to src ch5
- Responses to chapter 5 tech review
- Ch5 after tech review
- Merge branch 'ch7-edits'
- fix: mdBook authors
- Propagating ch17 edits to src
- Edits from nostarch for ch17
- Fix rust-lang/book#3152 - Wrong character used
- & is not valid inside image alt text
- Merge branch 'ch20'
11 commits in 0c02acdb6f48f03907a02ea8e537c3272b4fde9f..554c00e4805df7f7bffac7db408437d62d6dfb9a
2022-05-10 09:45:31 -0300 to 2022-05-24 17:15:35 -0700
- Cleanup rustdoc-internals
- Fix some wording on the "Incremental Compilation In Detail" page
- Exclude `tomlee.co` from link-checking (rust-lang/rustc-dev-guide#1356)
- Add note about patching dependencies and warnings. (rust-lang/rustc-dev-guide#1354)
- make sentence more simple (rust-lang/rustc-dev-guide#1353)
- Update some links and docs (rust-lang/rustc-dev-guide#1340)
- Replace a broken YouTube link (rust-lang/rustc-dev-guide#1295)
- Edit the "Compiler Source Code" chapter (rust-lang/rustc-dev-guide#1307)
- Add docs for logging of queries. (rust-lang/rustc-dev-guide#1350)
- Fix configuration names for vscode/r-a (rust-lang/rustc-dev-guide#1352)
- Update docs for deprecated attribute (rust-lang/rustc-dev-guide#1338)
Guillaume Gomez [Wed, 25 May 2022 22:32:10 +0000 (00:32 +0200)]
Rollup merge of #97375 - petrochenkov:zgccld, r=bjorn3
Simplify implementation of `-Z gcc-ld`
- The logic is now unified for all targets (wasm targets should also be supported now)
- Additional "symlink" files like `ld64` are eliminated
- lld-wrapper is used for propagating the correct lld flavor
- Cleanup "unwrap or exit" logic in lld-wrapper
cc https://github.com/rust-lang/rust/issues/97352
r? `@bjorn3`
- The logic is now unified for all targets (wasm targets should also be supported now)
- Additional "symlink" files like `ld64` are eliminated
- lld-wrapper is used for propagating the correct lld flavor
- Cleanup "unwrap or exit" logic in lld-wrapper
* doc: discuss build script instruction order (rust-lang/cargo#10600)
* Require http-registry URLs to end with a '/' (rust-lang/cargo#10698)
* No printing executable names when running tests and benchmarks with json message format (rust-lang/cargo#10691)
* Restore proper error for crate not in local reg (rust-lang/cargo#10683)
* Update libcurl (rust-lang/cargo#10696)
* Fixed small typos (rust-lang/cargo#10693)
* fix bugs with `workspace` key and `update_toml` (rust-lang/cargo#10685)
* Bump to 0.64.0, update changelog (rust-lang/cargo#10687)
* List C compiler as a build dependency in README (rust-lang/cargo#10678)
* Add unstable `rustc-check-cfg` build script output (rust-lang/cargo#10539)