Rollup of 5 pull requests #113911
Merged
Rollup of 5 pull requests #113911
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
…ics. LLVM has a neat [statistics] feature that tracks how often optimizations kick in. It's very handy for optimization work. Since we expose the LLVM pass timings, I thought it made sense to expose the LLVM statistics too. [statistics]: https://llvm.org/docs/ProgrammersManual.html#the-statistic-class-stats-option
…rust/pull/113723/files use slice memcpy rather than strcpy and write it on stdout use println on failure Co-authored-by: Oli Scherer <github35764891676564198441@oli-obk.de>
This introduces a bit of code duplication, but we don't have the build_output_filenames in the CrateName arm and this seems a little cleaner overall.
The style guide discusses the default Rust style. Configurability of Rust formatting tools are not the domain of the style guide.
The style guide requires a trailing comma on where clause components, but then gives an example that doesn't include one. Add the missing trailing comma.
…change) Avoid putting a sentence fragment after a list; integrate it with the sentence before the list.
…default style
The style guide inconsistently used language like "there should be a
space" or "it should be on its own line", or "may be written on a single
line", for things that are required components of the default Rust
style. "should" and especially "may" come across as optional. While the
style guide overall now has a statement at the top that the default
style itself is a *recommendation*, the *definition* of the default
style should not be ambiguous about what's part of the default style.
Rewrite language in the style guide to only use "should" and "may" and
similar for truly optional components of the style (e.g. things a tool
cannot or should not enforce in its default configuration).
In their place, either use "must", or rewrite in imperative style ("put
a space", "start it on the same line"). The latter also substantially
reduces the use of passive voice.
This is a purely editorial change, and does not affect the semantic
definition of the Rust style.
Make it clear the rule for stacking the second line on the first applies recursively, as long as the condition holds.
…rustfmt) An example immediately following "Put each bound on its own line." did not put each bound on its own line.
Co-authored-by: Caleb Cartwright <calebcartwright@users.noreply.github.com>
…ust-should-may, r=calebcartwright
style-guide: clean up "must"/"should"/"may"
Avoid using "should" or "may" for required parts of the default style.
The style guide inconsistently used language like "there should be a space" or
"it should be on its own line", or "may be written on a single line", for
things that are required components of the default Rust style. "should" and
especially "may" come across as optional. While the style guide overall now has
a statement at the top that the default style itself is a *recommendation*, the
*definition* of the default style should not be ambiguous about what's part of
the default style.
Rewrite language in the style guide to only use "should" and "may" and similar
for truly optional components of the style (e.g. things a tool cannot or should
not enforce in its default configuration).
In their place, either use "must", or rewrite in imperative style ("put a
space", "start it on the same line"). The latter also substantially reduces the
use of passive voice.
Looking for "should"s also flagged some recommendations the style guide made
for configurability of tools (e.g. a tool "should" have a given configuration
option). I've removed those recommendations, per discussion with the style
team; it's not the domain of the style guide to make such recommendations, only
to define the default Rust style.
In the process of making this change, I also fixed a typo, fixed a text structure
issue, fixed an example that didn't match the Rust style (missing a trailing
comma), and added an additional example for clarity. (Those changes would have
conflicted with this one.) Those changes appear in separate commits.
These are all purely editorial changes, and do not affect the semantic
definition of the Rust style.
…nikic Resurrect: rustc_llvm: Add a -Z `print-codegen-stats` option to expose LLVM statistics. This resurrects PR rust-lang#104000, which has sat idle for a while. And I want to see the effect of stack-move optimizations on LLVM (like https://reviews.llvm.org/D153453) :). I have applied the changes requested by `@oli-obk` and `@nagisa` rust-lang#104000 (comment) and rust-lang#104000 (comment) in the latest commits. r? `@oli-obk` ----- LLVM has a neat [statistics](https://llvm.org/docs/ProgrammersManual.html#the-statistic-class-stats-option) feature that tracks how often optimizations kick in. It's very handy for optimization work. Since we expose the LLVM pass timings, I thought it made sense to expose the LLVM statistics too. ----- (Edit: fix broken link (Edit2: fix segmentation fault and use malloc If `rustc` is built with ```toml [llvm] assertions = true ``` Then you can see like ``` rustc +stage1 -Z print-codegen-stats -C opt-level=3 tmp.rs ===-------------------------------------------------------------------------=== ... Statistics Collected ... ===-------------------------------------------------------------------------=== 3 aa - Number of MayAlias results 193 aa - Number of MustAlias results 531 aa - Number of NoAlias results ... ``` And the current default build emits only ``` $ rustc +stage1 -Z print-codegen-stats -C opt-level=3 tmp.rs ===-------------------------------------------------------------------------=== ... Statistics Collected ... ===-------------------------------------------------------------------------=== $ ``` This might be better to emit the message to tell assertion flag necessity, but now I can't find how to do that...
Support `--print KIND=PATH` command line syntax As is already done for `--emit KIND=PATH` and `-L KIND=PATH`. In the discussion of rust-lang#110785, it was pointed out that `--print KIND=PATH` is nicer than trying to apply the single global `-o` path to `--print`'s output, because in general there can be multiple print requests within a single rustc invocation, and anyway `-o` would already be used for a different meaning in the case of `link-args` and `native-static-libs`. I am interested in using `--print cfg=PATH` in Buck2. Currently Buck2 works around the lack of support for `--print KIND=PATH` by [indirecting through a Python wrapper script](https://github.com/facebook/buck2/blob/d43cf3a51a31f00be2c2248e78271b0fef0452b4/prelude/rust/tools/get_rustc_cfg.py) to redirect rustc's stdout into the location dictated by the build system. From skimming Cargo's usages of `--print`, it definitely seems like it would benefit from `--print KIND=PATH` too. Currently it is working around the lack of this by inserting `--crate-name=___ --print=crate-name` so that it can look for a line containing `___` as a delimiter between the 2 other `--print` informations it actually cares about. This is commented as a "HACK" and "abuse". https://github.com/rust-lang/cargo/blob/31eda6f7c360d9911f853b3014e057db61238f3e/src/cargo/core/compiler/build_context/target_info.rs#L242 (FYI `@weihanglo` as you dealt with this recently in rust-lang/cargo#11633.) Mentioning reviewers active in rust-lang#110785: `@fee1-dead` `@jyn514` `@bjorn3`
Make {Rc,Arc}::allocator associated functions
Minor improvements to Windows TLS dtors This does a few things: * Moves keyless dtors into the same module as the `on_tls_callback` function because of dylib mess. We keep the `inline(never)` hints as a precaution (see also the issue they link to). * Introduces the `HAS_DTORS` atomic as an optimization hint. This allows removing (most) of the TLS dtor code if no dtors are ever run. Otherwise it's always included because of a `#[used]`. * Only run either keyed dtors or keyless dtors but not both. They should be mutually exclusive as keyed dtors are a fallback. I've also added an `assert` to make sure this is true.
rustbot
added
S-waiting-on-review
|
@bors r+ rollup=never p=6 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: 1a44b45987 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Jul 21, 2023
|
Finished benchmarking commit (78f97c9): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 650.086s -> 651.312s (0.19%) |
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:
print-codegen-statsoption to expose LLVM statistics. #113723 (Resurrect: rustc_llvm: Add a -Zprint-codegen-statsoption to expose LLVM statistics.)--print KIND=PATHcommand line syntax #113780 (Support--print KIND=PATHcommand line syntax)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup