Refactor build-manifest to minimize the number of changes needed to add a new component
- Add all components to `PkgType`
- Automate functionality wherever possible, so functions often don't have to be manually edited
- Where that's not possible, use exhaustive matches on `PkgType` instead of adding individual strings.
- Add documentation for how to add a component. Improve the existing documentation for how to test changes.
I tested locally that this generates an identical manifest before and after my change, as follows:
```sh
git checkout d44e14225a
cargo +nightly run --manifest-path src/tools/build-manifest/Cargo.toml build/dist build/manifest-before 1970-01-01 http://example.com nightly
git checkout refactor-build-manifest
cargo +nightly run --manifest-path src/tools/build-manifest/Cargo.toml build/dist build/manifest-before 1970-01-01 http://example.com nightly
sort -u build/manifest-before/channel-rust-nightly.toml | diff - <(sort -u build/manifest-after/channel-rust-nightly.toml)
```
I then verified by hand that the differences before sorting are inconsequential (mostly targets being slightly reordered).
The only change in behavior is that `llvm-tools` is now properly renamed to `llvm-tools-preview`:
```
; sort -u build/manifest-before/channel-rust-nightly.toml | diff - <(sort -u build/manifest-after/channel-rust-nightly.toml)
784a785
> [renames.llvm-tools]
894a896
> to = "llvm-tools-preview"
```
This is based on https://github.com/rust-lang/rust/pull/102241 and should not be merged before.
Previously, rustdoc would unconditionally report the version that *rustc* was compiled with.
That showed things like `nightly-2022-10-30`, which wasn't right, since this was a `dev` build compiled from source.
Fix it by changing `rustc_driver::version` to a macro expanded at invocation time.
Rollup of 7 pull requests
Successful merges:
- #100508 (avoid making substs of type aliases late bound when used as fn args)
- #101381 (Test that target feature mix up with homogeneous floats is sound)
- #103353 (Fix Access Violation when using lld & ThinLTO on windows-msvc)
- #103521 (Avoid possible infinite loop when next_point reaching the end of file)
- #103559 (first move on a nested span_label)
- #103778 (Update several crates for improved support of the new targets)
- #103827 (Properly remap and check for substs compatibility in `confirm_impl_trait_in_trait_candidate`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Avoid possible infinite loop when next_point reaching the end of file
Fixes#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`.
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#81408
Test that target feature mix up with homogeneous floats is sound
This pull-request adds a test in `src/test/abi/` that test that target feature mix up with homogeneous floats is sound.
This is basically is ripoff of [src/test/ui/simd/target-feature-mixup.rs](47d1cdb0bc/src/test/ui/simd/target-feature-mixup.rs) but for floats and without `#[repr(simd)]`.
*Extracted from https://github.com/rust-lang/rust/pull/97559 since I don't yet know what to do with that PR.*
avoid making substs of type aliases late bound when used as fn args
fixes#47511fixes#85533
(although I did not know theses issues existed when i was working on this 🙃)
currently `Alias<...>` is treated the same as `Struct<...>` when deciding if generics should be late bound or early bound but this is not correct as `Alias` might normalize to a projection which does not constrain the generics.
I think this needs more tests before merging
more explanation of PR [here](https://hackmd.io/v44a-QVjTIqqhK9uretyQg?view)
Hackmd inline for future readers:
---
This assumes reader is familiar with the concept of early/late bound lifetimes. There's a section on rustc-dev-guide if not (although i think some details are a bit out of date)
## problem & background
Not all lifetimes on a fn can be late bound:
```rust
fn foo<'a>() -> &'a ();
impl<'a> Fn<()> for FooFnDef {
type Output = &'a (); // uh oh unconstrained lifetime
}
```
so we make make them early bound
```rust
fn foo<'a>() -> &'a ();
impl<'a> Fn<()> for FooFnDef<'a> {// wow look at all that lifetimey
type Output = &'a ();
}
```
(Closures have the same constraint however it is not enforced leading to soundness bugs, [#84385](https://github.com/rust-lang/rust/pull/84385) implements this "downgrading late bound to early bound" for closures)
lifetimes on fn items are only late bound when they are "constrained" by the fn args:
```rust
fn foo<'a>(_: &'a ()) -> &'a ();
// late bound, not present on `FooFnItem`
// vv
impl<'a> Trait<(&'a (),)> for FooFnItem {
type Output = &'a ();
}
// projections do not constrain inputs
fn bar<'a, T: Trait>(_: <T as Trait<'a>>::Assoc) -> &'a (); // early bound
// vv
impl<'a, T: Trait> Fn<(<T as Trait<'a>>::Assoc,)> for BarFnItem<'a, T> {
type Output = &'a ();
}
```
current logic for determining if inputs "constrain" a lifetime works off of HIR so does not normalize aliases. It also assumes that any path with no self type constrains all its substs (i.e. `Foo<'a, u32>` has no self type but `T::Assoc` does). This falls apart for top level type aliases (see linked issues):
```rust
type Alias<'a, T> = <T as Trait<'a>>::Assoc;
// wow look its a path with no self type uwu
// i bet that constrains `'a` so it should be latebound
// vvvvvvvvvvv
fn foo<'a, T: Trait>(_: Alias<'a, T>) -> &'a ();
// `Alias` normalized to make things clearer
// vvvvvvvvvvvvvvvvvvvvvvv
impl<'a, T: Trait> Fn<(<T as Trait<'a>>::Assoc,)> for FooFnDef<T> {
type Output = &'a ();
// oh no `'a` isnt constrained wah wah waaaah *trumbone noises*
// i think, idk what musical instrument that is
}
```
## solution
The PR solves this by having the hir visitor that checks for lifetimes in constraining uses check if the path is a `DefKind::Alias`. If it is we ""normalize"" it by calling `type_of` and walking the returned type. This is a bit hacky as it requires a mapping between the substs on the path in hir, and the generics of the `type Alias<...>` which is on the ty layer.
Alternative solutions may involve calculating the "late boundness" of lifetimes after/during astconv rather than relying on hir at all. We already have code to determine whether a lifetime SHOULD be late bound or not as this is currently how the error for `fn foo<'a, T: Trait>(_: Alias<'a, T>) -> &'a ();` gets emitted.
It is probably not possible to do this right now, late boundness is used by `generics_of` and `gather_explicit_predicates_of` as we currently do not put late bound lifetimes in `Generics`. Although this seems sus to me as the long term goal is to make all generics late bound which would result in `generics_of(function)` being empty? [#103448](https://github.com/rust-lang/rust/pull/103448) places all lifetimes in `Generics` regardless of late boundness so that may be a good step towards making this possible.
Better error for HRTB error from generator interior
cc #100013
This is just a first pass at an error. It could be better, and shouldn't really be emitted in the first place. But this is better than what was being emitted before.
Remove an address comparison from the parser
Originally this check was added in #68985, as suggested by 940f65782c (r376850175). I don't think that this address check is a robust way of making parser more robust.
This code is also extensively tested by [`ui/parser/issues/issue-35813-postfix-after-cast.rs`](57d3c58ed6/src/test/ui/parser/issues/issue-35813-postfix-after-cast.rs).
_Replaces #103700_
r? `@compiler-errors`
Clarify licensing situation of MPSC and SPSC queue
Originally, these two files were licensed under the `BSD-2-Clause` license, as they were based off sample code on a blog licensing those snippets under that license:
* `library/std/src/sync/mpsc/mpsc_queue.rs`
* `library/std/src/sync/mpsc/spsc_queue.rs`
In 2017 though, the author of that blog agreed to relicense their code under the standard `MIT OR Apache-2.0` license in https://github.com/rust-lang/rust/pull/42149. This PR clarifies the situation in the files by expanding the comment at the top of the file.
r? ``@pnkfelix``
Fix `const_fn_trait_ref_impl`, add test for it
#99943 broke `#[feature(const_fn_trait_ref_impl)]`, this PR fixes this and adds a test for it.
r? ````@fee1-dead````
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 https://github.com/rust-lang/cargo/pull/11347 for details.
This will lead to closing https://github.com/rust-lang/rust/issues/103976.
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 https://github.com/rust-lang/rust/issues/104096.
r? ``@thomcc``
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``
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
#103697
selection failure: recompute applicable impls
The way we currently skip errors for ambiguous trait obligations seems pretty fragile so we get some duplicate errors because of this.
Removing this info from selection errors changes this system to be closer to my image of our new trait solver and is also making it far easier to change overflow errors to be non-fatal ✨
r? types cc `@estebank`
Make InferCtxtExt use a FxIndexMap
This should be faster, because the map is only being used to iterate,
which is supposed to be faster with the IndexMap
Make the user_computed_preds use an IndexMap
It is being used mostly for iteration, so the change shouldn't result in
a perf hit
Make the RegionDeps fields use an IndexMap
This change could be a perf hit. Both `larger` and `smaller` are used
for iteration, but they are also used for insertions.
Make types_without_default_bounds use an IndexMap
It uses extend, but it also iterates and removes items. Not sure if
this will be a perf hit.
Make InferTtxt.reported_trait_errors use an IndexMap
This change brought a lot of other changes. The map seems to have been
mostly used for iteration, so the performance shouldn't suffer.
Add FIXME to change ProvisionalEvaluationCache.map to use an IndexMap
Right now this results in a perf hit. IndexMap doesn't have
the `drain_filter` API, so in `on_completion` we now need to iterate two
times over the map.
resolve: More detailed effective visibility tracking for imports
Per-`DefId` tracking is not enough, due to glob imports in particular, which have a single `DefId` for the whole glob import item.
We need to track this stuff per every introduced name (`NameBinding`).
Also drop `extern` blocks from the effective visibility table, they are nominally private and it doesn't make sense to keep them there.
Later commits add some debug-only invariant checking and optimiaztions to mitigate regressions in https://github.com/rust-lang/rust/pull/103965#issuecomment-1304256445.
This is a bugfix and continuation of https://github.com/rust-lang/rust/pull/102026.
