raw-dylib is a link kind that allows rustc to link against a library
without having any library files present.
This currently only exists on Windows. rustc will take all the symbols
from raw-dylib link blocks and put them in an import library, where they
can then be resolved by the linker.
While import libraries don't exist on ELF, it would still be convenient
to have this same functionality. Not having the libraries present at
build-time can be convenient for several reasons, especially
cross-compilation. With raw-dylib, code linking against a library can be
cross-compiled without needing to have these libraries available on the
build machine. If the libc crate makes use of this, it would allow
cross-compilation without having any libc available on the build
machine. This is not yet possible with this implementation, at least
against libc's like glibc that use symbol versioning.
The raw-dylib kind could be extended with support for symbol versioning
in the future.
This implementation is very experimental and I have not tested it very
well. I have tested it for a toy example and the lz4-sys crate, where it
was able to successfully link a binary despite not having a
corresponding library at build-time.
Make -Z unpretty=mir suggest -Z dump-mir as well for discoverability
While debugging something else, I got quite annoyed with `-Z unpretty=mir` showing me post-processed MIR instead of the one just after it is built. I ended up asking on Zulip and got pointed to `-Z dump-mir`. While this feature is documented in the rustc dev guide, I think it'd be good if the possibility of making use of it was staring you in the face while you need it.
revert accidental change in get_closest_merge_commit
This was accidentally merged as part of https://github.com/rust-lang/rust/pull/137594. I need this local diff to be able to debug miri syncs, and then typed `git commit -a` too fast and didn't realize it includes this change... sorry for that.
r? ``@Kobzol``
Don't suggest constraining unstable associated types
Fixes#137624
This could be made a bit more specific, considering the local crate's stability or nightly status or something, but I think in general we should not be suggesting associated type bounds on unstable associated items.
Teach structured errors to display short `Ty<'_>`
Make it so that in every structured error annotated with `#[derive(Diagnostic)]` that has a field of type `Ty<'_>`, the printing of that value into a `String` will look at the thread-local storage `TyCtxt` in order to shorten to a length appropriate with the terminal width. When this happen, the resulting error will have a note with the file where the full type name was written to.
```
error[E0618]: expected function, found `((..., ..., ..., ...), ..., ..., ...)``
--> long.rs:7:5
|
6 | fn foo(x: D) { //~ `x` has type `(...
| - `x` has type `((..., ..., ..., ...), ..., ..., ...)`
7 | x(); //~ ERROR expected function, found `(...
| ^--
| |
| call expression requires function
|
= note: the full name for the type has been written to 'long.long-type-14182675702747116984.txt'
= note: consider using `--verbose` to print the full type name to the console
```
Follow up to and response to the comments on #136898.
r? ``@oli-obk``
It is reasonable to expect that ./x.py test core is enough to run tests
when you are working on core. In addition it seems like CI for wasm32 at
least doesn't run coretests currently, which this commit fixes.
When the manually stripped entity receives a name as the first use
through a simple `let` statement, this name can be used in the generated
`if let Some(…)` expression instead of a placeholder.
Fix#14183
changelog: [`manual_strip`]: reuse existing identifier in suggestion
when possible
Change interners to start preallocated with an increased capacity
Inspired by https://github.com/rust-lang/rust/issues/137005.
Added a `with_capacity` function to `InternedSet`. Changed the `CtxtInterners` to start with `InternedSets` preallocated with a capacity.
This *does* increase memory usage at very slightly(by ~1 MB at the start), altough that increase quickly disaperars for larger crates(since they require such capacity anyway).
A local perf run indicates this improves compiletimes for small crates(like `ripgrep`), without a negative effect on larger ones.
Include version number of libs being built in cargo lib metadata (esp. `librustc_driver*.so`)
Previously, on a non-stable channel, it's possible for two builds from different versioned sources (e.g. 1.84.0 vs 1.84.1) to produce a `librustc_driver*.so` with the same filename hashes. This causes problems with side-by-side installs wrt. linker search paths because 1.84.1 rustc bin and 1.84.0 rustc bin may try to link to the "same" `librustc_driver*.so` (same filename hash) but fail because the contents of the so is actually different.
We try to mitigate this by including the version number of artifacts being built via `__CARGO_DEFAULT_LIB_METADATA` (kind of an ugly hack, but I don't think cargo has a way for us to tell cargo to use a package version override).
Fixes#136701 (mitigates, really).
### Testing
Tested manually[^host] by:
```bash
$ cat src/version
1.86.0
$ ./x build library # w/ compiler profile, (non-stable) dev channel
$ lddtree build/host/stage1/bin/rustc
rustc => build/host/stage1/bin/rustc (interpreter => /lib64/ld-linux-x86-64.so.2)
librustc_driver-ea1b1b2291881cc4.so => build/host/stage1/bin/../lib/librustc_driver-ea1b1b2291881cc4.so
[...]
```
and observing that changing `src/version` to bump a point release causes `librustc_driver*.so` to have a different hash while sources are unmodified otherwise.
```bash
$ cat src/version
1.86.1
$ ./x build library # w/ compiler profile, (non-stable) dev channel
$ lddtree build/host/stage1/bin/rustc
rustc => build/host/stage1/bin/rustc (interpreter => /lib64/ld-linux-x86-64.so.2)
librustc_driver-746badadbcb74721.so => build/host/stage1/bin/../lib/librustc_driver-746badadbcb74721.so
[...]
```
cc `@clan` `@demize` could you check that if you backport this change against 1.84.{0,1} as reported in #136701, that the produced `rustc` binary works, under the context of the Gentoo build system setup?
[^host]: on a `x86_64-unknown-linux-gnu` host, no cross
