Auto merge of #99796 - compiler-errors:issue-53475, r=oli-obk
use `check_region_obligations_and_report_errors` to avoid ICEs
If we don't call `process_registered_region_obligations` before `resolve_regions_and_report_errors` then we'll ICE if we have any region obligations, and `check_region_obligations_and_report_errors` just does both of these for us in a nice convenient function.
* openssl-probe v0.1.2 -> v0.1.5 updates ancient (2017) crate (https://github.com/alexcrichton/openssl-probe/compare/0.1.2...0.1.5). Adds support to search cert for additional platforms.
* diff v0.1.12 -> v0.1.13 (https://github.com/utkarshkukreti/diff.rs/compare/0.1.12...0.1.13) Few optimizations (https://github.com/utkarshkukreti/diff.rs/pull/16, https://github.com/utkarshkukreti/diff.rs/commit/0f0aa580f197af7dab9ab905568f70a2387e23bc)
* ignore v0.4.17 -> v0.4.18 (it's hard to get usable diff, but most notable perf change is https://github.com/BurntSushi/ripgrep/commit/a28e664abd0d8912e4a2d85039fe282b9d37b994)
* globset v0.4.5 -> v0.4.9
* regex v1.5.5 -> v1.5.6 few bugfixes (https://github.com/rust-lang/regex/blob/1.5.6/CHANGELOG.md#156-2022-05-20). There exist 1.6.0 version, but it's too fresh.
Auto merge of #99123 - mystor:crossbeam_bridge, r=eddyb
proc_macro: use crossbeam channels for the proc_macro cross-thread bridge
This is done by having the crossbeam dependency inserted into the `proc_macro` server code from the server side, to avoid adding a dependency to `proc_macro`.
In addition, this introduces a -Z command-line option which will switch rustc to run proc-macros using this cross-thread executor. With the changes to the bridge in #98186, #98187, #98188 and #98189, the performance of the executor should be much closer to same-thread execution.
In local testing, the crossbeam executor was substantially more performant than either of the two existing `CrossThread` strategies, so they have been removed to keep things simple.
Auto merge of #99925 - JohnTitor:rollup-4bt9ou3, r=JohnTitor
Rollup of 8 pull requests
Successful merges:
- #99227 (Fix thumbv4t-none-eabi frame pointer setting)
- #99518 (Let-else: break out scopes when a let-else pattern fails to match)
- #99671 (Suggest dereferencing index when trying to use a reference of usize as index)
- #99831 (Add Fuchsia platform support documentation)
- #99881 (fix ICE when computing codegen_fn_attrs on closure with non-fn parent)
- #99888 (Streamline lint checking)
- #99891 (Adjust an expr span to account for macros)
- #99904 (Cleanup html whitespace)
Rollup merge of #99904 - GuillaumeGomez:cleanup-html-whitespace, r=notriddle
Cleanup html whitespace
I realized while looking at the raw HTML that we generated some unwanted white space characters. This PR cleans up the one coming directly from rustdoc. I'll check from `pulldown-cmark` for the remaining ones.
Some numbers now: the difference is small, it goes from `63009` to `62859`. But multiplied by the number of files, it becomes quite interesting overall.
Rollup merge of #99888 - nnethercote:streamline-visitors, r=cjgillot
Streamline lint checking
The early (AST) and late (HIR) lint checkers have a number of functions that aren't used by rustc or clippy. Might as well remove them -- it's not like there's a canonical API here, as shown by the ad hoc use of `check_foo`/`check_foo_post` combinations.
Rollup merge of #99227 - Lokathor:fix-thumbv4t-none-eabi-frame-pointer, r=davidtwco
Fix thumbv4t-none-eabi frame pointer setting
The `thumb_base` profile has changed since I last remember seeing it, and now it sets the frame pointer to "always keep", which is not desired for this target. Hooking a debugger to the running program is not really done, it's preferable to have the register available for actual program use, so the default "may omit" is now set.
I thought that the target was already using "may omit" when I checked on it last month, because I forgot that the target was previously based on `thumb_base` rather than `Default::default()`. I only noticed the issue just now when creating the `armv4t-none-eabi` target (https://github.com/rust-lang/rust/pull/99226), though this PR is not in any way conditional on that one.
Nika Layzell [Sat, 18 Jun 2022 18:15:03 +0000 (14:15 -0400)]
proc_macro: use crossbeam channels for the proc_macro cross-thread bridge
This is done by having the crossbeam dependency inserted into the
proc_macro server code from the server side, to avoid adding a
dependency to proc_macro.
In addition, this introduces a -Z command-line option which will switch
rustc to run proc-macros using this cross-thread executor. With the
changes to the bridge in #98186, #98187, #98188 and #98189, the
performance of the executor should be much closer to same-thread
execution.
In local testing, the crossbeam executor was substantially more
performant than either of the two existing CrossThread strategies, so
they have been removed to keep things simple.
Auto merge of #99577 - est31:remove_box_librustdoc, r=jsha
Remove remaining uses of box syntax from librustdoc
Remove the remaining uses of box syntax from librustdoc. Followup of #99066 where these changes were split out because they were responsible for a small but noticeable regression. This PR avoids the regression by boxing some large variants of `ItemKind` to reduce the enum's size by half from 224 bytes to 112 bytes (on x86-64). This should also help with reducing memory usage.
Auto merge of #99892 - JohnTitor:rollup-qi4fem8, r=JohnTitor
Rollup of 8 pull requests
Successful merges:
- #99686 (add suggestion when there is a impl of external trait on pointer with wrong coherence rules)
- #99760 (doc/rustc: describe the uefi target platforms)
- #99766 (Htmldocck: Substitute the doc channel when blessing)
- #99781 (Use String::from_utf8_lossy in CStr demo)
- #99803 (Update mentions to `rustc_metadata::rmeta::Lazy`)
- #99845 (Remove `$` prefix for bash scripts in doc)
- #99850 (rustdoc: Remove more Clean trait implementations)
- #99872 (Clone the `src/llvm-project` submodule if profiling is enabled)
Rollup merge of #99872 - Nilstrieb:bootstrap-llvm, r=jyn514
Clone the `src/llvm-project` submodule if profiling is enabled
To compile rustc with profiling information, `compiler-rt` from LLVM is required. Building it requires the `src/llvm-project` submodule to be initialized and updated.
Rollup merge of #99803 - JohnTitor:update-lazy-docs, r=compiler-errors
Update mentions to `rustc_metadata::rmeta::Lazy`
While working on https://github.com/rust-lang/rustc-dev-guide/pull/1411, I noticed there are still some mentions of `Lazy`. This updates them to `LazyValue`, `LazyArray`, or `LazyTable`.
Rollup merge of #99766 - fmease:htmldocck-subst-channel-when-blessing, r=Mark-Simulacrum
Htmldocck: Substitute the doc channel when blessing
Since #84942, the snippet `{{channel}}` gets substituted with the concrete “doc channel” (e.g. `https://doc.rust-lang.org/nightly`) when snapshot files are checked against the actual rustdoc output.
However, when you `--bless` rustdoc tests, htmldocck just dumps the concrete channel into the snapshot file and
you have to manually do a find-and-replace after blessing to uphold what #84942 set out to fix.
I admit it's a bit fragile to blindly replace URLs like this but I guess it's not too bad in practice.
Feel free to close this PR if you don't think that this is a good idea.
Rollup merge of #99760 - dvdhrm:rw/uefiplat, r=ehuss
doc/rustc: describe the uefi target platforms
Add a `platform-support` entry to the rustc-docs for the different `*-unknown-uefi` targets. This describes in detail how this platform works, a few basic examples, and how to compile for the platform.
Red Hat is sponsoring my work on this platform, so I am putting myself down as target maintainer. Co-maintainers are more than welcome to join me in the effort. Communication is going on off-list to coordinate the different efforts.
Note that the ultimate goal is to move the UEFI targets to Tier-2 so bootloaders can be more easily supported in commercial products. This documentation is the first step towards that goal, but should be a viable documentation even for the current Tier-3 status of the targets.
I also want to point out that there is an ongoing GSoC-effort to port the rust standard library to UEFI (by Ayush Singh). While this work is not necessarily required to get to Tier-2, we definitely should coordinate the efforts and update the documentation as soon as any such ports are merged.
Note that the targets are already used by multiple commercial and non commercial production systems, including, but not limited to:
* Tianocore-EDK2 (Official UEFI SDK by Intel) comes with rust support
in its staging repository (not part of any release, yet).
(https://github.com/tianocore/edk2-staging/tree)
* Intel's research program "Project Mu" uses the rust UEFI targets to
show possible future replacements for Tianocore-EDK2.
* The Rust OS "Redox" uses the UEFI targets for its bootloader.
(https://www.redox-os.org/)
* The hugely popular in-depth documentation of OS development in Rust
by Philipp Oppermann uses the UEFI targets.
(https://os.phil-opp.com/)
Auto merge of #99660 - PrestonFrom:issue_99265, r=compiler-errors
Generate correct suggestion with named arguments used positionally
Address issue #99265 by checking each positionally used argument
to see if the argument is named and adding a lint to use the name
instead. This way, when named arguments are used positionally in a
different order than their argument order, the suggested lint is
correct.
For example:
```
println!("{b} {}", a=1, b=2);
```
This will now generate the suggestion:
```
println!("{b} {a}", a=1, b=2);
```
Additionally, this check now also correctly replaces or inserts
only where the positional argument is (or would be if implicit).
Also, width and precision are replaced with their argument names
when they exists.
Since the issues were so closely related, this fix for issue #99265
also fixes issue #99266.
Auto merge of #99512 - nikic:llvm-15-fixes, r=cuviper
LLVM 15 compatibility fixes
These are LLVM 15 compatibility fixes split out from #99464. There are three changes here:
* Emit elementtype attribtue for ldrex/strex intrinsics. This is requires as part of the opaque pointers migration.
* Make more tests compatible with opaque pointers. These are either new or aren't run on x86.
* Remove a test for `#[rustc_allocator]`. Since #99574 there are more requirement on the function signature. I dropped the test entirely, since we already test the effect of the attribute elsewhere.
* The main change: When a worker thread emits an error, wait for other threads to finish before unwinding the main thread and exiting. Otherwise workers may end up using globals for which destructors have already been run. This was probably never quite correct, but became an active problem with LLVM 15, because it started using global dtors in critical places, as part of ManagedStatic removal.
Clone the `src/llvm-project` submodule if profiling is enabled
To compile rustc with profiling information, `compiler-rt` from
LLVM is required. Building it requires the `src/llvm-project` submodule
to be initialized and updated.
Auto merge of #99863 - Dylan-DPC:rollup-lq9w047, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #99628 (add more docs regarding ideographic numbers)
- #99689 (Revert `write!` and `writeln!` to late drop temporaries)
- #99807 (Fix PermissionDenied UI tests on WSL)
- #99817 (rustdoc: remove Clean trait impls for more items)
- #99851 (Fix small typo in Cargo.toml comment)
- #99856 (fix: remove fake no_dead_strip for osx)
Link arg `-no_dead_strip` doesn't exist on OSX at all.
The `no_gc_sections` function was never called before export-executable-symols implementation, and `export-executable-symbols` still works, so we just remove it.
r? `@bjorn3`
Auto merge of #99780 - Nilstrieb:mir-opt-test-line-no, r=oli-obk
Use line numbers relative to the function in mir-opt tests
As shown in #99770, the line numbers can be a big source of needless and confusing diffs. This PR adds a new flag `-Zmir-pretty-relative-line-numbers` to make them relative to the function declaration, which avoids most needless diffs from attribute changes.
`@JakobDegen` told me that there has been a zulip conversation about disabling line numbers with mixed opinions, so I'd like to get some feedback here, for this hopefully better solution.
Auto merge of #99756 - fasterthanlime:ra-sync-and-pms-component, r=Mark-Simulacrum
Sync `rust-analyzer`, add `rust-analyzer-proc-macro-srv` binary to Rustc component
As discussed earlier with `@jyn514` and `@pietroalbini,` I'm also going to use this PR to have `dist::Rustc` build the `rust-analyzer-proc-macro-srv` binary introduced in:
Auto merge of #99182 - RalfJung:mitigate-uninit, r=scottmcm
mem::uninitialized: mitigate many incorrect uses of this function
Alternative to https://github.com/rust-lang/rust/pull/98966: fill memory with `0x01` rather than leaving it uninit. This is definitely bitewise valid for all `bool` and nonnull types, and also those `Option<&T>` that we started putting `noundef` on. However it is still invalid for `char` and some enums, and on references the `dereferenceable` attribute is still violated, so the generated LLVM IR still has UB -- but in fewer cases, and `dereferenceable` is hopefully less likely to cause problems than clearly incorrect range annotations.
This can make using `mem::uninitialized` a lot slower, but that function has been deprecated for years and we keep telling everyone to move to `MaybeUninit` because it is basically impossible to use `mem::uninitialized` correctly. For the cases where that hasn't helped (and all the old code out there that nobody will ever update), we can at least mitigate the effect of using this API. Note that this is *not* in any way a stable guarantee -- it is still UB to call `mem::uninitialized::<bool>()`, and Miri will call it out as such.
This is somewhat similar to https://github.com/rust-lang/rust/pull/87032, which proposed to make `uninitialized` return a buffer filled with 0x00. However
- That PR also proposed to reduce the situations in which we panic, which I don't think we should do at this time.
- The 0x01 bit pattern means that nonnull requirements are satisfied, which (due to references) is the most common validity invariant.
`@5225225` I hope I am using `cfg(sanitize)` the right way; I was not sure for which ones to test here.
Cc https://github.com/rust-lang/rust/issues/66151
Fixes https://github.com/rust-lang/rust/issues/87675
projects / rust.git / log