Michael Goulet [Thu, 10 Nov 2022 05:53:37 +0000 (21:53 -0800)]
Rollup merge of #104201 - GuillaumeGomez:gui-test-check-file-errors, r=notriddle
Add check in GUI test for file loading failure
Since https://github.com/rust-lang/rust/pull/101702, some resources location need to be updated in case their content changed because then their hash will change too. This will prevent errors like https://github.com/rust-lang/rust/pull/104114 to happen again.
The second commit is to prevent CORS errors: when a file is linked from a file itself imported, the web browser considers they come from a different domain and therefore triggers the error. The option tells the web browser to ignore this case.
Michael Goulet [Thu, 10 Nov 2022 05:53:34 +0000 (21:53 -0800)]
Rollup merge of #102763 - compiler-errors:nits, r=cjgillot
Some diagnostic-related nits
1. Use `&mut Diagnostic` instead of `&mut DiagnosticBuilder<'_, T>`
2. Make `diag.span_suggestions` take an `IntoIterator` instead of `Iterator`, just to remove some `.into_iter` calls on the caller.
idk if I should add a lint to make sure people use `&mut Diagnostic` instead of `&mut DiagnosticBuilder<'_, T>` in cases where we're just, e.g., adding subdiagnostics to the diagnostic... maybe a followup.
Rollup merge of #104184 - jyn514:rustdoc-version, r=davidtwco
Fix `rustdoc --version` when used with download-rustc
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.
cc https://github.com/rust-lang/rust/issues/103206#issuecomment-1284123084
12 commits in aa5ee485bd6bd80d205da7c82fcdd776f92fdd51..3f64052c048c6def93b94a2b514ee88bba918744
2022-10-20 16:49:55 -0400 to 2022-11-03 22:13:58 -0400
- Upgrade to Rust 1.65
- Upgrade to Rust 1.64
- Upgrade to Rust 1.63
- New ideas for the issue template to try
- Clarify that the conditional expression is the one under discussion
- Updates from copyedit of ch6
- Made Option<T> error explanation more clear
- Update ch06-01-defining-an-enum
- Upgrade mdbook
- Clarify that user1 can't be used as a whole instance. Fixes rust-lang/book#2978.
- Fix plural and incorrect phrase. Fixes rust-lang/book#3359.
- Updates from copyedit of ch5
## rust-by-example
4 commits in 03491f33375c5a2a1661c7fa4be671fe95ce1249..2b15c0abf2bada6e00553814336bc3e2d8399097
2022-10-21 07:30:08 -0300 to 2022-10-31 08:30:13 -0300
- Remove --edition from src/crates/using_lib.md (rust-lang/rust-by-example#1635)
- upgrade upload-artifact
- Clarify Fn in fn/closures/input_parameters.md (rust-lang/rust-by-example#1634)
- fix: erroneous white spaces in types/cast.md
## rustc-dev-guide
12 commits in 51a37ad19a15709d0601afbac6581f5aea6a45da..d0dc6c97a6486f68bac782fff135086eae6d77ec
2022-10-25 10:18:58 -0700 to 2022-11-07 16:49:22 +0200
- trans -> codegen
- Remove implementation details
- Update some more things and improve wording
- Update query.md
- replace tabs with spaces (rust-lang/rustc-dev-guide#1504)
- align code blocks with their paragraphs
- Fixes some typos (rust-lang/rustc-dev-guide#1502)
- UPDATE - mention of Diagnostic derive on enums
- trans -> codegen (rust-lang/rustc-dev-guide#1500)
- add note for err annotation formatting
- Remove `--bless` from pre-push hook suggestion
- Update for highfive transition.
Rollup merge of #103929 - BlackHoleFox:apple-targets-cleanup, r=petrochenkov
Cleanup Apple-related code in rustc_target
While working on https://github.com/rust-lang/rust/pull/103455, the consistency of the `rustc_target` code for Apple's platforms was "kind of bad." There were two "base" files (`apple_base.rs` and `apple_sdk_base.rs`) that the targets each pulled some parts out of, each and all of them were written slightly differently, and sometimes missed comments other implementations had.
So to hopefully make future maintenance, like implementing https://github.com/rust-lang/compiler-team/issues/556, easier, this makes all of them use similar patterns and the same target base logic everywhere instead of picking bits from both. This also has some other smaller upsides like less stringly-typed functions.
Dylan DPC [Wed, 9 Nov 2022 13:51:25 +0000 (19:21 +0530)]
Rollup merge of #104125 - ink-feather-org:const_cmp_tuples, r=fee1-dead
Const Compare for Tuples
Makes the impls for Tuples of ~const `PartialEq` types also `PartialEq`, impls for Tuples of ~const `PartialOrd` types also `PartialOrd`, for Tuples of ~const `Ord` types also `Ord`.
behind the `#![feature(const_cmp)]` gate.
~~Do not merge before #104113 is merged because I want to use this feature to clean up the new test that I added there.~~
Dylan DPC [Wed, 9 Nov 2022 13:51:24 +0000 (19:21 +0530)]
Rollup merge of #104111 - yancyribbens:add-mutable-to-the-description-for-as-simd-mut, r=scottmcm
rustdoc: Add mutable to the description
Add mutable the description to differentiate [as_simd](https://github.com/rust-lang/rust/blob/master/library/core/src/slice/mod.rs#L3654) from [as_simd_mut](https://github.com/rust-lang/rust/blob/master/library/core/src/slice/mod.rs#L3654).
Dylan DPC [Wed, 9 Nov 2022 13:51:24 +0000 (19:21 +0530)]
Rollup merge of #103952 - ehuss:dont-intra-linkcheck-reference, 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.
Dylan DPC [Wed, 9 Nov 2022 13:51:21 +0000 (19:21 +0530)]
Rollup merge of #103570 - lukas-code:stabilize-ilog, r=scottmcm
Stabilize integer logarithms
Stabilizes feature `int_log`.
I've also made the functions const stable, because they don't depend on any unstable const features. `rustc_allow_const_fn_unstable` is just there for `Option::expect`, which could be replaced with a `match` and `panic!`. cc ``@rust-lang/wg-const-eval``
bors [Wed, 9 Nov 2022 10:24:27 +0000 (10:24 +0000)]
Auto merge of #102565 - jyn514:refactor-build-manifest, r=Mark-Simulacrum
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 d44e14225ab00e164aa9ea9e8d9e1bee40f96b3e
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.
Joshua Nelson [Wed, 9 Nov 2022 08:52:59 +0000 (02:52 -0600)]
Fix `rustdoc --version` when used with download-rustc
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.
bors [Wed, 9 Nov 2022 04:43:43 +0000 (04:43 +0000)]
Auto merge of #104179 - Manishearth:rollup-yvsx5hh, r=Manishearth
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`)
Rollup merge of #103353 - wesleywiser:fix_lld_thinlto_msvc, 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:
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.
Rollup merge of #101381 - Urgau:target-mixup-homogenous-floats, r=Amanieu
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](https://github.com/rust-lang/rust/blob/47d1cdb0bcac8e417071ce1929d261efe2399ae2/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.*
Rollup merge of #100508 - BoxyUwU:make_less_things_late_bound, r=nikomatsakis
avoid making substs of type aliases late bound when used as fn args
fixes #47511
fixes #85533
(although I did not know theses issues existed when i was working on this :upside_down_face:)
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.
bors [Wed, 9 Nov 2022 02:02:28 +0000 (02:02 +0000)]
Auto merge of #103171 - jackh726:gen-interior-hrtb-error, r=cjgillot
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.
bors [Tue, 8 Nov 2022 22:50:12 +0000 (22:50 +0000)]
Auto merge of #104168 - GuillaumeGomez:rollup-tf4edqc, r=GuillaumeGomez
Rollup of 12 pull requests
Successful merges:
- #103928 (Add 'ty_error_with_guaranteed' and 'const_error_with_guaranteed')
- #104027 (Place config.toml in current working directory if config not found)
- #104093 (disable btree size tests on Miri)
- #104097 (run alloc benchmarks in Miri and fix UB)
- #104104 (Add split-debuginfo print option)
- #104109 (rustdoc: Add mutable to the description)
- #104113 (Fix `const_fn_trait_ref_impl`, add test for it)
- #104114 (Fix invalid background-image file name)
- #104132 (fix: lint against lint functions)
- #104139 (Clarify licensing situation of MPSC and SPSC queue)
- #104147 (Remove an address comparison from the parser)
- #104165 (Add llvm-main to triagebot.toml)
Failed merges:
- #104115 (Migrate crate-search element to CSS variables)
Guillaume Gomez [Tue, 8 Nov 2022 19:40:53 +0000 (20:40 +0100)]
Rollup merge of #104147 - WaffleLapkin:don't-compare-ptr-addresses-in-parser-, r=compiler-errors
Remove an address comparison from the parser
Originally this check was added in #68985, as suggested by https://github.com/rust-lang/rust/pull/68985/commits/940f65782cc5df7fecad27b38cc25b6d1eeaf2e8#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`](https://github.com/rust-lang/rust/blob/57d3c58ed6e0faf89a62411f96c000ffc9fd3937/src/test/ui/parser/issues/issue-35813-postfix-after-cast.rs).
projects / rust.git / log