-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Rollup of 10 pull requests #142442
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 10 pull requests #142442
Conversation
…common code * Fix invalid whitespace handling
* Fix typo * Remove usage of `!has`
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
Rewriting git history is something that is often difficult for new contributors, and we're already explaining the `<foo>` placeholder syntax, so I think it makes sense to be explicit about what exactly the paths mean.
that was phrased like a separate sentence
They will be used in a subsequent commit.
It currently only inserts separators into `usize`s, because that's all that has been needed so far. `-Zmacro-stats` will need `isize` and `f64` handling, so this commit adds that.
It collects data about macro expansions and prints them in a table after expansion finishes. It's very useful for detecting macro bloat, especially for proc macros. Details: - It measures code snippets by pretty-printing them and then measuring lines and bytes. This required a bunch of additional pretty-printing plumbing, in `rustc_ast_pretty` and `rustc_expand`. - The measurement is done in `MacroExpander::expand_invoc`. - The measurements are stored in `ExtCtxt::macro_stats`.
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
Rustc pull update
This allows UTF-8 characters to be printed without escapes, rather than just ASCII.
Implement asymmetrical precedence for closures and jumps I have been through a series of asymmetrical precedence designs in Syn, and finally have one that I like and is worth backporting into rustc. It is based on just 2 bits of state: `next_operator_can_begin_expr` and `next_operator_can_continue_expr`. Asymmetrical precedence is the thing that enables `(return 1) + 1` to require parentheses while `1 + return 1` does not, despite `+` always having stronger precedence than `return` [according to the Rust Reference](https://doc.rust-lang.org/1.83.0/reference/expressions.html#expression-precedence). This is facilitated by `next_operator_can_continue_expr`. Relatedly, it is the thing that enables `(return) - 1` to require parentheses while `return + 1` does not, despite `+` and `-` having exactly the same precedence. This is facilitated by `next_operator_can_begin_expr`. **Example:** ```rust macro_rules! repro { ($e:expr) => { $e - $e; $e + $e; }; } fn main() { repro!{return} repro!{return 1} } ``` `-Zunpretty=expanded` **Before:** ```console fn main() { (return) - (return); (return) + (return); (return 1) - (return 1); (return 1) + (return 1); } ``` **After:** ```console fn main() { (return) - return; return + return; (return 1) - return 1; (return 1) + return 1; } ```
…lett Delegate `<CStr as Debug>` to `ByteStr` This allows UTF-8 characters to be printed without escapes, rather than just ASCII. r? `@joshtriplett`
…ring, r=camelid Merge `Cfg::render_long_html` and `Cfg::render_long_plain` methods common code Follow-up of rust-lang#141747. Thanks `@camelid` for spotting it! r? `@camelid`
…henkov Introduce `-Zmacro-stats` Introduce `-Zmacro-stats`. It collects data about macro expansions and prints them in a table after expansion finishes. It's very useful for detecting macro bloat, especially for proc macros. r? `@petrochenkov`
Tracking the old name of renamed unstable library features This PR resolves the first problem of rust-lang#141617 : tracking renamed unstable features. The first commit is to add a ui test, and the second one tracks the changes. I will comment on the code for clarification. r? `@jdonszelmann` There have been a lot of PR's reviewed by you lately, thanks for your time! cc `@jyn514`
…vidtwco [AIX] strip underlying xcoff object When stripping, we need to strip the archive member first before archiving. Otherwise, the shared library remain untouched, only the archive symbol table will be modified.
…li-obk miri: we can use apfloat's mul_add now With rust-lang/rustc_apfloat#11 fixed, there is no reason to still use host floats here. Fixes rust-lang/miri#2995 We already have a test for this: https://github.com/rust-lang/rust/blob/a7153db254acc387e271e75153bdbd3caa2bed89/src/tools/miri/tests/pass/float.rs#L998-L1003 r? ``@oli-obk``
…bzol Add bootstrap option to compile a tool with features Add an option to specify which features to build a tool with, e.g. it will be useful to build Miri with tracing enabled: ```toml tool-config.miri.features = ["tracing"] ``` See [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Passing.20--features.20to.20Miri.20build.20using.20.2E.2Fx.2Epy/with/523564773) for the options considered. If the final decision will be different than what I wrote now, I will update the code as needed. The reason why the option is `tool-config.miri.features` instead of something like `tool-features.miri` is to possibly allow adding more tool-specific configurations in the future. I didn't do any validation of the keys of the `tool-config` hashmap, since I saw that no validation is done on the `tools` hashset either. I don't like much the fact that features can be chosen by various places of the codebase: `Step`s can have some fixed `extra_features`, `prepare_tool_cargo` will add features depending on some bootstrapping options, and the newly added option can also contribute features to tools. However I think it is out of scope of this PR to try to refactor all of that (if it even is refactorable), so I left a comment in the codebase explaining all of the sources of features I could find.
…workingjubilee intrinsics: rename min_align_of to align_of Now that `pref_align_of` is gone (rust-lang#141803), we can give the intrinsic backing `align_of` its proper name. r? `@workingjubilee` or `@bjorn3`
rustc-dev-guide subtree update r? `@ghost`
@bors r+ rollup=never p=1 |
@bors p=5 |
☀️ Test successful - checks-actions |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 015c777 (parent) -> c359117 (this PR) Test differencesShow 192 test diffsStage 1
Stage 2
Additionally, 138 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard c35911781925bcbfdeb5e6e1adb305097af46801 --output-dir test-dashboard And then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
📌 Perf builds for each rolled up PR:
previous master: 015c7770ec In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (c359117): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -0.8%, secondary -0.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -0.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 754.993s -> 755.253s (0.03%) |
Successful merges:
<CStr as Debug>
toByteStr
#141491 (Delegate<CStr as Debug>
toByteStr
)Cfg::render_long_html
andCfg::render_long_plain
methods common code #141770 (MergeCfg::render_long_html
andCfg::render_long_plain
methods common code)-Zmacro-stats
#142069 (Introduce-Zmacro-stats
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup