about summary refs log tree commit diff
path: root/src/tools
AgeCommit message (Collapse)AuthorLines
2023-07-31Rollup merge of #114228 - fmease:wf-lazy-ty-aliases, r=oli-obkMatthias Krüger-1/+1
Check lazy type aliases for well-formedness Previously we didn't check if `T: Mul` holds given lazy `type Alias<T> = <T as Mul>::Output;`. Now we do. It only makes sense. `@rustbot` label F-lazy_type_alias r? `@oli-obk`
2023-07-31Auto merge of #3002 - RalfJung:miri-script, r=RalfJungbors-1/+1
fix oversight from new miri-script
2023-07-31fix oversight from new miri-scriptRalf Jung-1/+1
2023-07-31Auto merge of #113592 - Kobzol:pgo-script-bolt, r=Mark-Simulacrumbors-11/+155
Move BOLT from `bootstrap` to `opt-dist` Currently, we use BOLT to optimize LLVM for x64 Linux. The BOLT instrumentation and optimization step is implemented in `bootstrap`, but it was always quite hacky, because BOLT works quite differently than PGO. Rather than building an instrumented artifact, it takes an already built artifact and instruments it in-place. This is not a good fit for the bootstrap caching mechanism, and it meant that we had to run BOLT "on-the-fly" when packaging LLVM artifacts into the created sysroot. The BOLT code was also really only used by the PGO script (now called `opt-dist`) and nothing else, so it was quite hardcoded for this one single usage. And even if someone wanted to use the `--llvm-bolt-profile-[use/generate]` bootstrap flags outside of the PGO script, they would also need to implement profile gathering, as this is not performed by bootstrap anyway. I think that it could be more practical to move the BOLT logic to the `opt-dist` tool instead. This simplifies bootstrap, removes unneeded implementation of BOLT caching (we will now do it exactly once - no need to check if it has been performed already when bootstrap copies `libLLVM.so` around multiple times) and removes two BOLT-specific bootstrap flags, and also one special case for building LLVM (instead I pass the linker flags with `--set llvm.ldflags` from `opt-dist` now). There are also a few disadvantages to this new approach: - We have to guess/find the path to the built `libLLVM.so` file (but currently this is quite easy, it's just in `stage2/lib`). - We have to provide the BOLT profile externally to bootstrap, so that it is packaged into the reproducible artifacts archive. Doesn't seem like a big deal to me. - We are depending on some inner behavior of boostrap in `opt-dist` (namely, that `libLLVM.so` is hardlinked). But we do that for many other things in the `opt-dist` tool anyway, it's tied quite closely to bootstrap. I would like to go back to my attempts to also use BOLT for `librustc_driver.so`, and I think that it might be a bit simpler if I also do it from the `opt-dist` tool, so this is the first step towards that. Anyway, let me know what you think about this. It's just a refactoring in a way, no big deal. r? bootstrap
2023-07-31add some interesting tests for alignment corner casesRalf Jung-18/+67
2023-07-31Remove a `bool` for color in favor of the `WriteColor` trait wrapping ↵Oli Scherer-1/+0
colored and uncolored printing
2023-07-31Use builder pattern instead of lots of arguments for `EmitterWriter::new`Oli Scherer-22/+3
2023-07-31remove repetitive wordscui fliter-1/+1
Signed-off-by: cui fliter <imcusg@gmail.com>
2023-07-31Update cargoWeihang Lo-0/+0
2023-07-31Auto merge of #2909 - osiewicz:rewrite-miri-script-in-rust-2883, r=RalfJungbors-361/+1016
Rewrite miri script in rust This is a sketch of a rewrite of miri script in Rust. It does not include changes made in https://github.com/rust-lang/miri/pull/2908 yet. Environment variables are not properly propagated yet, which is something I plan to address. This PR is mostly a heads-up about the ongoing effort and it's state. It's definitely not the cleanest code I've seen in my life, but my first goal was feature/interface parity. I will iterate on it a bit before marking it as ready. I wonder though how this should be integrated/tested. Are you aware of anyone using `./miri` in their scripts? I guess we should keep existing `miri` script in place and let it run miri-script package directly? CI should probably `cargo check` this package as well. Fixes #2883
2023-07-31port to hand-rolled parser, since clap doesn't behave just the right wayRalf Jung-354/+150
2023-07-31miri-script refactorRalf Jung-614/+553
2023-07-31Replace the many arguments of `EmitterWriter::stderr` with builder methodsOli Scherer-0/+7
2023-07-31Pass BOLT profile to bootstrap to be included in the reproducible artifacts ↵Jakub Beránek-23/+28
archive
2023-07-31Implement BOLT optimization in the `opt-dist` toolJakub Beránek-24/+163
2023-07-30Auto merge of #112843 - chenyukang:yukang-more-on-backtrace, r=workingjubileebors-1/+1
Print omitted frames count for short backtrace mode Fixes #111730
2023-07-30rewrite miri script in RustPiotr Osiewicz-357/+1277
2023-07-30Auto merge of #2997 - RalfJung:test-utils, r=RalfJungbors-112/+77
refactor tests/utils a bit, and move some FS functions there
2023-07-30refactor tests/utils a bit, and move some FS functions thereRalf Jung-112/+77
2023-07-30Rollup merge of #114227 - asquared31415:tidy_check_fixed, r=albertlarsan68Matthias Krüger-1/+1
Add tidy check for stray rustfix files `x.fixed` files that don't correspond to a test file now emit a tidy error.
2023-07-30Rollup merge of #112655 - WaffleLapkin:must_use_map_or, r=workingjubileeMatthias Krüger-5/+5
Mark `map_or` as `#[must_use]` I don't know what else to say. r? libs
2023-07-30Mark `map_or` as `#[must_use]`Maybe Waffle-5/+5
2023-07-30Check lazy type aliases for well-formednessLeón Orell Valerian Liehr-1/+1
2023-07-30fmtThe Miri Conjob Bot-1/+1
2023-07-30Merge from rustcThe Miri Conjob Bot-4424/+152
2023-07-30Preparing for merge from rustcThe Miri Conjob Bot-1/+1
2023-07-29add tidy check for stray rustfix filesasquared31415-1/+1
2023-07-29Auto merge of #114211 - RalfJung:miri, r=RalfJungbors-233/+336
update Miri r? `@ghost`
2023-07-29Auto merge of #2993 - Vanille-N:tb-protector, r=RalfJungbors-151/+264
TB: Redefine trigger condition for protectors The Coq formalization revealed that as currently implemented, read accesses did not always commute. Indeed starting from a lazily initialized `Active` protected tag, applying a foreign read then a child read produces `Frozen`, but child read then foreign read triggers UB (because the child read initializes _before_ the `Active -> Frozen`). This reformulation of when protectors trigger fixes that issue: - instead of `Active + foreign read -> Frozen` and `Active -> Frozen` when protected is UB - we do `Active + foreign read -> if protected { Disabled } else { Frozen }` There is already precedent for transitions being dependent on the presence of a protector (`Reserved + foreign read -> if protected { Frozen } else { Reserved }`), and this has the nice side-effect of simplifying the protector trigger condition to just an equality check against `Disabled` since now there is protector UB iff a protected tag becomes `Disabled`. In order not to introduce an extra `if`, it was decided that `Disabled -> Disabled` would be UB when protected, which was not the case previously. This is merely a theoretical for now because a protected `Disabled` is unreachable in the first place. The extra test is not directly related to this modification, but also checks things related to protectors and lazy initialization.
2023-07-29doc comment suggestionsNeven Villani-25/+57
2023-07-29Add wasm32-wasi-threads target + WASI threadsGeorgii Rylov-0/+1
2023-07-29print omitted frames count for short backtrace modeyukang-1/+1
2023-07-29Adjust some tests for invalid_reference_casting improvementsUrgau-0/+4
2023-07-29Fix test output.Mara Bos-2/+4
2023-07-29Change default panic handler message format.Mara Bos-47/+94
2023-07-29Auto merge of #113422 - Urgau:cast_ref_to_mut-pre-beta, r=Nilstriebbors-8/+8
Rename and allow `cast_ref_to_mut` lint This PR is a small subset of https://github.com/rust-lang/rust/pull/112431, that is the renaming of the lint (`cast_ref_to_mut` -> `invalid_reference_casting`). BUT also temporarily change the default level of the lint from deny-by-default to allow-by-default until https://github.com/rust-lang/rust/pull/112431 is merged. r? `@Nilstrieb`
2023-07-29Auto merge of #111916 - fee1-dead-contrib:noop-method-call-warn, ↵bors-13/+15
r=compiler-errors make `noop_method_call` warn by default r? `@compiler-errors`
2023-07-29Update lexer emoji diagnostics to Unicode 15.0Charles Lew-5/+1
2023-07-28Add UI tests for generic const itemsLeón Orell Valerian Liehr-1/+1
2023-07-28Make Clippy understand generic const itemsLeón Orell Valerian Liehr-7/+15
2023-07-28exract a perform_access, check read-read commutation exhaustivelyNeven Villani-100/+193
2023-07-28Auto merge of #111780 - weiznich:diagnostic_namespace, r=petrochenkovbors-1/+1
Diagnostic namespace This PR implements the basic infrastructure for accepting the `#[diagnostic]` attribute tool namespace as specified in https://github.com/rust-lang/rfcs/pull/3368. Note: This RFC is not merged yet, but it seems like it will be accepted soon. I open this PR early on to get feedback on the actual implementation as soon as possible. This hopefully enables getting at least the diagnostic namespace to stable rust "soon", so that crates do not need to bump their MSRV if we stabilize actual attributes in this namespace. This PR only adds infrastructure accept attributes from this namespace, it does not add any specific attribute. Therefore the compiler will emit a lint warning for each attribute that's actually used. This namespace is added behind a feature flag, so it will be only available on a nightly compiler for now. cc `@estebank` as they've supported me in planing, specifying and implementing this feature.
2023-07-28Introduce the `#[diagnostic]` attribute namespaceGeorg Semmler-1/+1
Co-authored-by: est31 <est31@users.noreply.github.com> Co-authored-by: Esteban Kuber <estebank@users.noreply.github.com> Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
2023-07-28tidy: add exclusion for platform dependent cfg for miniz_oxide, as it hack ↵klensy-0/+1
itself
2023-07-28remove addr2line from tidy list. Why?klensy-1/+0
2023-07-28Auto merge of #114134 - fee1-dead-contrib:rm-constness-from-param-env, r=oli-obkbors-35/+37
Remove `constness` from `ParamEnv` This should be replaced by keyword generics/effects. cc #110395 r? `@oli-obk`
2023-07-28Auto merge of #114115 - nnethercote:less-token-tree-cloning, r=petrochenkovbors-14/+14
Less `TokenTree` cloning `TokenTreeCursor` has this comment on it: ``` // FIXME: Many uses of this can be replaced with by-reference iterator to avoid clones. ``` This PR completes that FIXME. It doesn't have much perf effect, but at least we now know that. r? `@petrochenkov`
2023-07-27Auto merge of #114144 - workingjubilee:rollup-jkmtgdo, r=workingjubileebors-4329/+6
Rollup of 4 pull requests Successful merges: - #97571 (Add documentation on v0 symbol mangling.) - #114122 (tests/ui/hello_world/main.rs: Remove FIXME (#62277)) - #114133 (Revert "add tidy check that forbids issue ui test filenames") - #114139 (Make `--print` with path unstable) r? `@ghost` `@rustbot` modify labels: rollup
2023-07-27Rollup merge of #114133 - workingjubilee:revert-add-tidy-check-issue-12345, ↵Jubilee-4329/+6
r=jackh726 Revert "add tidy check that forbids issue ui test filenames" This reverts commit 13e2abf6b388762af2e97ce065d6206961264a8f. Reverting because an MCP was requested and it turned out there was a lack of a consensus on what to do in this area.
2023-07-27Auto merge of #113779 - Kobzol:try-build-no-lto, r=Mark-Simulacrumbors-1/+31
Build the first LLVM without LTO in try builds Currently, we perform three LLVM builds in the Linux x64 dist builder, which is used for `try` builds: 1) "Normal" LLVM - takes ~5s to compile thanks to `sccache`, but ~8 minutes to link because of ThinLTO 2) PGO instrumented LLVM - same timings as 1) 3) PGO optimized LLVM - takes about 20 minutes to build When I tried to disable LTO for build 1), it suddenly takes only about a minute to build, because the linking step is much faster. The first LLVM doesn't really need LTO all that much. Without it, it will be a bit slower to build `rustc` in two subsequent steps, but it seems that the ~7 minutes saved on linking it do win that back. Btw, we can't use the host LLVM for build 1), because this LLVM then builds `rustc` in PGO instrumented mode, and we need the same compiler when later PGO optimizing `rustc`. And we want to use our in-house LLVM for that I think.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-27 16:30:55 +0000