Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 13 pull requests #104167

Closed
wants to merge 35 commits into from
Closed

Conversation

Manishearth
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

chenyukang and others added 30 commits October 25, 2022 21:16
Users report an AV at runtime of the compiled binary when using lld and
ThinLTO on windows-msvc. The AV occurs when accessing a static value
which is defined in one crate but used in another. Based on the
disassembly of the cross-crate use, it appears that the use is not
correctly linked with the definition and is instead assigned a garbage
pointer value.

If we look at the symbol tables for each crates' obj file, we can see
what is happening:

*lib.obj*:

```
COFF SYMBOL TABLE
...
00E 00000000 SECT2  notype       External     | _ZN10reproducer7memrchr2FN17h612b61ca0e168901E
...
```

*bin.obj*:

```
COFF SYMBOL TABLE
...
010 00000000 UNDEF  notype       External     | __imp__ZN10reproducer7memrchr2FN17h612b61ca0e168901E
...
```

The use of the symbol has the "import" style symbol name but the
declaration doesn't generate any symbol with the same name. As a result,
linking the files generates a warning from lld:

> rust-lld: warning: bin.obj: locally defined symbol imported: reproducer::memrchr::FN::h612b61ca0e168901 (defined in lib.obj) [LNK4217]

and the symbol reference remains undefined at runtime leading to the AV.

To fix this, we just need to detect that we are performing ThinLTO (and
thus, static linking) and omit the `dllimport` attribute on the extern
item in LLVM IR.
Apply suggestions from code review

Co-authored-by: David Wood <[email protected]>
This option prints all supported values for -Csplit-debuginfo=.., i.e.
only stable ones on stable/beta and all of them on nightly/dev.
…r=michaelwoerister

Fix Access Violation when using lld & ThinLTO on windows-msvc

Users report an AV at runtime of the compiled binary when using lld and ThinLTO on windows-msvc. The AV occurs when accessing a static value which is defined in one crate but used in another. Based on the disassembly of the cross-crate use, it appears that the use is not correctly linked with the definition and is instead assigned a garbage pointer value.

If we look at the symbol tables for each crates' obj file, we can see what is happening:

*lib.obj*:

```
COFF SYMBOL TABLE
...
00E 00000000 SECT2  notype       External     | _ZN10reproducer7memrchr2FN17h612b61ca0e168901E
...
```

*bin.obj*:

```
COFF SYMBOL TABLE
...
010 00000000 UNDEF  notype       External     | __imp__ZN10reproducer7memrchr2FN17h612b61ca0e168901E
...
```

The use of the symbol has the "import" style symbol name but the declaration doesn't generate any symbol with the same name. As a result, linking the files generates a warning from lld:

> rust-lld: warning: bin.obj: locally defined symbol imported: reproducer::memrchr::FN::h612b61ca0e168901 (defined in lib.obj) [LNK4217]

and the symbol reference remains undefined at runtime leading to the AV.

To fix this, we just need to detect that we are performing ThinLTO (and thus, static linking) and omit the `dllimport` attribute on the extern item in LLVM IR.

Fixes rust-lang#81408
Add support for custom mir

This implements rust-lang/compiler-team#564 . Details about the design, motivation, etc. can be found in there.

r? `@oli-obk`
…-hang, r=jackh726,wesleywiser

Avoid possible infinite  loop when next_point reaching the end of file

Fixes rust-lang#103451
If we return a span with `lo` = `hi`, `span_to_snippet` will always get `Ok("")`, which may introduce infinite loop if we don't care.

This PR make `find_width_of_character_at_span` return `width` with 1, so that `span_to_snippet` will get an `Err`.
first move on a nested span_label

trying not to be smart this time.
…if-let, r=jackh276,davidtwco

Recover from common if let syntax mistakes/typos

Fixes rust-lang#103587
…at, r=wesleywiser

Properly remap and check for substs compatibility in `confirm_impl_trait_in_trait_candidate`

Fixes rust-lang#103824
…y_error_with_guaranteed, r=lcnr

Add 'ty_error_with_guaranteed' and 'const_error_with_guaranteed'

