1
Fork 0
Commit graph

279875 commits

Author SHA1 Message Date
Michael Goulet
304b3cfcb2 Manually walk into WF obligations in BestObligation proof tree visitor 2025-01-31 18:21:58 +00:00
Michael Goulet
d8b176f683 Move fulfillment error derivation into new module 2025-01-31 18:16:02 +00:00
bors
7f36543a48 Auto merge of #136332 - jhpratt:rollup-aa69d0e, r=jhpratt
Rollup of 9 pull requests

Successful merges:

 - #132156 (When encountering unexpected closure return type, point at return type/expression)
 - #133429 (Autodiff Upstreaming - rustc_codegen_ssa, rustc_middle)
 - #136281 (`rustc_hir_analysis` cleanups)
 - #136297 (Fix a typo in profile-guided-optimization.md)
 - #136300 (atomic: extend compare_and_swap migration docs)
 - #136310 (normalize `*.long-type.txt` paths for compare-mode tests)
 - #136312 (Disable `overflow_delimited_expr` in edition 2024)
 - #136313 (Filter out RPITITs when suggesting unconstrained assoc type on too many generics)
 - #136323 (Fix a typo in conventions.md)

r? `@ghost`
`@rustbot` modify labels: rollup
2025-01-31 09:42:28 +00:00
bors
25a16572a3 Auto merge of #136331 - jhpratt:rollup-curo1f4, r=jhpratt
Rollup of 8 pull requests

Successful merges:

 - #135414 (Stabilize `const_black_box`)
 - #136150 (ci: use windows 2025 for i686-mingw)
 - #136258 (rustdoc: rename `issue-\d+.rs` tests to have meaningful names (part 11))
 - #136270 (Remove `NamedVarMap`.)
 - #136278 (add constraint graph to polonius MIR dump)
 - #136287 (LLVM changed the nocapture attribute to captures(none))
 - #136291 (some test suite cleanups)
 - #136296 (float::min/max: mention the non-determinism around signed 0)

r? `@ghost`
`@rustbot` modify labels: rollup
2025-01-31 06:55:04 +00:00
Jacob Pratt
e429adaeb1
Rollup merge of #136323 - etaoins:fix-typo-in-conventions-md, r=tgross35
Fix a typo in conventions.md

Introduced in #135950
2025-01-31 00:26:35 -05:00
Jacob Pratt
e6285b8ff1
Rollup merge of #136313 - compiler-errors:too-many-args, r=lqd
Filter out RPITITs when suggesting unconstrained assoc type on too many generics

Fixes #136233
2025-01-31 00:26:34 -05:00
Jacob Pratt
15ef406f9d
Rollup merge of #136312 - compiler-errors:overflow_delimited_expr-2024, r=ytmimi
Disable `overflow_delimited_expr` in edition 2024

This reverts the style guide changes and sets the default to "false" in rustfmt for style edition 2024.

r? `@ytmimi`

cc `@rust-lang/style` `@rust-lang/rustfmt`
2025-01-31 00:26:33 -05:00
Jacob Pratt
4e64180917
Rollup merge of #136310 - lqd:long-types, r=compiler-errors
normalize `*.long-type.txt` paths for compare-mode tests

When using a compare mode, the name of the test + compare-mode is embedded in some of rustc's output, like the location where a long type `bla.long-type(-some-hash)?.txt` is written to. That generally makes these tests fail under all compare-modes.

This PR fixes this by normalizing the compare-mode suffix away in the stderr output. We can also see some remnants of the long-removed `nll` compare mode being normalized away ^^.

I did this to fix some failures with `--compare-mode next-solver` (but it also fixes them with e.g. `--compare-mode polonius` of course):
- it makes 9 new tests pass with the new solver
- however, 3 tests I changed here still don't pass with the new solver (IIRC there were 2 ICEs, and some duplicate errors for the 3rd one)

(There was also one that triggered slowness in the new solver while triggering the long type failure, I'll mention this on zulip. )
2025-01-31 00:26:33 -05:00
Jacob Pratt
e2a73ab7ad
Rollup merge of #136300 - RalfJung:compare-and-swap, r=joboet
atomic: extend compare_and_swap migration docs

Fixes https://github.com/rust-lang/rust/issues/80486
2025-01-31 00:26:32 -05:00
Jacob Pratt
fc25599f4e
Rollup merge of #136297 - zeenix:patch-1, r=lqd
Fix a typo in profile-guided-optimization.md

It's either "profile-guided" or "profiled-guided" and I think it'sw the former. :)
2025-01-31 00:26:31 -05:00
Jacob Pratt
940b45f27c
Rollup merge of #136281 - nnethercote:rustc_hir_analysis, r=lcnr
`rustc_hir_analysis` cleanups

