| Age | Commit message (Collapse) | Author | Lines |
|---|
|
etc: add `RUSTC_BOOTSTRAP` to rust-analyzer config
Fixes the problem reported in https://github.com/rust-lang/rust/issues/112391#issuecomment-1597224941
|
|
r=Mark-Simulacrum
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```
|
|
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.
|
|
r=Mark-Simulacrum
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
|
|
remove repetitive words
|
|
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
|
|
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
|
|
Add missing feature gate in multiple_supertrait_upcastable doc
Fix #112424
|
|
Migrate GUI colors test to original CSS color format
Follow-up of https://github.com/rust-lang/rust/pull/111459.
r? `@notriddle`
|
|
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`
|
|
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`
|
|
refactor builtin unsize handling, extend comments
r? `@compiler-errors`
|
|
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
|
|
|
|
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`
|
|
`codegen_ssa` cleanups
Some clarifications I made when reading this code closely.
r? `@tmiasko`
|
|
Signed-off-by: cui fliter <imcusg@gmail.com>
|
|
|
|
archive
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
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 `{} `.
|
|
It makes things a little clearer.
|
|
|
|
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.
|
|
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.
|
|
The two functions are alway called together. This commit factors out the
repeated code.
|
|
`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`.
|
|
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.
|
|
Make it match the corresponding comment at the start of the unstable
options.
|
|
It's no longer used, and `spawn_named_thread` is preferable, because
naming threads is helpful when profiling.
|
|
This is useful when profiling with a profiler like Samply.
|
|
|
|
|
|
The `Worker` is unnecessary, and just makes it longer than necessary.
|
|
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.
|
|
- Thin and fat LTO can't happen together.
- `NeedsLink` and (non-allocator) `Compiled` work item results can't
happen together.
|
|
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.
|
|
It has a single callsite, and provides little value.
|
|
Fix simd_bswap for i8/u8
#114156 missed this test case ☹️
cc `@workingjubilee`
|
|
Rollup of 4 pull requests
Successful merges:
- #95965 (Stabilize const-weak-new)
- #109075 (Use `LazyLock` to lazily resolve backtraces)
- #113741 (Don't install default projection bound for return-position `impl Trait` in trait methods with no body)
- #114268 (Fix empty_write since rust version attribute)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix empty_write since rust version attribute
Fixup of https://github.com/rust-lang/rust/pull/98154 for the rust version.
r? ``@workingjubilee``
|
|
r=spastorino
Don't install default projection bound for return-position `impl Trait` in trait methods with no body
This ensures that we never try to project to an opaque type in a trait method that has no body to infer its hidden type, which means we never later call `type_of` on that opaque. This is because opaque types try to reveal their hidden type when proving auto traits.
I thought about this a lot, and I think this is a fix that's less likely to introduce other strange downstream ICEs than #113461.
Fixes #113434
r? `@spastorino`
|
|
Use `LazyLock` to lazily resolve backtraces
By using TAIT to name the initializing closure, `LazyLock` can be used to replace the current `LazilyResolvedCapture`.
|
|
Stabilize const-weak-new
This is a fairly uncontroversial library stabilization, so I'm going ahead and proposing it to ride the trains to stable.
This stabilizes the following APIs, which are defined to be non-allocating constructors.
```rust
// alloc::rc
impl<T> Weak<T> {
pub const fn new() -> Weak<T>;
}
// alloc::sync
impl<T> Weak<T> {
pub const fn new() -> Weak<T>;
}
```
Closes #95091
``@rustbot`` modify labels: +needs-fcp
|
|
clean stage-specific artifacts using `x clean --stage`
fixes #109313
|
|
|
