https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.71.0 2023-05-07T16:20:16+00:00 2023-05-07T16:20:16+00:00 jyn github@jyn.dev 2023-05-07T16:19:13+00:00 urn:sha1:654f56e086fad836da5931e1a3defad804d9cfe9 cc https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/Building.20.60coretests.60.20by.20hand 2023-04-18T03:40:31+00:00 jyn github@jyn.dev 2023-04-18T01:00:36+00:00 urn:sha1:d6af60266eed9a19ee550278cdfe1d2857763286 Nils had an excellent idea the other day: the same way that rustdoc is able to load `rustc_driver` from the sysroot, ui-fulldeps tests should also be able to load it from the sysroot. That allows us to run fulldeps tests with stage1, without having to fully rebuild the compiler twice. It does unfortunately have the downside that we're running the tests on the *bootstrap* compiler, not the in-tree sources, but since most of the fulldeps tests are for the *API* of the compiler, that seems ok. I think it's possible to extend this to `run-make-fulldeps`, but I've run out of energy for tonight. - Move `plugin` tests into a subdirectory. Plugins are loaded at runtime with `dlopen` and so require the ABI of the running compile to match the ABI of the compiler linked with `rustc_driver`. As a result they can't be supported in stage 1 and have to use `// ignore-stage1`. - Remove `ignore-stage1` from most non-plugin tests - Ignore diagnostic tests in stage 1. Even though this requires a stage 2 build to load rustc_driver, it's primarily testing the error message that the *running* compiler emits when the diagnostic struct is malformed. - Pass `-Zforce-unstable-if-unmarked` in stage1, not just stage2. That allows running `hash-stable-is-unstable` in stage1, since it now suggests adding `rustc_private` to enable loading the crates. - Add libLLVM.so to the stage0 target sysroot, to allow fulldeps tests that act as custom drivers to load it at runtime. - Pass `--sysroot stage0-sysroot` in compiletest so that we use the correct version of std. 2023-03-20T17:19:35+00:00 Andy Russell arussell123@gmail.com 2023-01-15T18:43:15+00:00 urn:sha1:bb7c373fdf6c7c3fb8e204dcc178d870644fcc4b 2023-01-10T01:04:14+00:00 Eric Huss eric@huss.org 2023-01-06T01:20:59+00:00 urn:sha1:2717f600935174aa3ee5e743a3d1901d6be149a9 2022-11-25T14:28:18+00:00 Tshepang Mbambo tshepang@gmail.com 2022-11-25T14:28:18+00:00 urn:sha1:b21674f3bdca0083e7802842d282f64ee30080fb 2022-11-25T14:27:27+00:00 Tshepang Mbambo tshepang@gmail.com 2022-10-31T02:23:46+00:00 urn:sha1:c6ea362571bd7f7bc0d36b2aa61b44e183a2d841 2022-10-06T04:49:44+00:00 Nicholas Nethercote n.nethercote@gmail.com 2022-10-06T03:51:45+00:00 urn:sha1:9110d925d0b3e4842376e830f4404a28e1aa2658 The compiler currently has `-Ztime` and `-Ztime-passes`. I've used `-Ztime-passes` for years but only recently learned about `-Ztime`. What's the difference? Let's look at the `-Zhelp` output: ``` -Z time=val -- measure time of rustc processes (default: no) -Z time-passes=val -- measure time of each rustc pass (default: no) ``` The `-Ztime-passes` description is clear, but the `-Ztime` one is less so. Sounds like it measures the time for the entire process? No. The real difference is that `-Ztime-passes` prints out info about passes, and `-Ztime` does the same, but only for a subset of those passes. More specifically, there is a distinction in the profiling code between a "verbose generic activity" and an "extra verbose generic activity". `-Ztime-passes` prints both kinds, while `-Ztime` only prints the first one. (It took me a close reading of the source code to determine this difference.) In practice this distinction has low value. Perhaps in the past the "extra verbose" output was more voluminous, but now that we only print stats for a pass if it exceeds 5ms or alters the RSS, `-Ztime-passes` is less spammy. Also, a lot of the "extra verbose" cases are for individual lint passes, and you need to also use `-Zno-interleave-lints` to see those anyway. Therefore, this commit removes `-Ztime` and the associated machinery. One thing to note is that the existing "extra verbose" activities all have an extra string argument, so the commit adds the ability to accept an extra argument to the "verbose" activities. 2022-09-16T21:35:00+00:00 est31 MTest31@outlook.com 2022-09-16T21:28:02+00:00 urn:sha1:706f0f018b2e186aa9c464e0e8d7e20b0dfd324a This commit does three things: * First, it passes --cfg=bootstrap on stage 0 for rustdoc invocations on proc_macro crates. This mirrors what we do already for rustc invocations of those, and is needed because cargo doesn't respect RUSTFLAGS or RUSTDOCFLAGS when confronted with a proc macro. * Second, it marks the bootstrap config variable as expected. This is needed both on later stages where it's not set, but also on stage 0, where it is set. * Third, it adjusts the comment in the rustc wrapper to better reflect the reason why we set the bootstrap variable as expected: due to recent changes, setting it as expected is also required even if the cfg variable is passed: ebf4cc361e0d0f11a25b42372bd629953365d17e . 2022-08-16T21:22:02+00:00 Alex Macleod alex@macleod.io 2022-08-16T21:18:41+00:00 urn:sha1:23abd599e73993f1ab4599f189650141a1cd313e 2022-06-15T22:03:27+00:00 est31 MTest31@outlook.com 2022-06-15T19:31:28+00:00 urn:sha1:471fa05fef0b09e0430a80e3d7f205ef19fc4a86 As was discovered in https://github.com/rust-lang/rust/pull/93628#issuecomment-1154697627 , adding #[cfg(bootstrap)] to a rust-internal proc macro crate would yield an unexpected cfg name error, at least on later stages wher the bootstrap cfg arg wasn't set. rustc already passes arguments to mark bootstrap as expected, however the means of delivery through the RUSTFLAGS env var is unable to reach proc macro crates, as described in the issue linked in the code this commit touches. This wouldn't be an issue for cfg args that get passed through RUSTFLAGS, as they would never become *active* either, so any usage of one of these flags in a proc macro's code would legitimately yield a lint warning. But since dc302587e2cf5105a3a864319d7e7bcb434bba20, rust takes extra measures to pass --cfg=bootstrap even in proc macros, by passing it via the wrapper. Thus, we need to send the flags to mark bootstrap as expected also from the wrapper, so that #[cfg(bootstrap)] also works from proc macros. I want to thank Urgau and jplatte for helping me find the cause of this. ❤️