Use `structurally_normalize` instead of manual `normalizes-to` goals in alias relate errors
r? `@lcnr`
I added `structurally_normalize_term` so that code that is generic over ty or const can use the structurally normalize helpers. See `tests/ui/traits/next-solver/diagnostics/alias_relate_error_uses_structurally_normalize.rs` for a description of the reason for the (now fixed) ICEs
Make our `DIFlags` match `LLVMDIFlags` in the LLVM-C API
In order to be able to use a mixture of LLVM-C and C++ bindings for debuginfo, our Rust-side `DIFlags` needs to have the same layout as LLVM-C's `LLVMDIFlags`, and we also need to be able to convert it to the `DIFlags` accepted by LLVM's C++ API.
Internally, LLVM converts between the two types with a simple cast. We can't necessarily rely on that always being true, and LLVM doesn't expose a conversion function, so we have two potential options:
- Convert each bit/subvalue individually
- Statically assert that doing a cast is actually fine
As long as both types do remain the same under the hood (which seems likely), the static-assert-and-cast approach is easier and faster. If the static assertions ever start failing against some future version of LLVM, we'll have to switch over to the convert-each-subvalue approach, which is a bit more error-prone.
---
Extracted from #134009, though this PR ended up choosing the static-assert-and-cast approach over the convert-each-subvalue approach.
AIX: use align 8 for byval parameter
On AIX, byval pointer arguments are aligned to 8 bytes based on the 64bit register size. For example, the C callee https://godbolt.org/z/5f4vnG6bh will expect the following argument.
```
ptr nocapture noundef readonly byval(%struct.TwoU64s) align 8 %0
```
This case is captured by `run-make/extern-fn-explicit-align`
Refactor dyn-compatibility error and suggestions
This CL makes a number of small changes to dyn compatibility errors:
- "object safety" has been renamed to "dyn-compatibility" throughout
- "Convert to enum" suggestions are no longer generated when there exists a type-generic impl of the trait or an impl for `dyn OtherTrait`
- Several error messages are reorganized for user readability
Additionally, the dyn compatibility error creation code has been split out into functions.
cc #132713
cc #133267
r? `@compiler-errors`
This CL makes a number of small changes to dyn compatibility errors:
- "object safety" has been renamed to "dyn-compatibility" throughout
- "Convert to enum" suggestions are no longer generated when there
exists a type-generic impl of the trait or an impl for `dyn OtherTrait`
- Several error messages are reorganized for user readability
Additionally, the dyn compatibility error creation code has been
split out into functions.
cc #132713
cc #133267
Properly record metavar spans for other expansions other than TT
This properly records metavar spans for nonterminals other than tokentree. This means that we operations like `span.to(other_span)` work correctly for macros. As you can see, other diagnostics involving metavars have improved as a result.
Fixes#132908
Alternative to #133270
cc `@ehuss`
cc `@petrochenkov`
Update our range `assume`s to the format that LLVM prefers
I found out in https://github.com/llvm/llvm-project/issues/123278#issuecomment-2597440158 that the way I started emitting the `assume`s in #109993 was suboptimal, and as seen in that LLVM issue the way we're doing it -- with two `assume`s sometimes -- can at times lead to CVP/SCCP not realize what's happening because one of them turns into a `ne` instead of conveying a range.
So this updates how it's emitted from
```
assume( x >= LOW );
assume( x <= HIGH );
```
or
```
// (for ranges that wrap the range)
assume( (x <= LOW) | (x >= HIGH) );
```
to
```
assume( (x - LOW) <= (HIGH - LOW) );
```
so that we don't need multiple `icmp`s nor multiple `assume`s for a single value, and both wrappping and non-wrapping ranges emit the same shape.
(And we don't bother emitting the subtraction if `LOW` is zero, since that's trivial for us to check too.)
The candidate shouldn't have false_edge_start_block if it has sub candidates.
In remove_never_subcandidates(), the false_edge_start_block from the first sub candidte is assigned to a value and the value is later used if all sub candidates are removed and candidate doesn't have false_edge_start_block.
In merge_trivial_subcandidates, I leave the if block which assign a false_edge_start_block into the candidate as before I put this commit since compile panics.
Signed-off-by: Shunpoco <tkngsnsk313320@gmail.com>
Rollup of 8 pull requests
Successful merges:
- #132232 (CI: build FreeBSD artifacts on FreeBSD 13.4)
- #135706 (Move `supertrait_def_ids` into the elaborate module like all other fns)
- #135750 (Add an example of using `carrying_mul_add` to write wider multiplication)
- #135793 (Ignore `mermaid.min.js`)
- #135810 (Add Kobzol on vacation)
- #135821 (fix OsString::from_encoded_bytes_unchecked description)
- #135824 (tests: delete `cat-and-grep-sanity-check`)
- #135833 (Add fixme and test for issue #135289)
Failed merges:
- #135816 (Use `structurally_normalize` instead of manual `normalizes-to` goals in alias relate errors)
r? `@ghost`
`@rustbot` modify labels: rollup
```
error: couldn't read `$DIR/not-utf8-bin-file.rs`: stream did not contain valid UTF-8
--> $DIR/not-utf8-2.rs:6:5
|
LL | include!("not-utf8-bin-file.rs");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
note: `[193]` is not valid utf-8
--> $DIR/not-utf8-bin-file.rs:2:14
|
LL | let _ = "�|�␂!5�cc␕␂��";
| ^
= note: this error originates in the macro `include` (in Nightly builds, run with -Z macro-backtrace for more info)
```
When we attempt to load a Rust source code file, if there is a OS file failure we try reading the file as bytes. If that succeeds we try to turn it into UTF-8. If *that* fails, we provide additional context about *where* the file has the first invalid UTF-8 character.
Fix#76869.
This commit updates the `wasm-component-ld` tool from 0.5.11 to 0.5.12.
This pulls in a fix for the binary adapters that are included with this
tool for an issue described in bytecodealliance/wasmtime#10058. Some
other dependencies have additionally been updated in the meantime of
`wasm-component-ld` but there should otherwise be no major changes.
Add fixme and test for issue #135289
This PR:
- adds a test minimizing issue #135289 for PR #135310
- adds a fixme about the suboptimal fix for the ICE
I've verified the test indeed ICEs with 3f2f695d68 reverted.
r? `@estebank`
tests: delete `cat-and-grep-sanity-check`
Part of #121876.
All remaining `Makefile`s have open PRs that do not rely on platform `cat` or `grep` or the `cat-and-grep` script.
Add Kobzol on vacation
I will be mostly reviewing diaper contents in the upcoming weeks, so I'm (proactively, for now) removing myself from the auto review rotation. Feel free to CC me (explicit `r?` won't work) explicitly though, I will be around.
r? `````@ghost`````
Ignore `mermaid.min.js`
It is very long and tends to match a lot of search queries. It's not useful to show with ripgrep.
Note that this does not actually untrack the file; changes can still be committed (although I suspect it may not have been intentional to commit originally?). This just changes how it interacts with tools that use `.gitignore` as a default filter.
r? rustc-dev-guide
Add an example of using `carrying_mul_add` to write wider multiplication
Just the basic quadratic version that you wouldn't actually use for really-big integers, but it's nice and short so is useful as for a demonstration of why you might find `carrying_mul_add` useful :)
cc #85532 ``````@clarfonthey``````
CI: build FreeBSD artifacts on FreeBSD 13.4
13.2 is EoL, and 13.3 will be EoL too in about 2 months. Plus, both suffer from a bug in LLVM's libunwind. It causes a segfault inside of std::backtrace::Backtrace::capture().
Fixes#132185
cc ``````@ehuss`````` . before you can do the trybuild, you'll also have to download new FreeBSD 13.4 base.txz images and place them in https://ci-mirrors.rust-lang.org/rustc , then update this PR with the correct file names.
try-job: dist-x86_64-freebsd
try-job: dist-various-2
bump compiler and tools to windows 0.59, bootstrap to 0.57
This bumps compiler and tools to windows 0.59 (temporary dupes version, as `sysinfo` still depend on <= 0.57).
Bootstrap bumps only to 0.57 (the same sysinfo dep).
This additionally resolves my comment https://github.com/rust-lang/rust/pull/130874#issuecomment-2393562071
Will work on it in follow up pr: There still some sus imports for `rustc_driver.dll` like ws2_32 or RoOriginateErrorW, but i will look at them later.
When a struct definition has default field values, and the use struct ctor has missing field, if all those missing fields have defaults suggest `..`:
```
error[E0063]: missing fields `field1` and `field2` in initializer of `S`
--> $DIR/non-exhaustive-ctor.rs:16:13
|
LL | let _ = S { field: () };
| ^ missing `field1` and `field2`
|
help: all remaining fields have defaults, use `..`
|
LL | let _ = S { field: (), .. };
| ++++
```
remove support for the (unstable) #[start] attribute
As explained by `@Noratrieb:`
`#[start]` should be deleted. It's nothing but an accidentally leaked implementation detail that's a not very useful mix between "portable" entrypoint logic and bad abstraction.
I think the way the stable user-facing entrypoint should work (and works today on stable) is pretty simple:
- `std`-using cross-platform programs should use `fn main()`. the compiler, together with `std`, will then ensure that code ends up at `main` (by having a platform-specific entrypoint that gets directed through `lang_start` in `std` to `main` - but that's just an implementation detail)
- `no_std` platform-specific programs should use `#![no_main]` and define their own platform-specific entrypoint symbol with `#[no_mangle]`, like `main`, `_start`, `WinMain` or `my_embedded_platform_wants_to_start_here`. most of them only support a single platform anyways, and need cfg for the different platform's ways of passing arguments or other things *anyways*
`#[start]` is in a super weird position of being neither of those two. It tries to pretend that it's cross-platform, but its signature is a total lie. Those arguments are just stubbed out to zero on ~~Windows~~ wasm, for example. It also only handles the platform-specific entrypoints for a few platforms that are supported by `std`, like Windows or Unix-likes. `my_embedded_platform_wants_to_start_here` can't use it, and neither could a libc-less Linux program.
So we have an attribute that only works in some cases anyways, that has a signature that's a total lie (and a signature that, as I might want to add, has changed recently, and that I definitely would not be comfortable giving *any* stability guarantees on), and where there's a pretty easy way to get things working without it in the first place.
Note that this feature has **not** been RFCed in the first place.
*This comment was posted [in May](https://github.com/rust-lang/rust/issues/29633#issuecomment-2088596042) and so far nobody spoke up in that issue with a usecase that would require keeping the attribute.*
Closes https://github.com/rust-lang/rust/issues/29633
try-job: x86_64-gnu-nopt
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
try-job: test-various
