Improve niche placement by trying two strategies and picking the better result
Fixes#104807Fixes#105371
Determining which sort order is better requires calculating the struct size (so we can calculate the niche offset). But that in turn depends on the field order, so happens after sorting. So the simple way to solve that is to run the whole thing twice and pick the better result.
1st commit is just code motion, the meat is in the later ones.
This fixes the following recurring error on windows:
```
Traceback (most recent call last):
File "C:\Users\jyn\src\rust\x.py", line 29, in <module>
bootstrap.main()
File "C:\Users\jyn\src\rust\src\bootstrap\bootstrap.py", line 963, in main
bootstrap(args)
File "C:\Users\jyn\src\rust\src\bootstrap\bootstrap.py", line 927, in bootstrap
build.download_toolchain()
File "C:\Users\jyn\src\rust\src\bootstrap\bootstrap.py", line 437, in download_toolchain
shutil.rmtree(bin_root)
File "C:\Users\jyn\AppData\Local\Programs\Python\Python311\Lib\shutil.py", line 759, in rmtree
return _rmtree_unsafe(path, onerror)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\jyn\AppData\Local\Programs\Python\Python311\Lib\shutil.py", line 617, in _rmtree_unsafe
_rmtree_unsafe(fullname, onerror)
File "C:\Users\jyn\AppData\Local\Programs\Python\Python311\Lib\shutil.py", line 622, in _rmtree_unsafe
onerror(os.unlink, fullname, sys.exc_info())
File "C:\Users\jyn\AppData\Local\Programs\Python\Python311\Lib\shutil.py", line 620, in _rmtree_unsafe
os.unlink(fullname)
PermissionError: [WinError 5] Access is denied: 'C:\\Users\\jyn\\src\\rust\\build\\x86_64-pc-windows-msvc\\stage0\\bin\\rust-analyzer-proc-macro-srv.exe'
```
Don't duplicate anonymous lifetimes for async fn in traits
`record_lifetime_params_for_async` needs to be called outside of the scope of the function, or else it'll end up collecting anonymous lifetimes twice (those on the function and those within the `AnonymousCreateParameter` rib). This matches how `record_lifetime_params_for_async` is being used for functions with bodies below.
This fixes (partially) #110963 when the lifetimes are late-bound, but does not do so when the lifetimes are early-bound (as seen from the known-bug that I added).
Make sure that some stdlib method signatures aren't accidental refinements
In the process of implementing https://rust-lang.github.io/rfcs/3245-refined-impls.html, I found a bunch of stdlib implementations that accidentally "refined" their method signatures by dropping (unnecessary) bounds.
This isn't currently a problem, but may become one if/when method signature refining is stabilized in the future. Shouldn't hurt to make these signatures a bit more accurate anyways.
NOTE (just to be clear lol): This does not affect behavior at all, since we don't actually take advantage of refined implementations yet!
include source error for LoadLibraryExW
In #107595, we added retry behavior for LoadLibraryExW on Windows. If it fails we do not print the underlying error that Windows returned. This made #110889 a little harder to debug.
In this PR I am adding the source error in the message if it is available.
Clear response values for overflow in new solver
When we have an overflow, return a trivial query response. This fixes an ICE with the code described in #110544:
```rust
trait Trait {}
struct W<T>(T);
impl<T, U> Trait for W<(W<T>, W<U>)>
where
W<T>: Trait,
W<U>: Trait,
{}
fn impls<T: Trait>() {}
fn main() {
impls::<W<_>>()
}
```
Where, while proving `W<?0>: Trait`, we overflow but still apply the query response of `?0 = (W<?1>, W<?2>)`. Then while re-processing the query to validate that our evaluation result was stable, we get a different query response that looks like `?1 = (W<?3>, W<?4>), ?2 = (W<?5>, W<?6>)`, and so we trigger the ICE.
Also, by returning a trivial query response we also avoid the infinite-loop/OOM behavior of the old solver.
r? ``@lcnr``
Rollup of 8 pull requests
Successful merges:
- #110877 (Provide better type hints when a type doesn't support a binary operator)
- #110917 (only error combining +whole-archive and +bundle for rlibs)
- #110921 (Use `NonNull::new_unchecked` and `NonNull::len` in `rustc_arena`.)
- #110927 (Encoder/decoder cleanups)
- #110944 (share BinOp::Offset between CTFE and Miri)
- #110948 (run-make test: using single quotes to not trigger the shell)
- #110957 (Fix an ICE in conflict error diagnostics)
- #110960 (fix false negative for `unused_mut`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
For start-biased layout we want to avoid overpromoting so that
the niche doesn't get pushed back.
For end-biased layout we want to avoid promoting fields that
may contain one of the niches of interest.
fix false negative for `unused_mut`
fixes https://github.com/rust-lang/rust/issues/110849
We want to avoid double diagnostics for code like this, but only if an error actually occurs:
```rust
fn main() {
let mut x: (i32, i32);
x.0 = 1;
}
```
The first commit fixes the lint and the second one removes all the unused `mut`s it found.
run-make test: using single quotes to not trigger the shell
This test got added in #110801.
I'm no expert on Makefiles, but IIUC this command is passed to the shell, which usually tries to execute commands specified in between backticks in double-quoted strings.
Using single quotes should fix this, I think. (Note: Waiting for CI to test this, since I only have a web browser available right now).
r? ``@jyn514``
cc ``@WaffleLapkin``
Since this is breaking our build bot, even if it is not directly LLVM related: ``@rustbot`` label: +llvm-main
Use `NonNull::new_unchecked` and `NonNull::len` in `rustc_arena`.
This avoids a few extra dereferences as well as an `unwrap`.
According to the docs for [`NonNull::len`](https://doc.rust-lang.org/std/ptr/struct.NonNull.html#method.len) this also ensures that:
> This function is safe, even when the non-null raw slice cannot be dereferenced to a slice because the pointer does not have a valid address.
I am also fairly sure that the `unwrap` is unneeded in this case, as the docs for [`Box::into_raw`](https://doc.rust-lang.org/std/boxed/struct.Box.html#method.into_raw) also state:
> Consumes the Box, returning a wrapped raw pointer.
**The pointer will be properly aligned and non-null.**
only error combining +whole-archive and +bundle for rlibs
Fixes https://github.com/rust-lang/rust/issues/110912
Checking `flavor == RlibFlavor::Normal` was accidentally lost in 601fc8b36bhttps://github.com/rust-lang/rust/pull/105601
That caused combining +whole-archive and +bundle link modifiers on non-rlib crates to fail with a confusing error message saying that combination is unstable for rlibs. In particular, this caused the build to fail when +whole-archive was used on staticlib crates, even though +whole-archive effectively does nothing on non-bin crates because the final linker invocation is left to an external build system.
cc ``@petrochenkov``
Provide better type hints when a type doesn't support a binary operator
For example, when checking whether `vec![A] == vec![A]` holds, we first evaluate the LHS's ty, then probe for any `PartialEq` implementations for that. If none is found, we report an error by evaluating `Vec<A>: PartialEq<?0>` for fulfillment errors, but the RHS is not yet evaluated and remains an inference variable `?0`!
To fix this, we evaluate the RHS and equate it to that RHS infer var `?0`, so that we are able to provide more detailed fulfillment errors for why `Vec<A>: PartialEq<Vec<A>>` doesn't hold (namely, the nested obligation `A: PartialEq<A>` doesn't hold).
Fixes#95285Fixes#110867
In the old setup, if the dereffed-to item has multiple impl blocks,
each one gets its own `div.impl-items` in the section, but there
are no headers separating them. Since the last method in a
`div.impl-items` has no bottom margin, and there are no margins
between these divs, there is no margin between the last method
of one impl and the first method of the following impl.
This patch fixes it by simplifying the HTML. Each Deref block gets
exactly one `div.impl-items`, no matter how many impl blocks it
actually has.
Update awscli
The Windows GitHub Actions image just updated to pip 23.1.1 which broke the PyYaml installer in the current AWS CLI mirror. It now requires setuptools, wheel, and Cython to be installed manually. This updates to include that, as well as updating the versions of all the packages. This also now uses python3 on macOS since python2 doesn't work with the newer versions.
I have only tested that these install correctly, but not that they work correctly.
Pietro mentioned that we should just switch to aws cli 2, which I agree is probably the better solution. I'm posting this PR in case it helps unblock CI.