Just some improvements I found while looking through this code.

r? `@lcnr`
2025-01-31 00:26:31 -05:00
Jacob Pratt
c19c4b91f5
Rollup merge of #133429 - EnzymeAD:autodiff-middle, r=oli-obk
Autodiff Upstreaming - rustc_codegen_ssa, rustc_middle

This PR should not be merged until the rustc_codegen_llvm part is merged.
I will also alter it a little based on what get's shaved off from the cg_llvm PR,
and address some of the feedback I received in the other PR (including cleanups).

I am putting it already up to
1) Discuss with `@jieyouxu` if there is more work needed to add tests to this and
2) Pray that there is someone reviewing who can tell me why some of my autodiff invocations get lost.

Re 1: My test require fat-lto. I also modify the compilation pipeline. So if there are any other llvm-ir tests in the same compilation unit then I will likely break them. Luckily there are two groups who currently have the same fat-lto requirement for their GPU code which I have for my autodiff code and both groups have some plans to enable support for thin-lto. Once either that work pans out, I'll copy it over for this feature. I will also work on not changing the optimization pipeline for functions not differentiated, but that will require some thoughts and engineering, so I think it would be good to be able to run the autodiff tests isolated from the rest for now. Can you guide me here please?
For context, here are some of my tests in the samples folder: https://github.com/EnzymeAD/rustbook

Re 2: This is a pretty serious issue, since it effectively prevents publishing libraries making use of autodiff: https://github.com/EnzymeAD/rust/issues/173. For some reason my dummy code persists till the end, so the code which calls autodiff, deletes the dummy, and inserts the code to compute the derivative never gets executed. To me it looks like the rustc_autodiff attribute just get's dropped, but I don't know WHY? Any help would be super appreciated, as rustc queries look a bit voodoo to me.

Tracking:

- https://github.com/rust-lang/rust/issues/124509

r? `@jieyouxu`
2025-01-31 00:26:30 -05:00
Jacob Pratt
ae9dbf169f
Rollup merge of #132156 - estebank:closure-return, r=Nadrieril,compiler-errors
When encountering unexpected closure return type, point at return type/expression

```
error[E0271]: expected `{closure@fallback-closure-wrap.rs:18:40}` to be a closure that returns `()`, but it returns `!`
  --> $DIR/fallback-closure-wrap.rs:19:9
   |
LL |     let error = Closure::wrap(Box::new(move || {
   |                                        -------
LL |         panic!("Can't connect to server.");
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `()`, found `!`
   |
   = note: expected unit type `()`
                   found type `!`
   = note: required for the cast from `Box<{closure@$DIR/fallback-closure-wrap.rs:18:40: 18:47}>` to `Box<dyn FnMut()>`
```

```
error[E0271]: expected `{closure@dont-ice-for-type-mismatch-in-closure-in-async.rs:6:10}` to be a closure that returns `bool`, but it returns `Option<()>`
  --> $DIR/dont-ice-for-type-mismatch-in-closure-in-async.rs:6:16
   |
LL |     call(|| -> Option<()> {
   |     ---- ------^^^^^^^^^^
   |     |          |
   |     |          expected `bool`, found `Option<()>`
   |     required by a bound introduced by this call
   |
   = note: expected type `bool`
              found enum `Option<()>`
note: required by a bound in `call`
  --> $DIR/dont-ice-for-type-mismatch-in-closure-in-async.rs:3:25
   |
LL | fn call(_: impl Fn() -> bool) {}
   |                         ^^^^ required by this bound in `call`
```

