| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Enable ThinLTO for rustc on `x86_64-apple-darwin`
Local measurements seemed to show an improvement on a couple benchmarks, so I'd like to test real CI builds, and see if the builder doesn't timeout with the expected slight increase in build times.
Let's start with x64 rustc ThinLTO, and then figure out the file structure to configure LLVM ThinLTO. Maybe we'll then try `aarch64` builds since that also looked good locally.
|
|
Enable ThinLTO for rustc on x64 msvc
This applies the great work from `@bjorn3` and `@Kobzol` in https://github.com/rust-lang/rust/pull/101403 to x64 msvc.
Here are the local results for the try build `68c5c85ed759334a11f0b0e586f5032a23f85ce4`, compared to its parent `0a6b941df354c59b546ec4c0d27f2b9b0cb1162c`. Looking better than my previous local builds.
(I can't show cycle counts, as that option is failing on the windows version of the perf collector, but I'll try to analyze and debug this soon)
This will be the first of a few tests for rustc / llvm / both ThinLTO on the windows and mac targets.
|
|
Don't internalize __llvm_profile_counter_bias
Currently, LLVM profiling runtime counter relocation cannot be used by rust during LTO because symbols are being internalized before all symbol information is known.
This mode makes LLVM emit a __llvm_profile_counter_bias symbol which is referenced by the profiling initialization, which itself is pulled in by the rust driver here [1].
It is enabled with -Cllvm-args=-runtime-counter-relocation for platforms which are opt-in to this mode like Linux. On these platforms there will be no link error, rather just surprising behavior for a user which request runtime counter relocation. The profiling runtime will not see that symbol go on as if it were never there. On Fuchsia, the profiling runtime must have this symbol which will cause a hard link error.
As an aside, I don't have enough context as to why rust's LTO model is how it is. AFAICT, the internalize pass is only safe to run at link time when all symbol information is actually known, this being an example as to why. I think special casing this symbol as a known one that LLVM can emit which should not have it's visbility de-escalated should be fine given how seldom this pattern of defining an undefined symbol to get initilization code pulled in is. From a quick grep, __llvm_profile_runtime is the only symbol that rustc does this for.
[1] https://github.com/rust-lang/rust/blob/0265a3e93bf1b89d97cae113ed214954d5c35e22/compiler/rustc_codegen_ssa/src/back/linker.rs#L598
|
|
Rollup of 6 pull requests
Successful merges:
- #105411 (Introduce `with_forced_trimmed_paths`)
- #105532 (Document behaviour of `--remap-path-prefix` with several matches)
- #105537 (compiler: remove unnecessary imports and qualified paths)
- #105539 (rustdoc: Only hide lines starting with `#` in rust code blocks )
- #105546 (Add some regression tests for #44454)
- #105547 (Add regression test for #104582)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add regression test for #104582
Closes #104582
r? `@compiler-errors`
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
Add some regression tests for #44454
Closes #44454
r? ``@compiler-errors``
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
r=notriddle
rustdoc: Only hide lines starting with `#` in rust code blocks
Fixes https://github.com/rust-lang/rust/issues/105527.
So before approving, this is a big question: in rust code blocks, in a line starts with a `#`, we hide it in the output. However, should we do the same for non-rust code blocks too? I think it's a bit problematic to do it because `#` can be used for many things but I prefer to check first with everyone (might also be worth updating documentation too).
cc ``@rust-lang/rustdoc``
r? ``@notriddle``
|
|
Document behaviour of `--remap-path-prefix` with several matches
|
|
Introduce `with_forced_trimmed_paths`
Built on top of https://github.com/rust-lang/rust/pull/104922, only last commit is relevant.
|
|
r=notriddle
rustdoc: Prevent auto/blanket impl retrieval if there were compiler errors
Fixes https://github.com/rust-lang/rust/issues/105404.
I'm not sure happy about this fix but since it's how passes work (ie, even if there are errors, it runs all passes), I think it's fine as is.
Just as a sidenote: I also gave a try to prevent running all passes in case there were compiler errors but then a lot of rustdoc tests were failing so I went for this fix instead.
r? `@notriddle`
|
|
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
r=GuillaumeGomez
Clean up lifetimes in rustdoc syntax highlighting
Removes a few lifetimes and renames some.
r? ``@GuillaumeGomez``
|
|
Build rust-analyzer proc-macro server by default
This allows getting rid of some documentation and an extra step when building a custom toolchain: https://rustc-dev-guide.rust-lang.org/building/how-to-build-and-run.html#creating-a-rustup-toolchain and it seems likely that people will want to do this if they want rustdoc (which is also built by default).
|
|
|
|
|
|
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #104460 (Migrate parts of `rustc_expand` to session diagnostics)
- #105192 (Point at LHS on binop type err if relevant)
- #105234 (Remove unneeded field from `SwitchTargets`)
- #105239 (Avoid heap allocation when truncating thread names)
- #105410 (Consider `parent_count` for const param defaults)
- #105482 (Fix invalid codegen during debuginfo lowering)
Failed merges:
- #105411 (Introduce `with_forced_trimmed_paths`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Fix invalid codegen during debuginfo lowering
In order for LLVM to correctly generate debuginfo for msvc, we sometimes need to spill arguments to the stack and perform some direct & indirect offsets into the value. Previously, this code always performed those actions, even when not required as LLVM would clean it up during optimization.
However, when MIR inlining is enabled, this can cause problems as the operations occur prior to the spilled value being initialized. To solve this, we first calculate the necessary offsets using just the type which is side-effect free and does not alter the LLVM IR. Then, if we are in a situation which requires us to generate the LLVM IR (and this situation only occurs for arguments, not local variables) then we perform the same calculation again, this time generating the appropriate LLVM IR as we go.
r? `@tmiasko` but feel free to reassign if you want 🙂
Fixes #105386
|
|
Consider `parent_count` for const param defaults
Fixes #105257
|
|
Remove unneeded field from `SwitchTargets`
This had a fixme already. The only change in behavior is that the mir dumps now no longer contains labels for the types of the integers on the edges of a switchint:
Before:
After:
I don't think that's a problem though. The information is still available to a user that really cares by checking the type of `_2`, so it honestly feels like a bit of an improvement to me.
r? mir
|
|
Point at LHS on binop type err if relevant
|
|
Migrate parts of `rustc_expand` to session diagnostics
This migrates everything but the `mbe` and `proc_macro` modules. It also contains a few cleanups and drive-by/accidental diagnostic improvements which can be seen in the diff for the UI tests.
|
|
Fix failing codegen tests on s390x
Several codegen tests are currently failing due to making assumptions that are not valid for the s390x architecture:
- catch-unwind.rs: fails due to inlining differences. Already ignored on another platform for the same reason. Solution: Ignore on s390x.
- remap_path_prefix/main.rs: fails due to different alignment requirement for string constants. Solution: Do not test for the alignment requirement.
- repr-transparent-aggregates-1.rs: many ABI assumptions. Already ignored on many platforms for the same reason. Solution: Ignore on s390x.
- repr-transparent.rs: no vector ABI by default on s390x. Already ignored on another platform for a similar reason. Solution: Ignore on s390x.
- uninit-consts.rs: hard-coded little-endian constant. Solution: Match both little- and big-endian versions.
Fixes part of https://github.com/rust-lang/rust/issues/105383.
|
|
Removes a few lifetimes and renames some.
|
|
This migrates everything but the `mbe` and `proc_macro` modules. It also
contains a few cleanups and drive-by/accidental diagnostic improvements
which can be seen in the diff for the UI tests.
|
|
Update cargo
2 commits in f6e737b1e3386adb89333bf06a01f68a91ac5306..70898e522116f6c23971e2a554b2dc85fd4c84cd 2022-12-02 20:21:24 +0000 to 2022-12-05 19:43:44 +0000
- Rename `generate_units` -> `generate_root_units` (rust-lang/cargo#11458)
- Implements cargo file locking using fcntl on Solaris. (rust-lang/cargo#11439)
r? `@ghost`
|
|
Introduce `Span::is_visible`
r? `@oli-obk`
|
|
Don't warn about unused parens when they are used by yeet expr
Don't even get me started on how I've found this.
|
|
Add LLVM KCFI support to the Rust compiler
This PR adds LLVM Kernel Control Flow Integrity (KCFI) support to the Rust compiler. It initially provides forward-edge control flow protection for operating systems kernels for Rust-compiled code only by aggregating function pointers in groups identified by their return and parameter types. (See llvm/llvm-project@cff5bef.)
Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by identifying C char and integer type uses at the time types are encoded (see Type metadata in the design document in the tracking issue #89653).
LLVM KCFI can be enabled with -Zsanitizer=kcfi.
Thank you again, `@bjorn3,` `@eddyb,` `@nagisa,` and `@ojeda,` for all the help!
|
|
Set `download-ci-llvm = "if-available"` by default when `channel = dev`
See https://github.com/rust-lang/compiler-team/issues/566. The motivation for changing the default is to avoid downloading and building LLVM when someone runs `x build` before running `x setup`. The motivation for only doing it on `channel = "dev"` is to avoid breaking distros or users installing from source. It works because `dev` is also the default channel.
The diff looks larger than it is; most of it is moving the `llvm` branch below the `rust` so `config.channel` is set.
r? `@Mark-Simulacrum` cc `@oli-obk` `@bjorn3` `@cuviper`
|
|
Compute generator sizes with `-Zprint_type_sizes`
Fixes #103887
r? `@pnkfelix`
|
|
2 commits in f6e737b1e3386adb89333bf06a01f68a91ac5306..70898e522116f6c23971e2a554b2dc85fd4c84cd
2022-12-02 20:21:24 +0000 to 2022-12-05 19:43:44 +0000
- Rename `generate_units` -> `generate_root_units` (rust-lang/cargo#11458)
- Implements cargo file locking using fcntl on Solaris. (rust-lang/cargo#11439)
|
|
|
|
r=compiler-errors
Tweak `rustc_must_implement_one_of` diagnostic output
|
|
rustdoc: make stability badge CSS more consistent
# Before
# After
# Description
* They all get rounded corners now. A test case has been added for this, too.
* There are now broadly two kinds of stability badge, where there used to be three: item-info "fat badge", and the "thin badge" in both item tables and in docblocks (which got merged). The fat badges can have icons, while the thin badges can't.
* The old Ayu design doesn't make sense to me. Does anyone know why it was done that way?
|
|
r=GuillaumeGomez
rustdoc: remove no-op mobile CSS `#sidebar-toggle { text-align }`
Since 8b001b4da0716936e0ca32303cc0e3c5e53e42f8 make the sidebar toggle a flex container, and already centers its content in desktop mode, this rule doesn't do anything.
|
|
Skip test on s390x as LLD does not support the platform
test/run-make/issue-71519 requires use of lld as linker, but lld does not currently support the s390x architecture.
|
|
Add `rustc_on_unimplemented` to `Sum` and `Product` trait.
Helps with #105184, but I don't think it fully fixes it.
|
|
Make `missing_copy_implementations` more cautious
- Fixes https://github.com/rust-lang/rust/issues/98348
- Also makes the lint not fire on large types and types containing raw pointers. Thoughts?
|
|
|
|
|
|
* They all get rounded corners now. A test case has been added for this, too.
* There are now broadly two kinds of stability badge, where there used to be
three: item-info "fat badge", and the "thin badge" in both item tables and
in docblocks (which got merged). The fat badges can have icons, while the
thin badges can't.
|
|
|
|
|
|
Rollup of 10 pull requests
Successful merges:
- #105216 (Remove unused GUI test)
- #105245 (attempt to clarify align_to docs)
- #105387 (Improve Rustdoc scrape-examples UI)
- #105389 (Enable profiler in dist-powerpc64le-linux)
- #105427 (Dont silently ignore rustdoc errors)
- #105442 (rustdoc: clean up docblock table CSS)
- #105443 (Move some queries and methods)
- #105455 (use the correct `Reveal` during validation)
- #105470 (Clippy: backport ICE fix before beta branch)
- #105474 (lib docs: fix typo)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Clippy: backport ICE fix before beta branch
r? `@Manishearth`
Before beta is branched tomorrow we should backport the fix from https://github.com/rust-lang/rust-clippy/pull/10027 for an ICE. That way we'll get this into stable one release sooner.
This only cherry-picks the fix, not the tests for it. The proper sync of this will be done next week Thursday.
|
|
use the correct `Reveal` during validation
supersedes #105454. Deals with https://github.com/rust-lang/rust/issues/105009#issuecomment-1342395333, not closing #105009 as the ICE may leak into beta
The issue was the following:
- we optimize the mir, using `Reveal::All`
- some optimization relies on the hidden type of an opaque type
- we then validate using `Reveal::UserFacing` again which is not able to observe the hidden type
r? `@jackh726`
|
