- 01 8月, 2023 6 次提交
-
-
由 Matthias Krüger 提交于
Fix ice tests when librustc-driver is linked dynamically Running `dump-ice-to-disk`and `short-ice` tests on Linux targeting `x86_64-fortanix-unknown-sgx` platform results in: ``` jenkins@31cf43196355:~/workspace/rust-sgx-ci/Raoul/rust$ cat /home/jenkins/workspace/rust-sgx-ci/Raoul/rust/build/x86_64-unknown-linux-gnu/test/run-make/dump-ice-to-disk/dump-ice-to-disk/* /home/jenkins/workspace/rust-sgx-ci/Raoul/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc: error while loading shared libraries: librustc_driver-fa98927b935b2881.so: cannot open shared object file: No such file or directory /home/jenkins/workspace/rust-sgx-ci/Raoul/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc: error while loading shared libraries: librustc_driver-fa98927b935b2881.so: cannot open shared object file: No such file or directory /home/jenkins/workspace/rust-sgx-ci/Raoul/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc: error while loading shared libraries: librustc_driver-fa98927b935b2881.so: cannot open shared object file: No such file or directory /home/jenkins/workspace/rust-sgx-ci/Raoul/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc: error while loading shared libraries: librustc_driver-fa98927b935b2881.so: cannot open shared object file: No such file or directory ``` Setting the LD_LIBRARY_PATH explicitly to `$(HOST_RPATH_DIR)` in these tests Makefiles resolves the issue. The `thumb-none-qemu` and `thumb-none-cortex-m` run-make tests do something similar. cc: ```@jethrogb``` ```@vn971``` ```@mkaynov```
-
由 Matthias Krüger 提交于
Update `.gitmodules` to use shallow submodule clones This change makes submodule checkouts shallow by default. This significantly reduces the time needed to do a recursive checkout when `--shallow-submodules` is not specified, such as when `x` is not being used.
-
由 Matthias Krüger 提交于
Move MinGW linker dist option to proper section Using this option currently results in the error: ``` failed to parse TOML configuration 'config.toml': unknown field `include-mingw-linker`, expected one of `optimize`, `debug`, `codegen-units`, `codegen-units-std`, `debug-assertions`, `debug-assertions-std`, `overflow-checks`, `overflow-checks-std`, `debug-logging`, `debuginfo-level`, `debuginfo-level-rustc`, `debuginfo-level-std`, `debuginfo-level-tools`, `debuginfo-level-tests`, `split-debuginfo`, `run-dsymutil`, `backtrace`, `incremental`, `parallel-compiler`, `default-linker`, `channel`, `description`, `musl-root`, `rpath`, `verbose-tests`, `optimize-tests`, `codegen-tests`, `omit-git-hash`, `dist-src`, `save-toolstates`, `codegen-backends`, `lld`, `use-lld`, `llvm-tools`, `deny-warnings`, `backtrace-on-ice`, `verify-llvm-ir`, `thin-lto-import-instr-limit`, `remap-debuginfo`, `jemalloc`, `test-compare-mode`, `llvm-libunwind`, `control-flow-guard`, `new-symbol-mangling`, `profile-generate`, `profile-use`, `download-rustc`, `lto`, `validate-mir-opts` for key `rust` ``` That's because the option [belongs to `dist` section](https://github.com/rust-lang/rust/blob/bef6ff618f17398775e9d8cd23a6f47d983869dc/src/bootstrap/config.rs#L861). cc #108581
-
由 Matthias Krüger 提交于
remove repetitive words
-
由 Matthias Krüger 提交于
Update Android system definitions and add riscv-linux-android as tier 3 target This PR includes the following: * Corrected Android system definitions for some types * Support for the riscv64-linux-android target The authoritative types for the system definitions can be found here: https://cs.android.com/android/platform/superproject/+/master:bionic/libc/include/sys/stat.h Fixes rust-lang/compiler-team#640
-
由 bors 提交于
Rollup of 9 pull requests Successful merges: - #114111 (Improve test case for experimental API remove_matches) - #114169 (refactor builtin unsize handling, extend comments) - #114182 (clean up after 113312) - #114193 (Update lexer emoji diagnostics to Unicode 15.0) - #114200 (Detect trait upcasting through struct tail unsizing in new solver select) - #114228 (Check lazy type aliases for well-formedness) - #114267 (Map RPITIT's opaque type bounds back from projections to opaques) - #114269 (Migrate GUI colors test to original CSS color format) - #114286 (Add missing feature gate in multiple_supertrait_upcastable doc) r? `@ghost` `@rustbot` modify labels: rollup
-
- 31 7月, 2023 34 次提交
-
-
由 Matthias Krüger 提交于
Add missing feature gate in multiple_supertrait_upcastable doc Fix #112424
-
由 Matthias Krüger 提交于
Migrate GUI colors test to original CSS color format Follow-up of https://github.com/rust-lang/rust/pull/111459. r? `@notriddle`
-
由 Matthias Krüger 提交于
Map RPITIT's opaque type bounds back from projections to opaques An RPITIT in a program's AST is eventually translated into both a projection GAT and an opaque. The opaque is used for default trait methods, like: ``` trait Foo { fn bar() -> impl Sized { 0i32 } } ``` The item bounds for both the projection and opaque are identical, and both have a *projection* self ty. This is mostly okay, since we can normalize this projection within the default trait method body to the opaque, but it does two things: 1. it leads to bugs in places where we don't normalize item bounds, like `deduce_future_output_from_obligations` 2. it leads to extra match arms that are both suspicious looking and also easy to miss This PR maps the opaque type bounds of the RPITIT's *opaque* back to the opaque's self type to avoid this quirk. Then we can fix the UI test for #108304 (1.) and also remove a bunch of match arms (2.). Fixes #108304 r? `@spastorino`
-
由 Matthias Krüger 提交于
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`
-
由 Matthias Krüger 提交于
refactor builtin unsize handling, extend comments r? `@compiler-errors`
-
由 bors 提交于
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
-
由 Gary Guo 提交于
-
由 bors 提交于
Update cargo 14 commits in 7ac9416d82cd4fc5e707c9ec3574d22dff6466e5..c91a693e7977e33a1064b63a5daf5fb689f01651 2023-07-24 14:29:38 +0000 to 2023-07-31 00:26:46 +0000 - fix: align `cargo --help` text (rust-lang/cargo#12418) - fix: normalize relative git submodule urls with `ssh://` (rust-lang/cargo#12411) - test: relax help text assertion (rust-lang/cargo#12416) - test: relax assertions of panic handler message format (rust-lang/cargo#12413) - fix(package): Recognize and normalize `cargo.toml` (rust-lang/cargo#12399) - Clarify `lto` setting passing `-Clinker-plugin-lto` (rust-lang/cargo#12407) - doc: add missing reference to `CARGO_PROFILE_<name>_STRIP` in environment variables docs (rust-lang/cargo#12408) - Update curl-sys to pull in curl 8.2.1 (rust-lang/cargo#12406) - docs: raise awareness of resolver used inside workspace (rust-lang/cargo#12388) - chore: update `home` to 0.5.7 (rust-lang/cargo#12401) - Update curl-sys to pull in curl 8.2.0 (rust-lang/cargo#12400) - test(cli): Track --help output (rust-lang/cargo#11912) - refactor(test): Move cargo-config into a dir (rust-lang/cargo#12398) - refactor(tests): Name init ui tests more consistently (rust-lang/cargo#12397) r? `@ghost`
-
由 bors 提交于
`codegen_ssa` cleanups Some clarifications I made when reading this code closely. r? `@tmiasko`
-
由 cui fliter 提交于
Signed-off-by: Ncui fliter <imcusg@gmail.com>
-
由 Weihang Lo 提交于
-
由 Jakub Beránek 提交于
-
由 Jakub Beránek 提交于
-
由 Jakub Beránek 提交于
-
由 Nicholas Nethercote 提交于
-
由 bors 提交于
Only golden arches A number of tests in the test suite have applied the somewhat comedic practice of ignoring *every* single target architecture that rustc has ever supported. This is silly, when they are clearly tests built around certain assumptions, primarily of the x86-64 architecture, or in one case when they are only relevant for a handful of 32-bit targets. This has even resulted, in one case, in the same architecture being ignored twice! Document these better, and use a "revision + only-arch" idiom in the test headers to denote the "golden arches" that actually pass these tests.
-
由 Nicholas Nethercote 提交于
This function has some shared code for the thin LTO and fat LTO cases, but those cases have so little in common that it's actually clearer to treat them fully separately.
-
由 Nicholas Nethercote 提交于
PR #112946 tweaked the naming of LLVM threads, but messed things up slightly, resulting in threads on Windows having names like `optimize module {} regex.f10ba03eb5ec7975-cgu.0`. This commit removes the extraneous `{} `.
-
由 Nicholas Nethercote 提交于
It makes things a little clearer.
-
由 Nicholas Nethercote 提交于
-
由 Nicholas Nethercote 提交于
The main loop has a *very* complex condition, which includes two mentions of `codegen_state`. The body of the loop then immediately switches on the `codegen_state`. I find it easier to understand if it's a `loop` and we check for exit conditions after switching on `codegen_state`. We end up with a tiny bit of code duplication, but it's clear that (a) we never exit in the `Ongoing` case, (b) we exit in the `Completed` state only if several things are true (and there's interaction with LTO there), and (c) we exit in the `Aborted` state if a couple of things are true. Also, the exit conditions are all simple conjunctions.
-
由 Nicholas Nethercote 提交于
This loop condition involves `codegen_state`, `work_items`, and `running_with_own_token`. But the body of the loop cannot modify `codegen_state`, so repeatedly checking it is unnecessary.
-
由 Nicholas Nethercote 提交于
The two functions are alway called together. This commit factors out the repeated code.
-
由 Nicholas Nethercote 提交于
`CodegenContext` is immutable except for the `worker` field - we clone `CodegenContext` in multiple places, changing the `worker` field each time. It's simpler to move the `worker` field out of `CodegenContext`.
-
由 Nicholas Nethercote 提交于
Because it's usefulness wasn't clear to me, and I initially wondered if it could be removed. The text is based on the text in #50972, the PR that added the flag.
-
由 Nicholas Nethercote 提交于
Make it match the corresponding comment at the start of the unstable options.
-
由 Nicholas Nethercote 提交于
It's no longer used, and `spawn_named_thread` is preferable, because naming threads is helpful when profiling.
-
由 Nicholas Nethercote 提交于
This is useful when profiling with a profiler like Samply.
-
由 Nicholas Nethercote 提交于
-
由 Nicholas Nethercote 提交于
-
由 Nicholas Nethercote 提交于
The `Worker` is unnecessary, and just makes it longer than necessary.
-
由 Nicholas Nethercote 提交于
It took me some time to understand how the main thread can lend a jobserver token to an LLVM thread. This commit renames a couple of things to make it clearer. - Rename the `LLVMing` variant as `Lending`, because that is a clearer description of what is happening. - Rename `running` as `running_with_own_token`, which makes it clearer that there might be one additional LLVM thread running (with a loaned token). Also add a comment to its definition.
-
由 Nicholas Nethercote 提交于
- Thin and fat LTO can't happen together. - `NeedsLink` and (non-allocator) `Compiled` work item results can't happen together.
-
由 Nicholas Nethercote 提交于
And rename the `Compiled` variant as `Finished`, because that name makes it clearer there is nothing left to do, contrasting nicely with the `Needs*` variants.
-