```
error[E0271]: expected `{closure@f670.rs:28:13}` to be a closure that returns `Result<(), _>`, but it returns `!`
    --> f670.rs:28:20
     |
28   |     let c = |e| -> ! {
     |             -------^
     |                    |
     |                    expected `Result<(), _>`, found `!`
...
32   |     f().or_else(c);
     |         ------- required by a bound introduced by this call
-Ztrack-diagnostics: created at compiler/rustc_trait_selection/src/error_reporting/traits/fulfillment_errors.rs:1433:28
     |
     = note: expected enum `Result<(), _>`
                found type `!`
note: required by a bound in `Result::<T, E>::or_else`
    --> /home/gh-estebank/rust/library/core/src/result.rs:1406:39
     |
1406 |     pub fn or_else<F, O: FnOnce(E) -> Result<T, F>>(self, op: O) -> Result<T, F> {
     |                                       ^^^^^^^^^^^^ required by this bound in `Result::<T, E>::or_else`
```

CC #111539.
2025-01-31 00:26:29 -05:00
Jacob Pratt
08dc8c931f
Rollup merge of #136296 - RalfJung:float-min-max, r=tgross35
float::min/max: mention the non-determinism around signed 0

Turns out this can actually produce different results on different machines [in practice](https://github.com/rust-lang/rust/issues/83984#issuecomment-2623859230); that seems worth documenting. I assume LLVM will happily const-fold these operations so so there could be different results for the same input even on the same machine, depending on whether things get const-folded or not.

`@nikic` I remember there was an LLVM soundness fix regarding scalar evolution for loops that had to recognize certain operations as non-deterministic... it seems to me that pass would also have to avoid predicting the result of `llvm.{min,max}num`, for the same reason?

r? `@tgross35`
Cc `@rust-lang/libs-api`

If this lands we should also make Miri non-deterministic here.

Fixes https://github.com/rust-lang/rust/issues/83984
2025-01-31 00:25:38 -05:00
Jacob Pratt
55512db4aa
Rollup merge of #136291 - lcnr:compare-mode, r=oli-obk
some test suite cleanups

found while checking `compare-mode next-solver`

r? `@oli-obk`

<sub> [lcnr](https://github.com/rust-lang/rust/commits?author=lcnr) authored and JJ_EMPTY_STRING committed </sub>
2025-01-31 00:25:38 -05:00
Jacob Pratt
b87df231c5
Rollup merge of #136287 - zmodem:nocapture, r=nikic
LLVM changed the nocapture attribute to captures(none)

This updates RustWrapper.cpp and tests after
https://github.com/llvm/llvm-project/pull/123181
2025-01-31 00:25:37 -05:00
Jacob Pratt
8b409e44da
Rollup merge of #136278 - lqd:polonius-debugger-episode-3, r=matthewjasper
add constraint graph to polonius MIR dump

Another easy one while I work on diagnostics. This PR adds a mermaid visualization of the polonius constraint graph to the polonius MIR dump.

Adding kills is left to a future PR (until they're encoded in edges directly or I set up recording debugging info in and out of the analysis), because right now they're only computed during traversal.

[Here's](https://gistpreview.github.io/?096b0131e8258f9a3125c55c7ac369bc) how that looks.

 r? `@matthewjasper` but as always feel free to reroll.
2025-01-31 00:25:36 -05:00
Jacob Pratt
dcf1134386
Rollup merge of #136270 - nnethercote:rm-NamedVarMap, r=jackh726
Remove `NamedVarMap`.

`NamedVarMap` is extremely similar to `ResolveBoundVars`. The former contains two `UnordMap<ItemLocalId, T>` fields (obscured behind `ItemLocalMap` typedefs). The latter contains two
`SortedMap<ItemLocalId, T>` fields. We construct a `NamedVarMap` and then convert it into a `ResolveBoundVars` by sorting the `UnordMap`s, which is unnecessary busywork.

This commit removes `NamedVarMap` and constructs a `ResolveBoundVars` directly. `SortedMap` and `NamedVarMap` have slightly different perf characteristics during construction (e.g. speed of insertion) but this code isn't hot enough for that to matter.

A few details to note.
- A `FIXME` comment is removed.
- The detailed comments on the fields of `NamedVarMap` are copied to `ResolveBoundVars` (which has a single, incorrect comment).
- `BoundVarContext::map` is renamed.
- `ResolveBoundVars` gets a derived `Default` impl.

r? `@jackh726`
2025-01-31 00:25:36 -05:00
Jacob Pratt
1a5ebc9e52
Rollup merge of #136258 - notriddle:notriddle/issue-d, r=fmease
rustdoc: rename `issue-\d+.rs` tests to have meaningful names (part 11)

Follow up

* https://github.com/rust-lang/rust/pull/134053
* https://github.com/rust-lang/rust/pull/130287

et al

As always, it's easier to review the commits one at a time. Don't use the Files Changed tab. It's confusing.
2025-01-31 00:25:35 -05:00
Jacob Pratt
7f05c7e50c
Rollup merge of #136150 - marcoieni:windows-25-i686-mingw, r=Kobzol
ci: use windows 2025 for i686-mingw

try-job: i686-mingw
2025-01-31 00:25:35 -05:00
Jacob Pratt
b249760c51
Rollup merge of #135414 - tgross35:stabilize-const_black_box, r=dtolnay
Stabilize `const_black_box`

This has been unstably const since #92226, but a tracking issue was never created. Per [discussion on Zulip][zulip], there should not be any blockers to making this const-stable. The function does not provide any functionality at compile time but does allow code reuse between const- and non-const functions, so stabilize it here.

[zulip]: https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/const_black_box
2025-01-31 00:25:34 -05:00
bors
c37fbd873a Auto merge of #135318 - compiler-errors:vtable-fixes, r=lcnr
Fix deduplication mismatches in vtables leading to upcasting unsoundness

We currently have two cases where subtleties in supertraits can trigger disagreements in the vtable layout, e.g. leading to a different vtable layout being accessed at a callsite compared to what was prepared during unsizing. Namely:

### #135315

In this example, we were not normalizing supertraits when preparing vtables. In the example,

```
trait Supertrait<T> {
    fn _print_numbers(&self, mem: &[usize; 100]) {
        println!("{mem:?}");
    }
}
impl<T> Supertrait<T> for () {}

trait Identity {
    type Selff;
}
impl<Selff> Identity for Selff {
    type Selff = Selff;
}

trait Middle<T>: Supertrait<()> + Supertrait<T> {
    fn say_hello(&self, _: &usize) {
        println!("Hello!");
    }
}
impl<T> Middle<T> for () {}

trait Trait: Middle<<() as Identity>::Selff> {}
impl Trait for () {}

fn main() {
    (&() as &dyn Trait as &dyn Middle<()>).say_hello(&0);
}
```

When we prepare `dyn Trait`, we see a supertrait of `Middle<<() as Identity>::Selff>`, which itself has two supertraits `Supertrait<()>` and `Supertrait<<() as Identity>::Selff>`. These two supertraits are identical, but they are not duplicated because we were using structural equality and *not* considering normalization. This leads to a vtable layout with two trait pointers.

When we upcast to `dyn Middle<()>`, those two supertraits are now the same, leading to a vtable layout with only one trait pointer. This leads to an offset error, and we call the wrong method.

### #135316

This one is a bit more interesting, and is the bulk of the changes in this PR. It's a bit similar, except it uses binder equality instead of normalization to make the compiler get confused about two vtable layouts. In the example,

```
trait Supertrait<T> {
    fn _print_numbers(&self, mem: &[usize; 100]) {
        println!("{mem:?}");
    }
}
impl<T> Supertrait<T> for () {}

trait Trait<T, U>: Supertrait<T> + Supertrait<U> {
    fn say_hello(&self, _: &usize) {
        println!("Hello!");
    }
}
impl<T, U> Trait<T, U> for () {}

fn main() {
    (&() as &'static dyn for<'a> Trait<&'static (), &'a ()>
        as &'static dyn Trait<&'static (), &'static ()>)
        .say_hello(&0);
}
```

When we prepare the vtable for `dyn for<'a> Trait<&'static (), &'a ()>`, we currently consider the PolyTraitRef of the vtable as the key for a supertrait. This leads two two supertraits -- `Supertrait<&'static ()>` and `for<'a> Supertrait<&'a ()>`.

However, we can upcast[^up] without offsetting the vtable from `dyn for<'a> Trait<&'static (), &'a ()>` to `dyn Trait<&'static (), &'static ()>`. This is just instantiating the principal trait ref for a specific `'a = 'static`. However, when considering those supertraits, we now have only one distinct supertrait -- `Supertrait<&'static ()>` (which is deduplicated since there are two supertraits with the same substitutions). This leads to similar offsetting issues, leading to the wrong method being called.

[^up]: I say upcast but this is a cast that is allowed on stable, since it's not changing the vtable at all, just instantiating the binder of the principal trait ref for some lifetime.

The solution here is to recognize that a vtable isn't really meaningfully higher ranked, and to just treat a vtable as corresponding to a `TraitRef` so we can do this deduplication more faithfully. That is to say, the vtable for `dyn for<'a> Tr<'a>` and `dyn Tr<'x>` are always identical, since they both would correspond to a set of free regions on an impl... Do note that `Tr<for<'a> fn(&'a ())>` and `Tr<fn(&'static ())>` are still distinct.

----

There's a bit more that can be cleaned up. In codegen, we can stop using `PolyExistentialTraitRef` basically everywhere. We can also fix SMIR to stop storing `PolyExistentialTraitRef` in its vtable allocations.

As for testing, it's difficult to actually turn this into something that can be tested with `rustc_dump_vtable`, since having multiple supertraits that are identical is a recipe for ambiguity errors. Maybe someone else is more creative with getting that attr to work, since the tests I added being run-pass tests is a bit unsatisfying. Miri also doesn't help here, since it doesn't really generate vtables that are offset by an index in the same way as codegen.

r? `@lcnr` for the vibe check? Or reassign, idk. Maybe let's talk about whether this makes sense.

<sup>(I guess an alternative would also be to not do any deduplication of vtable supertraits (or only a really conservative subset) rather than trying to normalize and deduplicate more faithfully here. Not sure if that works and is sufficient tho.)</sup>

cc `@steffahn` -- ty for the minimizations
cc `@WaffleLapkin` -- since you're overseeing the feature stabilization :3

Fixes #135315
Fixes #135316
2025-01-31 04:09:11 +00:00
Ryan Cumming
ba5386aeed
Fix a typo in conventions.md
Introduced in #135950
2025-01-31 10:23:46 +11:00
bors
6c1d960d88 Auto merge of #136318 - matthiaskrgr:rollup-a159mzo, r=matthiaskrgr
Rollup of 9 pull requests

Successful merges:

 - #135026 (Cast global variables to default address space)
 - #135475 (uefi: Implement path)
 - #135852 (Add `AsyncFn*` to `core` prelude)
 - #136004 (tests: Skip const OOM tests on aarch64-unknown-linux-gnu)
 - #136157 (override build profile for bootstrap tests)
 - #136180 (Introduce a wrapper for "typed valtrees" and properly check the type before extracting the value)
 - #136256 (Add release notes for 1.84.1)
 - #136271 (Remove minor future footgun in `impl Debug for MaybeUninit`)
 - #136288 (Improve documentation for file locking)

r? `@ghost`
`@rustbot` modify labels: rollup
2025-01-30 23:11:38 +00:00
Nicholas Nethercote
483307f127 Don't export rustc_hir_analysis::collect.
Instead re-export `rustc_hir_analysis::collect::suggest_impl_trait`,
which is the only thing from the module used in another crate. This
fixes a `FIXME` comment. Also adjust some visibilities to satisfy the
`unreachable_pub` lint.

This changes requires downgrading a link in a comment on `FnCtxt`
because `collect` is no longer public and rustdoc complains otherwise.
This is annoying but I can't see how to avoid it.
2025-01-31 08:36:30 +11:00
Nicholas Nethercote
29317604d1 Remove xform submodule.
It used to be bigger, with an `Xform` trait, but now it has just a
single function.
2025-01-31 08:28:28 +11:00
Nicholas Nethercote
4e2ef694f3 Remove an unnecessary loop label. 2025-01-31 08:28:28 +11:00
Nicholas Nethercote
d8be00fd44 Fix a comment typo. 2025-01-31 08:28:14 +11:00
Nicholas Nethercote
40db88979d Use .and chaining to improve readability. 2025-01-31 08:27:16 +11:00
Nicholas Nethercote
ceb09de256 Remove an unnecessary lifetime from RemapLateParam. 2025-01-31 08:27:15 +11:00
Nicholas Nethercote
c2e37d32d5 Remove an unused arg from the trait method provided_kind. 2025-01-31 08:27:15 +11:00
Nicholas Nethercote
969d9336ca Remove unnecessary builders.
`delegation.rs` has three builders: `GenericsBuilder`,
`PredicatesBuilder`, and `GenericArgsBuilder`. The first two builders
have just two optional parameters, and the third one has zero. Each
builder is used within a single function. The code is over-engineered.

This commit removes the builders, replacing each with with a single
`build_*` function. This makes the code shorter and simpler.
2025-01-31 08:27:15 +11:00
Nicholas Nethercote
7be593e379 Format delegation.rs better.
There is a comment `Delegation to inherent methods is not yet
supported.` that appears three times mid-pattern and somehow inhibits
rustfmt from formatting the enclosing `match` statement. This commit
moves them to the top of the pattern, which enables more formatting.
2025-01-31 08:27:15 +11:00
Nicholas Nethercote
cab629fbd2 Merge two identical match arms.
Note: `inherit_predicates_for_delegation_item` already has these cases
merged.
2025-01-31 08:27:15 +11:00
Nicholas Nethercote
2dbe9fd8a6 Remove an out-of-date FIXME comment.
This comment made sense when this crate was called `rustc_typeck`, but
makes less sense now that it's called `rustc_hir_analysis`. Especially
given that `check_drop_impl` is only called within the crate.
2025-01-31 08:27:15 +11:00
Nicholas Nethercote
f453f930ab Merge two match arms that are identical.
Also rewrite the merged arm slightly to more closely match the arm above
it.
2025-01-31 08:27:15 +11:00
Nicholas Nethercote
b546334f6c Avoid a duplicated error case in fn_sig_suggestion. 2025-01-31 08:27:15 +11:00
Nicholas Nethercote
97d1b0cbcd Clarify a comment.
I was confused here for a bit.
2025-01-31 08:27:15 +11:00
bors
a730edcd67 Auto merge of #135030 - Flakebi:require-cpu, r=workingjubilee
Target option to require explicit cpu

Some targets have many different CPUs and no generic CPU that can be used as a default. For these targets, the user needs to explicitly specify a CPU through `-C target-cpu=`.

Add an option for targets and an error message if no CPU is set.

This affects the proposed amdgpu and avr targets.

amdgpu tracking issue: #135024
AVR MCP: https://github.com/rust-lang/compiler-team/issues/800
2025-01-30 20:21:50 +00:00
Matthias Krüger
867317835d
Rollup merge of #136288 - joshtriplett:would-you-could-you-with-some-locks--would-you-could-you-in-some-docs, r=m-ou-se
Improve documentation for file locking

Add notes to each method stating that locks get dropped on close.

Clarify the return values of the try methods: they're only defined if
the lock is held via a *different* file handle/descriptor. That goes
along with the documentation that calling them while holding a lock via
the *same* file handle/descriptor may deadlock.

Document the behavior of unlock if no lock is held.

r? `@m-ou-se`
(Documentation changes requested in https://github.com/rust-lang/rust/issues/130994 .)
2025-01-30 20:47:09 +01:00
Matthias Krüger
410442f610
Rollup merge of #136271 - Sky9x:debug-maybeuninit-footgun, r=tgross35
Remove minor future footgun in `impl Debug for MaybeUninit`

No longer breaks if `MaybeUninit` moves modules (technically it could break if `MaybeUninit` were renamed but realistically that will never happen)

Debug impl originally added in #133282
2025-01-30 20:47:08 +01:00
Matthias Krüger
41c8ce99a9
Rollup merge of #136256 - cuviper:relnotes-1.84.1, r=pietroalbini
Add release notes for 1.84.1

r? `@Mark-Simulacrum`
2025-01-30 20:47:08 +01:00
Matthias Krüger
6a66a270b0
Rollup merge of #136180 - lukas-code:typed-valtree, r=oli-obk
Introduce a wrapper for "typed valtrees" and properly check the type before extracting the value

This PR adds a new wrapper type `ty::Value` to replace the tuple `(Ty, ty::ValTree)` and become the new canonical representation of type-level constant values.

The value extraction methods `try_to_bits`/`try_to_bool`/`try_to_target_usize` are moved to this new type. For `try_to_bits` in particular, this avoids some redundant matches on `ty::ConstKind::Value`. Furthermore, these methods and will now properly check the type before extracting the value, which fixes some ICEs.

The name `ty::Value` was chosen to be consistent with `ty::Expr`.

Commit 1 should be non-functional and commit 2 adds the type check.

---

fixes https://github.com/rust-lang/rust/issues/131102
supercedes https://github.com/rust-lang/rust/pull/136130

r? `@oli-obk`
cc `@FedericoBruzzone` `@BoxyUwU`
2025-01-30 20:47:07 +01:00
Matthias Krüger
6c9c69813d
Rollup merge of #136157 - onur-ozkan:override-release-profile, r=Kobzol
override build profile for bootstrap tests

Using the release profile for bootstrap self tests puts too much load on the CPU and makes it quite hot on `x test bootstrap` invocation for no good reason. It also makes the compilation take longer than usual (see https://github.com/rust-lang/rust/pull/136048#issuecomment-2616908484). This change turns off the release flag for bootstrap self tests.
2025-01-30 20:47:07 +01:00
Matthias Krüger
47ee068a88
Rollup merge of #136004 - mrkajetanp:aarch64-skip-large-const-alloc-tests, r=Kobzol
tests: Skip const OOM tests on aarch64-unknown-linux-gnu

Skip const OOM tests on AArch64 Linux through explicit annotations instead of inside opt-dist.
Intended to avoid confusion in cases like #135952.

Prerequisite for https://github.com/rust-lang/rust/pull/135960.

 r? `@Kobzol`
cc `@workingjubilee`

try-job: dist-aarch64-linux
2025-01-30 20:47:06 +01:00
Matthias Krüger
c32f2c7172
Rollup merge of #135852 - lukas-code:asyncfn-prelude-core, r=compiler-errors
Add `AsyncFn*` to `core` prelude

In https://github.com/rust-lang/rust/pull/132611 these got added to the `std` prelude only, which looks like an oversight.

r? libs-api
cc `@compiler-errors`
2025-01-30 20:47:05 +01:00
Matthias Krüger
55c7a02a8b
Rollup merge of #135475 - Ayush1325:uefi-absolute-path, r=jhpratt
uefi: Implement path

This PR is split off from https://github.com/rust-lang/rust/pull/135368 to reduce noise.

UEFI paths can be of 4 types:
1. Absolute Shell Path: Uses shell mappings
2. Absolute Device Path: this is what we want
3. Relative root: path relative to the current root.
4. Relative

Absolute shell path can be identified with `:` and Absolute Device path can be identified with `/`. Relative root path will start with `\`.

The algorithm is mostly taken from edk2 UEFI shell implementation and is somewhat simple. Check for the path type in order.

For Absolute Shell path, use `EFI_SHELL->GetDevicePathFromMap` to get a BorrowedDevicePath for the volume.

For Relative paths, we use the current working directory to construct the new path.

BorrowedDevicePath abstraction is needed to interact with `EFI_SHELL->GetDevicePathFromMap` which returns a Device Path Protocol with the lifetime of UEFI shell.

Absolute Shell paths cannot exist if UEFI shell is missing.

cc `@nicholasbishop`
2025-01-30 20:47:04 +01:00
Matthias Krüger
89f8abe8b4
Rollup merge of #135026 - Flakebi:global-addrspace, r=saethlin
Cast global variables to default address space

Pointers for variables all need to be in the same address space for correct compilation. Therefore ensure that even if a global variable is created in a different address space, it is casted to the default address space before its value is used.

This is necessary for the amdgpu target and others where the default address space for global variables is not 0.

For example `core` does not compile in debug mode when not casting the address space to the default one because it tries to emit the following (simplified) LLVM IR, containing a type mismatch:

```llvm
`@alloc_0` = addrspace(1) constant <{ [6 x i8] }> <{ [6 x i8] c"bit.rs" }>, align 1
`@alloc_1` = addrspace(1) constant <{ ptr }> <{ ptr addrspace(1) `@alloc_0` }>, align 8
; ^ here a struct containing a `ptr` is needed, but it is created using a `ptr addrspace(1)`
```

For this to compile, we need to insert a constant `addrspacecast` before we use a global variable:

```llvm
`@alloc_0` = addrspace(1) constant <{ [6 x i8] }> <{ [6 x i8] c"bit.rs" }>, align 1
`@alloc_1` = addrspace(1) constant <{ ptr }> <{ ptr addrspacecast (ptr addrspace(1) `@alloc_0` to ptr) }>, align 8
```

As vtables are global variables as well, they are also created with an `addrspacecast`. In the SSA backend, after a vtable global is created, metadata is added to it. To add metadata, we need the non-casted global variable. Therefore we strip away an addrspacecast if there is one, to get the underlying global.

Tracking issue: #135024
2025-01-30 20:47:02 +01:00
Michael Howell
c17d5689da
Direct link 108459 to issues -> pull redirect 2025-01-30 12:09:33 -07:00
Michael Howell
a1a55a2e0a Give 104145, 103463, and 31948 more descriptive names 2025-01-30 12:05:31 -07:00