Part of rust-lang#103874
…ce, r=Mark-Simulacrum

Don't intra linkcheck reference

This removes the reference from the intra-doc link checks. This causes problems if any of the reference content needs to change, it causes the linkchecker to break. The reference has its own broken link check (https://github.com/rust-lang/reference/tree/master/style-check) which uses pulldown-cmark on the source to find actual broken links (instead of false-positives like this regex does).

I think the intra-doc link check could potentially be removed completely, since I think rustdoc is now checking for them well enough. However, it may serve as a decent regression check.
Place config.toml in current working directory if config not found

Fixes an issue where bootsrapping a Rust build would place `config.toml` in `{src_root}` rather than the current working directory

rust-lang#103697
disable btree size tests on Miri

Seems fine not to run these in Miri, they can't have UB anyway. And this lets us do layout randomization in Miri.

r? `@thomcc`
run alloc benchmarks in Miri and fix UB

Miri since recently has a "fake monotonic clock" that works even with isolation. Its measurements are not very meaningful but it means we can run these benches and check them for UB.

And that's a good thing since there was UB here: fixes rust-lang#104096.

r? `@thomcc`
Add split-debuginfo print option

This option prints all supported values for `-Csplit-debuginfo=..`, i.e. only stable ones on stable/beta and all of them on nightly/dev.

Motivated by 1.65.0 regression causing builds with the following entry in `Cargo.toml` to fail on Windows:
```toml
[profile.dev]
split-debuginfo = "unpacked"
```

See rust-lang/cargo#11347 for details.

This will lead to closing rust-lang#103976.
…-Simulacrum

Add llvm-main to triagebot.toml
@rustbot rustbot added T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) A-meta Area: Issues & PRs about the rust-lang/rust repository itself A-translation Area: Translation infrastructure, and migrating existing diagnostics to SessionDiagnostic S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Nov 8, 2022
@Manishearth
Copy link
Member Author

@bors r+ p=5

@bors
Copy link
Contributor

bors commented Nov 8, 2022

📌 Commit 4468412 has been approved by Manishearth

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 8, 2022
@matthiaskrgr
Copy link
Member

ci fails in related to #103464 , closing

@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-llvm-13 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
 finished in 0.521 seconds
Check compiletest suite=mir-opt mode=mir-opt (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)

running 190 tests
..........F...F..................................i...................................... 88/190
Some tests failed in compiletest suite=mir-opt mode=mir-opt host=x86_64-unknown-linux-gnu target=x86_64-unknown-linux-gnu
..............
failures:


---- [mir-opt] src/test/mir-opt/building/custom/simple_assign.rs stdout ----
thread '[mir-opt] src/test/mir-opt/building/custom/simple_assign.rs' panicked at 'Output file `/checkout/obj/build/x86_64-unknown-linux-gnu/test/mir-opt/building/custom/simple_assign/simple_assign.simple.mir_map.0.mir` from test does not exist, available files are in `/checkout/obj/build/x86_64-unknown-linux-gnu/test/mir-opt/building/custom/simple_assign`', src/tools/compiletest/src/runtest.rs:3426:21


---- [mir-opt] src/test/mir-opt/building/custom/references.rs stdout ----
thread '[mir-opt] src/test/mir-opt/building/custom/references.rs' panicked at 'Output file `/checkout/obj/build/x86_64-unknown-linux-gnu/test/mir-opt/building/custom/references/references.mut_ref.mir_map.0.mir` from test does not exist, available files are in `/checkout/obj/build/x86_64-unknown-linux-gnu/test/mir-opt/building/custom/references`', src/tools/compiletest/src/runtest.rs:3426:21

failures:
failures:
    [mir-opt] src/test/mir-opt/building/custom/references.rs
    [mir-opt] src/test/mir-opt/building/custom/simple_assign.rs
test result: FAILED. 183 passed; 2 failed; 5 ignored; 0 measured; 0 filtered out; finished in 6.23s

Build completed unsuccessfully in 0:10:52

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-meta Area: Issues & PRs about the rust-lang/rust repository itself A-translation Area: Translation infrastructure, and migrating existing diagnostics to SessionDiagnostic rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.