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
changelog: Enhancement: [`nonstandard_macro_braces`]: Now includes `matches!()` in the default lint config
[#9471](https://github.com/rust-lang/rust-clippy/pull/9471)
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 #9505 - mikerite:fix-9504-2, r=dswij
Fix ICE in `unnecessary_to_owned`
Fixes #9504
Compiler generated call `into_future` nodes return empty substs which we need when checking it's predicates. Handle this by simply exitting when we encounter one. This change introduces false negatives in place of the ICEs.
Michael Wright [Wed, 21 Sep 2022 05:02:52 +0000 (07:02 +0200)]
Fix ICE in `unnecessary_to_owned`
Fixes #9504
Compiler generated call `into_iter` nodes return empty substs
which we need when checking it's predicates. Handle this by
simply exitting when we encounter one. This change introduces
false negatives in place of the ICEs.
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.)
This rule was added in 88fe6dfa31a1bee49090dc72c537c5cd7bd632f4 to assist
in position the hide/show togges on methods. This is no longer needed,
because these toggles are no longer implemented as absolutely positioned
links nested inside headers.
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.
Chris Wailes [Thu, 8 Sep 2022 23:33:44 +0000 (16:33 -0700)]
Update rustc's information on Android's sanitizers
This patch updates sanitizier support definitions for Android inside the
compiler. It also adjusts the logic to make sure no pre-built sanitizer
runtime libraries are emitted as these are instead provided dynamically
on Android targets.
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
Auto merge of #2552 - RalfJung:env-term, r=oli-obk
remove Windows TERM env var hack and -Zmiri-env-exclude
The hack should not be needed any more since https://github.com/rust-lang/rust/pull/100206. And that also mostly removes the need for `-Zmiri-env-exclude` -- if needed, users can still achieve the same by running `(unset VAR; cargo miri test)`.
I am keeping `-Zmiri-env-forward` since it is still useful, e.g. to have RUST_BACKTRACE=full set in an otherwise deterministic execution.
`@rust-lang/miri` any objections to removing `-Zmiri-env-exclude`?
Auto merge of #2548 - RalfJung:remove-tls-diagnostics-hack, r=RalfJung
avoid thread-local var indirection for non-halting diagnostics
This hack used to be necessary because Stacked Borrows did not have access to enough parts of the machine. But that got fixed a while ago, so now we can just emit diagnostics directly, which is a lot more reliable.
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.
Joshua Nelson [Tue, 20 Sep 2022 01:45:00 +0000 (20:45 -0500)]
Make cycle errors recoverable
In particular, this allows rustdoc to recover from cycle errors when normalizing associated types for documentation.
In the past, `@jackh726` has said we need to be careful about overflow errors:
> Off the top of my head, we definitely should be careful about treating overflow errors the same as
"not implemented for some reason" errors. Otherwise, you could end up with behavior that is
different depending on recursion depth. But, that might be context-dependent.
But cycle errors should be safe to unconditionally report; they don't depend on the recursion depth, they will always be an error whenever they're encountered.
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).
projects / rust.git / log