Rollup merge of #102032 - andrewpollack:bad-signal-compiler-tests, r=tmandry
Adding ignore fuchsia tests for signal interpretation cases
Tests where Signal interpreting is required. Since Fuchsia currently does not return signals of type `libc::SIGSEGV` etc., instead, use generalized `!status.success()` case.
Rollup merge of #102030 - est31:tidy_walk_no_reexport, r=Mark-Simulacrum
Don't crate-locally reexport walk functions in tidy
I've moved the walk functions into their own module in #100591 and didn't want to make changing the paths everywhere in tidy part of the PRs diff, so I just reexported the functions locally. This PR removes the crate-local reexport and instead does module level reexports. I'm not sure how much it's worth it and whether the new state is better, idk. Feel free to have any opinion on this.
Rollup merge of #101952 - Mark-Simulacrum:missing-fallback, r=ehuss
Avoid panicking on missing fallback
This just prints a message but continues on if a fallback is missing, which can happen when we're building a partial set of builders and producing a dev-static build from it (e.g., when no Apple builder runs at all).
Probably the more extensive fix is to allow the build-manifest invoker to specify the expected set of targets & hosts, but that's a far more extensive change. The main risk from this is that we accidentally start falling back to linux docs across all platforms without noticing. I'm not sure that we can do much about that though at this time.
cc `@ehuss` since IIRC you participated in adding this system
This comes up when building a test nightly from a try build, e.g., https://github.com/rust-lang/rust/pull/101855#issuecomment-1250123298. For now I'm going to manually cherry pick this onto that PR for testing purposes.
Auto merge of #101558 - JhonnyBillM:session-diagnostic-to-diagnostic-handler-refactor, r=davidtwco
Move and rename `SessionDiagnostic` & `SessionSubdiagnostic` traits and macros
After PR #101434, we want to:
- [x] Move `SessionDiagnostic` to `rustc_errors`.
- [x] Add `emit_` methods that accept `impl SessionDiagnostic` to `Handler`.
- [x] _(optional)_ Rename trait `SessionDiagnostic` to `DiagnosticHandler`.
- [x] _(optional)_ Rename macro `SessionDiagnostic` to `DiagnosticHandler`.
- [x] Update Rustc Dev Guide and Docs to reflect these changes. https://github.com/rust-lang/rustc-dev-guide/pull/1460
Now I am having build issues getting the compiler to build when trying to rename the macro.
<details>
<summary>See diagnostics errors and context when building.</summary>
```
error: diagnostics should only be created in `SessionDiagnostic`/`AddSubdiagnostic` impls
--> compiler/rustc_attr/src/session_diagnostics.rs:13:10
|
13 | #[derive(DiagnosticHandler)]
| ^^^^^^^^^^^^^^^^^ in this derive macro expansion
|
::: /Users/jhonny/.cargo/registry/src/github.com-1ecc6299db9ec823/synstructure-0.12.6/src/macros.rs:94:9
|
94 | / pub fn $derives(
95 | | i: $crate::macros::TokenStream
96 | | ) -> $crate::macros::TokenStream {
| |________________________________________- in this expansion of `#[derive(DiagnosticHandler)]`
|
note: the lint level is defined here
--> compiler/rustc_attr/src/lib.rs:10:9
|
10 | #![deny(rustc::diagnostic_outside_of_impl)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
And also this one:
```
error: diagnostics should only be created in `SessionDiagnostic`/`AddSubdiagnostic` impls
--> compiler/rustc_attr/src/session_diagnostics.rs:213:32
|
213 | let mut diag = handler.struct_span_err_with_code(
| ^^^^^^^^^^^^^^^^^^^^^^^^^
```
> **Note**
> Can't find where this message is coming from, because you can see in [this experimental branch](https://github.com/JhonnyBillM/rust/tree/experimental/trying-to-rename-session-diagnostic-macro) that I updated all errors and diags to say:
> error: diagnostics should only be created in **`DiagnosticHandler`**/`AddSubdiagnostic` impls
> and not:
> error: diagnostics should only be created in **`SessionDiagnostic`**/`AddSubdiagnostic` impls
</details>
I tried building the compiler in different ways (playing with the stages etc), but nothing worked.
## Question
**Do we need to build or do something different when renaming a macro and identifiers?**
For context, see experimental commit https://github.com/JhonnyBillM/rust/commit/f2193a98b44db3f2af77a878824b152cdf0d34a5 where the macro and symbols are renamed, but it doesn't compile.
Rollup merge of #102058 - mqudsi:path_extension_docs, r=thomcc
Clarify Path::extension() semantics in docs abstract
State up-front and center what shape the returned extension will have, without making the user read through the description and examples.
This is a doc-only change. There are no changes to the API contract and the clarification is in line with what was already stated/promised in the existing doc text - just clarified, summarized, and served bright and early.
Rationale: Various frameworks and libraries for different platforms have their different conventions as to whether an "extension" is ".ext" or just "ext" and anyone that's had to deal with this ambiguity in the past is always double- or triple-checking to make sure the function call returns an extension that matches the expected semantics. Offer the answer to this important question right off the bat instead of making them dig to find it.
Rollup merge of #102045 - RalfJung:const-prop-regression-fix, r=oli-obk
fix ConstProp handling of written_only_inside_own_block_locals
Fixes a regression introduced by https://github.com/rust-lang/rust/pull/100239, which adds an early return and thus skips some code in `visit_terminator` that must be run for soundness.
Rollup merge of #102031 - andrewpollack:compiler-tests-backtrace, r=tmandry
Adding ignore fuchsia tests for Backtrace, ErrorKind cases
Tests where Backtrace parses are required (invalid since Fuchsia backtraces are not symbolized), and test where ErrorKind is not properly translated from a Fuchsia-style to Unix-style error code
Auto merge of #101329 - QuinnPainter:armv5te-targets, r=nagisa
Add armv5te-none-eabi and thumbv5te-none-eabi targets
Creates two new Tier 3 targets, `armv5te-none-eabi` and `thumbv5te-none-eabi`. They are for the same target architecture (armv5te), but one defaults to the A32 instruction set and the other defaults to T32. Based on the existing `armv4t-none-eabi` and `thumbv4t-none-eabi` targets.
My particular use case for these targets is Nintendo DS homebrew, but they should be usable for any armv5te system.
Going through the Tier 3 target policy:
> A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)
That will be me.
> Targets must use naming consistent with any existing targets.
Naming is consistent with previous targets.
>> Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility.
No ambiguity here.
> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
Doesn't create any legal issues.
>> The target must not introduce license incompatibilities.
This doesn't introduce any new licenses.
>> Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).
Yep.
>> The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements.
No new license requirements.
>> Compiling, linking, and emitting functional binaries, libraries, or other code for the target (whether hosted on the target itself or cross-compiling from another target) must not depend on proprietary (non-FOSS) libraries.
Everything this uses is FOSS, no proprietary required.
> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
OK.
>> This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements.
OK.
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.
This is a bare-metal target with only support for `core` (and `alloc`, if the user provides an allocator).
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary.
Documentation has been added.
> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
OK.
> Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.
OK.
> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
This doesn't break any other targets.
>> In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target.
Auto merge of #100096 - compiler-errors:fn-return-must-be-sized, r=jackh726
a fn pointer doesn't implement `Fn`/`FnMut`/`FnOnce` if its return type isn't sized
I stumbled upon #83915 which hasn't received much attention recently, and I wanted to revive it since this is one existing soundness hole that seems pretty easy to fix.
I'm not actually sure that the [alternative approach described here](https://github.com/rust-lang/rust/pull/83915#issuecomment-823643322) is sufficient, given the `src/test/ui/function-pointer/unsized-ret.rs` example I provided below. Rebasing the branch mentioned in that comment and testing that UI test, it seems that we actually end up only observing that `str: !Sized` during monomorphization, whereupon we ICE. Even if we were to fix that ICE, ideally we'd be raising an error that a fn pointer is being used badly during _typecheck_ instead of monomorphization, hence adapting the original approach in #83915.
I am happy to close this if people would prefer we rebase the original PR and land that -- I am partly opening to be annoying and get people thinking about this unsoundness again :heart: :smile_cat:
cc: `@estebank` and `@nikomatsakis`
r? types
Here's a link to the thread: https://rust-lang.zulipchat.com/#narrow/stream/144729-t-types/topic/PR.20.2383915/near/235421351 for more context.
It's now much more like the `-Zhir-stats` output.
- Each line is preceded with `meta-stats`, which makes the provenance
clearer and allows filtering of the output.
- Sections are now sorted in reverse order of size.
- Column headings avoid the need to repeat the word "bytes" on every line.
- Long numbers now have `_` separators for easier reading.
- Consistent use of '-' within section labels, rather than a mix of '-',
'_', and ' '.
The code itself is shorter and easier to read thanks to:
- the `stat` macro, which encapsulates each section's encoding, avoids
some boilerplate, and removes the need for some low-value comments;
- the `stats` vector, which replaces dozens of local variables.
Auto merge of #100214 - scottmcm:strict-range, r=thomcc
Optimize `array::IntoIter`
`.into_iter()` on arrays was slower than it needed to be (especially compared to slice iterator) since it uses `Range<usize>`, which needs to handle degenerate ranges like `10..4`.
This PR adds an internal `IndexRange` type that's like `Range<usize>` but with a safety invariant that means it doesn't need to worry about those cases -- it only handles `start <= end` -- and thus can give LLVM more information to optimize better.
I added one simple demonstration of the improvement as a codegen test.
(`vec::IntoIter` uses pointers instead of indexes, so doesn't have this problem, but that only works because its elements are boxed. `array::IntoIter` can't use pointers because that would keep it from being movable.)
Mark Rousskov [Sat, 17 Sep 2022 22:13:59 +0000 (18:13 -0400)]
Avoid panicking on missing fallback
This just prints a message but continues on if a fallback is missing,
which can happen when we're building a partial set of builders and
producing a dev-static build from it (e.g., when no Apple builder runs
at all).
Probably the more extensive fix is to allow the build-manifest invoker
to specify the expected set of targets & hosts, but that's a far more
extensive change. The main risk from this is that we accidentally start
falling back to linux docs across all platforms without noticing. I'm
not sure that we can do much about that though at this time.
Auto merge of #100581 - joboet:sync_rwlock_everywhere, r=thomcc
std: use `sync::RwLock` for internal statics
Since `sync::RwLock` is now `const`-constructible, it can be used for internal statics, removing the need for `sys_common::StaticRwLock`. This adds some extra allocations on platforms which need to box their locks (currently SGX and some UNIX), but these will become unnecessary with the lock improvements tracked in #93740.
Michael Howell [Tue, 20 Sep 2022 17:13:02 +0000 (10:13 -0700)]
Rollup merge of #102038 - jyn514:rustdoc-normalize-test, r=compiler-errors
Make the `normalize-overflow` rustdoc test actually do something
Since https://github.com/rust-lang/rust/pull/88679, rustdoc doesn't load crates eagerly. Add an explicit `extern crate` item to make sure the crate is loaded and the bug reproduces.
You can verify this fix by adding `// compile-flags: -Znormalize-docs` and running the test to make sure it gives an error.
For this rule to have an actual effect, the border-bottom width needs specified, elsewhere, without also specifying the color. This doesn't happen. Ever since 88b137d5fe0cbe28dab4f9af61045c726f831872, every spot where headers get a border assigned to them also assigns the color.
Michael Howell [Tue, 20 Sep 2022 17:13:01 +0000 (10:13 -0700)]
Rollup merge of #102027 - notriddle:notriddle/docblock-item-decl, r=GuillaumeGomez
rustdoc: remove `docblock` class from `item-decl`
This class was originally added in 73b97c7e7c9cfac4dfa4804654b1db6ab687b589 to support hiding and showing the item, because `main.js` went through all `docblock` elements in the DOM and added toggles to them.
Michael Howell [Tue, 20 Sep 2022 17:12:58 +0000 (10:12 -0700)]
Rollup merge of #101958 - hanar3:101666/enhance-error-message, r=oli-obk
Improve error for when query is unsupported by crate
This is an improvement to the error message mentioned on #101666. It seems like a good idea to also add [this link to the rustc-dev-guide](https://rustc-dev-guide.rust-lang.org/query.html), if explaining the query system in detail is a concern here, but I'm unsure if there is any restrictions on adding links to error messages.
Michael Howell [Tue, 20 Sep 2022 17:12:57 +0000 (10:12 -0700)]
Rollup merge of #101014 - isikkema:fix-zmeta-stats-file-encoder-no-read-perms, r=isikkema
Fix -Zmeta-stats ICE by giving `FileEncoder` file read permissions
Fixes #101001
As far as I can tell, #101001 is caused because the file is being created with write-only permissions here: https://github.com/rust-lang/rust/blob/master/compiler/rustc_serialize/src/opaque.rs#L196
but it is trying to be read here: https://github.com/rust-lang/rust/blob/master/compiler/rustc_metadata/src/rmeta/encoder.rs#L780
This PR attempts to fix this by creating/opening the file with the same permissions as `File::create()` with the addition of read.
Michael Howell [Tue, 20 Sep 2022 17:12:56 +0000 (10:12 -0700)]
Rollup merge of #100250 - cjgillot:recover-token-stream, r=Aaron1011
Manually cleanup token stream when macro expansion aborts.
In case of syntax error in macro expansion, the expansion code can decide to stop processing anything. In that case, the token stream is malformed. This makes downstream users, like derive macros, ICE.
In this case, this PR manually cleans up the token stream by closing all currently open delimiters.
Clarify Path::extension() semantics in docs abstract
State up-front and center what shape the returned extension will have, without
making the user read through the description and examples.
Rationale: Various frameworks and libraries for different platforms have their
different conventions as to whether an "extension" is ".ext" or just "ext" and
anyone that's had to deal with this ambiguity in the past is always double- or
triple-checking to make sure the function call returns an extension that matches
the expected semantics. Offer the answer to this important question right off
the bat instead of making them dig to find it.
Auto merge of #99806 - oli-obk:unconstrained_opaque_type, r=estebank
Allow patterns to constrain the hidden type of opaque types
fixes #96572
reverts a revert as original PR was a perf regression that was fixed by reverting it: https://github.com/rust-lang/rust/pull/99368#issuecomment-1186587864)
TODO:
* check if https://github.com/rust-lang/rust/issues/99685 is avoided
Scott McMurray [Sat, 4 Jun 2022 23:23:15 +0000 (16:23 -0700)]
Optimize `array::IntoIter`
`.into_iter()` on arrays was slower than it needed to be (especially compared to slice iterator) since it uses `Range<usize>`, which needs to handle degenerate ranges like `10..4`.
This PR adds an internal `IndexRange` type that's like `Range<usize>` but with a safety invariant that means it doesn't need to worry about those cases -- it only handles `start <= end` -- and thus can give LLVM more information to optimize better.
I added one simple demonstration of the improvement as a codegen test.
Joshua Nelson [Tue, 20 Sep 2022 03:49:37 +0000 (22:49 -0500)]
Make the `normalize-overflow` rustdoc test actually do something
Since https://github.com/rust-lang/rust/pull/88679, rustdoc doesn't load crates eagerly.
Add an explicit `extern crate` item to make sure the crate is loaded and the bug reproduces.
You can verify this fix by adding `// compile-flags: -Znormalizing-docs` and running the test.
For this rule to have an actual effect, the border-bottom width needs
specified, elsewhere, without also specifying the color. This doesn't
happen. Ever since 88b137d5fe0cbe28dab4f9af61045c726f831872, every spot
where headers get a border assigned to them also assigns the color.
Auto merge of #102022 - matthiaskrgr:rollup-emwfjd1, r=matthiaskrgr
Rollup of 11 pull requests
Successful merges:
- #101389 (Tone down explanation on RefCell::get_mut)
- #101798 (Make `from_waker`, `waker` and `from_raw` unstably `const`)
- #101881 (Remove an unused struct field `late_bound`)
- #101904 (Add help for invalid inline argument)
- #101966 (Add unit test for identifier Unicode emoji diagnostics)
- #101979 (Update release notes for 1.64)
- #101985 (interpret: expose generate_stacktrace without full InterpCx)
- #102004 (Try to clarify what's new in 1.64.0 ffi types)
- #102005 (rustdoc: remove unused CSS `td.summary-column`)
- #102017 (Add all submodules to the list of directories tidy skips)
- #102019 (Remove backed off PRs from relnotes)
- Revert "Clarify when cargo detects changes" (https://github.com/rust-lang/cargo/pull/11107)
- Fix links to workspace inheritance headings in workspace docs (https://github.com/rust-lang/cargo/pull/11103)
- docs(ref): Clarify workspace settings (https://github.com/rust-lang/cargo/pull/11082)
- Update comment about ResolveVersion default version (https://github.com/rust-lang/cargo/pull/11095)
- [master] Run `reach_max_unpack_size` test only on debug build (https://github.com/rust-lang/cargo/pull/11091)
- Clarify when cargo detects changes (https://github.com/rust-lang/cargo/pull/11092)
- [master] Fix for https://github.com/advisories/GHSA-rfj2-q3h3-hm5j and https://github.com/advisories/GHSA-2hvr-h6gw-qrxp (https://github.com/rust-lang/cargo/pull/11089)
- Expose cargo add internals as edit API (https://github.com/rust-lang/cargo/pull/11059)
Michael Howell [Mon, 19 Sep 2022 17:52:13 +0000 (10:52 -0700)]
rustdoc: remove `docblock` class from `item-decl`
This class was originally added in 73b97c7e7c9cfac4dfa4804654b1db6ab687b589
to support hiding and showing the item, because `main.js` went through all
`docblock` elements in the DOM and added toggles to them.
Auto merge of #101894 - dingxiangfei2009:let-else-avoid-duplicate-storage-live, r=oli-obk
Avoid duplicating StorageLive in let-else
cc `@est31`
Fix #101867
Fix #101932
#101410 introduced directives to activate storages of bindings in let-else earlier. However, since it is using the machinery of `match` and friends for pattern matching and binding, those storages are activated for the second time. This PR adjusts this behavior and avoid the duplicated activation for let-else statements.
Rollup merge of #102017 - est31:rustc_dev_guide_tidy_skip, r=Mark-Simulacrum
Add all submodules to the list of directories tidy skips
Tidy contains a blacklist of directories that it is not visiting. This list is also used by the `replace-version-placeholder` tool added by #100591 , to determine the directories to do its replacement from. Generally, tidy does not check submodules, but this is not done consistently for all submodules. This PR adds the submodules that were previously missing, so that the `replace-version-placeholder` tool does not attempt to change content of the books. This was needed because `rustc-dev-guide` contains the placeholder, leading to #102014.
Rollup merge of #101985 - RalfJung:generate_stacktrace, r=oli-obk
interpret: expose generate_stacktrace without full InterpCx
In Miri we sometimes want to emit diagnostics without having a full `&InterpCx` available. To avoid duplicating code, this adds a way to get a stacktrace from an arbitrary slice of interpreter frames, that Miri can use with access to just a thread manager.
Rollup merge of #101979 - rust-lang:pa-update-relnotes, r=Mark-Simulacrum
Update release notes for 1.64
This PR makes a few updates to the release notes to bring them on-par with the release notes of other releases:
* The wording on some items has been changed to be more consistent and better describe what each change means, rather than using the PR title.
* Items that were also in the compatibility notes have been removed from the other sections, only keeping them in the compat notes.
* Diagnostics and ICE fixes have been removed from the notes.
* The cargo section has been made more consistent.
r? ``@Mark-Simulacrum``
cc ``@rust-lang/release`` ``@joshtriplett``
Rollup merge of #101966 - crlf0710:emoji_unittest, r=Mark-Simulacrum
Add unit test for identifier Unicode emoji diagnostics
Seems current diagnostics has some support for emoji usages, however it seems outdated and incomplete. This adds a simple unit test to showcase the status quo.
Rollup merge of #101389 - lukaslueg:rcgetmutdocs, r=m-ou-se
Tone down explanation on RefCell::get_mut
The language around `RefCell::get_mut` is remarkably sketchy and especially to the novice seems to quite strongly discourage using the method ("be cautious", "Also, please be aware", "special circumstances", "usually not what you want"). It was added six years ago in #40634 due to confusion about when to use `get_mut` and `borrow_mut`.
While its signature limits the use-cases for `get_mut`, there is no chance for a safety footgun, and readers can be made aware of `borrow_mut` more softly. I've also just sent a [PR](https://github.com/rust-lang/rust-clippy/issues/9044) to lint situations where `get_mut` could be used to improve ergonomics and performance.
So this PR tones down the language around `get_mut` and also brings it more in line with [`std::sync::Mutex::get_mut()`](https://doc.rust-lang.org/stable/std/sync/struct.Mutex.html#method.get_mut).
Auto merge of #101901 - lcnr:early-binder-type-foldable, r=compiler-errors
`EarlyBinder` prevent misuse
folding a type before substituting is pretty much always wrong and could happen by accident, e.g. see https://github.com/rust-lang/rust/pull/99798#discussion_r968666538
this PR removes the `TypeFoldable` and `TypeVisitable` impl from `EarlyBinder`.