Rollup of 14 pull requests #78952
Closed
Rollup of 14 pull requests #78952
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This expands time's test suite to use more and in more places the range of methods and constants added to Duration in recent proposals for the sake of testing more API surface area and improving legibility.
Duration::ZERO composes better with match and various other things, at the cost of an occasional parens, and results in less work for the optimizer, so let's use that instead.
Duration::ZERO supercedes it in effect.
It now only reacts to expansion of those macros, and suggests
inserting `"{}", ` in the right place.
The panic message might contain braces which should never be interpreted as format placeholders, which panic!() will do in a future edition.
The beta compiler doesn't accept rustc_diagnostic_items on macros yet.
(From the PR feedback.) Co-authored-by: Esteban Küber <esteban@kuber.com.ar>
Co-authored-by: bjorn3 <bjorn3@users.noreply.github.com>
(From the PR feedback.) Co-authored-by: Esteban Küber <esteban@kuber.com.ar>
Additionally introduce storage markers for all temporaries created by the inliner. The temporary introduced for destination rebrorrow, didn't use them previously.
* `-Zinline-mir-threshold` to change the default threshold. * `-Zinline-mir-hint-threshold` to change the threshold used by functions with inline hint.
occurences -> occurrences
Co-authored-by: varkor <github@varkor.com>
…stebank
Add lint for panic!("{}")
This adds a lint that warns about `panic!("{}")`.
`panic!(msg)` invocations with a single argument use their argument as panic payload literally, without using it as a format string. The same holds for `assert!(expr, msg)`.
This lints checks if `msg` is a string literal (after expansion), and warns in case it contained braces. It suggests to insert `"{}", ` to use the message literally, or to add arguments to use it as a format string.
This lint is also a good starting point for adding warnings about `panic!(not_a_string)` later, once [`panic_any()`](#74622) becomes a stable alternative.
Upgrade dlmalloc to version 0.2 In preparation of adding dynamic memory management support for SGXv2-enabled platforms, the dlmalloc crate has been refactored. More specifically, support has been added to implement platform specification outside of the dlmalloc crate. (see alexcrichton/dlmalloc-rs#15) This PR upgrades dlmalloc to version 0.2 for the `wasm` and `sgx` targets. As the dlmalloc changes have received a positive review, but have not been merged yet, this PR contains a commit to prevent tidy from aborting CI prematurely. cc: `@jethrogb`
Duration::zero() -> Duration::ZERO In review for #72790, whether or not a constant or a function should be favored for `#![feature(duration_zero)]` was seen as an open question. In #73544 (comment) an invitation was opened to either stabilize the methods or propose a switch to the constant value, supplemented with reasoning. Followup comments suggested community preference leans towards the const ZERO, which would be reason enough. ZERO also "makes sense" beside existing associated consts for Duration. It is ever so slightly awkward to have a series of constants specifying 1 of various units but leave 0 as a method, especially when they are side-by-side in code. It seems unintuitive for the one non-dynamic value (that isn't from Default) to be not-a-const, which could hurt discoverability of the associated constants overall. Elsewhere in `std`, methods for obtaining a constant value were even deprecated, as seen with [std::u32::min_value](https://doc.rust-lang.org/std/primitive.u32.html#method.min_value). Most importantly, ZERO costs less to use. A match supports a const pattern, but const fn can only be used if evaluated through a const context such as an inline `const { const_fn() }` or a `const NAME: T = const_fn()` declaration elsewhere. Likewise, while #73544 (comment) notes `Duration::zero()` can optimize to a constant value, "can" is not "will". Only const contexts have a strong promise of such. Even without that in mind, the comment in question still leans in favor of the constant for simplicity. As it costs less for a developer to use, may cost less to optimize, and seems to have more of a community consensus for it, the associated const seems best. r? `@LukasKalbertodt`
Support enable/disable sanitizers/profiler per target This PR add options under `[target.*]` of `config.toml` which can enable or disable sanitizers/profiler runtime for corresponding target. If these options are empty, the global options under `[build]` will take effect. Fix #78329
BTreeMap: split off most code of append To complete #78056, move the last single-purpose pieces of code out of map.rs into a separate module. Also, tweaked documentation and safeness - I doubt think this code would be safe if the iterators passed in wouldn't be as sorted as the method says they should be - and bounds on MergeIterInner. r? `@Mark-Simulacrum`
look at assoc ct, check the type of nodes an example where types matter are function objects, see the added test which previously passed. Now does a shallow comparison of unevaluated constants. r? `@oli-obk`
…trochenkov Implement destructuring assignment for structs and slices This is the second step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909, tracking issue: #71126). This PR is the second part of #71156, which was split up to allow for easier review. Note that the first PR (#78748) is not merged yet, so it is included as the first commit in this one. I thought this would allow the review to start earlier because I have some time this weekend to respond to reviews. If `@petrochenkov` prefers to wait until the first PR is merged, I totally understand, of course. This PR implements destructuring assignment for (tuple) structs and slices. In order to do this, the following *parser change* was necessary: struct expressions are not required to have a base expression, i.e. `Struct { a: 1, .. }` becomes legal (in order to act like a struct pattern). Unfortunately, this PR slightly regresses the diagnostics implemented in #77283. However, it is only a missing help message in `src/test/ui/issues/issue-77218.rs`. Other instances of this diagnostic are not affected. Since I don't exactly understand how this help message works and how to fix it yet, I was hoping it's OK to regress this temporarily and fix it in a follow-up PR. Thanks to `@varkor` who helped with the implementation, particularly around the struct rest changes. r? `@petrochenkov`
Add flags customizing behaviour of MIR inlining * `-Zinline-mir-threshold` to change the default threshold. * `-Zinline-mir-hint-threshold` to change the threshold used by functions with inline hint. Having those as configurable flags makes it possible to experiment with with different inlining thresholds and substantially increase test coverage of MIR inlining when used with increased thresholds (for example, necessary to test #78844).
Support inlining diverging function calls The existing heuristic does penalize diverging calls to some degree, but since it never inlined them previously it might need some further modifications. Additionally introduce storage markers for all temporaries created by the inliner. The temporary introduced for destination rebrorrow, didn't use them previously.
Cleanup and comment intra-doc link pass r? `@Manishearth` cc `@seeplusplus`
rustc_target: Move target env "gnu" from `linux_base` to `linux_gnu_base` Follow up to #77729. Changes the target spec hierarchy for Linux from ``` linux_base ├── linux_musl_base └── linux_uclibc_base ``` where `linux_base` is really `linux_gnu_base` and the inheriting targets replace target env "gnu" with "musl"/"uclibc" to ``` linux_base ├── linux_gnu_base ├── linux_musl_base └── linux_uclibc_base ``` which is slightly less confusing (I think).
rustc_taret: Remove `TargetOptions::is_like_android` This option was replaced by more specific options and is no longer used by the compiler.
Fix typo in comment occurences -> occurrences
Ship llvm-cov through llvm-tools `llvm-cov` is used to generate coverage report with LLVM InstrProf-based code coverage #34701. So if `llvm-cov` is shipped through llvm-tools, users can try it easily accorging to the instruction of [The Rust Unstable Book](https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/source-based-code-coverage.html).
|
📌 Commit 68c5bc3 has been approved by |
bors
added
the
S-waiting-on-bors
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
linux_basetolinux_gnu_base#78929 (rustc_target: Move target env "gnu" fromlinux_basetolinux_gnu_base)TargetOptions::is_like_android#78930 (rustc_taret: RemoveTargetOptions::is_like_android)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup