1
Fork 0
Commit graph

36471 commits

Author SHA1 Message Date
bors
f2208b3297 Auto merge of #123572 - Mark-Simulacrum:vtable-methods, r=oli-obk
Increase vtable layout size

This improves LLVM's codegen by allowing vtable loads to be hoisted out of loops (as just one example). The calculation here is an under-approximation but works for simple trait hierarchies (e.g., FnMut will be improved). We have a runtime assert that the approximation is accurate, so there's no risk of UB as a result of getting this wrong.

```rust
#[no_mangle]
pub fn foo(elements: &[u32], callback: &mut dyn Callback) {
    for element in elements.iter() {
        if *element != 0 {
            callback.call(*element);
        }
    }
}

pub trait Callback {
    fn call(&mut self, _: u32);
}
```

Simplifying a bit (e.g., numbering ends up different):

```diff
 ; Function Attrs: nonlazybind uwtable
-define void `@foo(ptr` noalias noundef nonnull readonly align 4 %elements.0, i64 noundef %elements.1, ptr noundef nonnull align 1 %callback.0, ptr noalias nocapture noundef readonly align 8 dereferenceable(24) %callback.1) unnamed_addr #0 {
+define void `@foo(ptr` noalias noundef nonnull readonly align 4 %elements.0, i64 noundef %elements.1, ptr noundef nonnull align 1 %callback.0, ptr noalias nocapture noundef readonly align 8 dereferenceable(32) %callback.1) unnamed_addr #0 {
 start:
   %_15 = getelementptr inbounds i32, ptr %elements.0, i64 %elements.1
`@@` -13,4 +13,5 `@@`
 bb4.lr.ph:                                        ; preds = %start
   %1 = getelementptr inbounds i8, ptr %callback.1, i64 24
+  %2 = load ptr, ptr %1, align 8, !nonnull !3
   br label %bb4

 bb6:                                              ; preds = %bb4
-  %4 = load ptr, ptr %1, align 8, !invariant.load !3, !nonnull !3
-  tail call void %4(ptr noundef nonnull align 1 %callback.0, i32 noundef %_9)
+  tail call void %2(ptr noundef nonnull align 1 %callback.0, i32 noundef %_9)
   br label %bb7
 }
```
2024-06-01 14:31:07 +00:00
bors
acaf0aeed0 Auto merge of #125821 - Luv-Ray:issue#121126, r=fee1-dead
Check index `value <= 0xFFFF_FF00`

<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.

This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using

    r​? <reviewer name>
-->
fixes #121126

check `idx <= FieldIdx::MAX_AS_U32` before calling `FieldIdx::from_u32` to avoid panic.
2024-06-01 12:24:44 +00:00
Mark Rousskov
95e073234f Deduplicate supertrait_def_ids code 2024-06-01 07:50:32 -04:00
Mark Rousskov
dd9c8cc467 Increase vtable layout size
This improves LLVM's codegen by allowing vtable loads to be hoisted out
of loops (as just one example).
2024-06-01 07:42:05 -04:00
bors
05965ae238 Auto merge of #124577 - GuillaumeGomez:stabilize-custom_code_classes_in_docs, r=rustdoc
Stabilize `custom_code_classes_in_docs` feature

Fixes #79483.

This feature has been around for quite some time now, I think it's fine to stabilize it now.

## Summary

## What is the feature about?

In short, this PR changes two things, both related to codeblocks in doc comments in Rust documentation:

 * Allow to disable generation of `language-*` CSS classes with the `custom` attribute.
 * Add your own CSS classes to a code block so that you can use other tools to highlight them.

#### The `custom` attribute

Let's start with the new `custom` attribute: it will disable the generation of the `language-*` CSS class on the generated HTML code block. For example:

```rust
/// ```custom,c
/// int main(void) {
///     return 0;
/// }
/// ```
```

The generated HTML code block will not have `class="language-c"` because the `custom` attribute has been set. The `custom` attribute becomes especially useful with the other thing added by this feature: adding your own CSS classes.

#### Adding your own CSS classes

The second part of this feature is to allow users to add CSS classes themselves so that they can then add a JS library which will do it (like `highlight.js` or `prism.js`), allowing to support highlighting for other languages than Rust without increasing burden on rustdoc. To disable the automatic `language-*` CSS class generation, you need to use the `custom` attribute as well.

This allow users to write the following:

```rust
/// Some code block with `{class=language-c}` as the language string.
///
/// ```custom,{class=language-c}
/// int main(void) {
///     return 0;
/// }
/// ```
fn main() {}
```

This will notably produce the following HTML:

```html
<pre class="language-c">
int main(void) {
    return 0;
}</pre>
```

Instead of:

```html
<pre class="rust rust-example-rendered">
<span class="ident">int</span> <span class="ident">main</span>(<span class="ident">void</span>) {
    <span class="kw">return</span> <span class="number">0</span>;
}
</pre>
```

To be noted, we could have written `{.language-c}` to achieve the same result. `.` and `class=` have the same effect.

One last syntax point: content between parens (`(like this)`) is now considered as comment and is not taken into account at all.

In addition to this, I added an `unknown` field into `LangString` (the parsed code block "attribute") because of cases like this:

```rust
/// ```custom,class:language-c
/// main;
/// ```
pub fn foo() {}
```

Without this `unknown` field, it would generate in the DOM: `<pre class="language-class:language-c language-c">`, which is quite bad. So instead, it now stores all unknown tags into the `unknown` field and use the first one as "language". So in this case, since there is no unknown tag, it'll simply generate `<pre class="language-c">`. I added tests to cover this.

EDIT(camelid): This description is out-of-date. Using `custom,class:language-c` will generate the output `<pre class="language-class:language-c">` as would be expected; it treats `class:language-c` as just the name of a language (similar to the langstring `c` or `js` or what have you) since it does not use the designed class syntax.

Finally, I added a parser for the codeblock attributes to make it much easier to maintain. It'll be pretty easy to extend.

As to why this syntax for adding attributes was picked: it's [Pandoc's syntax](https://pandoc.org/MANUAL.html#extension-fenced_code_attributes). Even if it seems clunkier in some cases, it's extensible, and most third-party Markdown renderers are smart enough to ignore Pandoc's brace-delimited attributes (from [this comment](https://github.com/rust-lang/rust/pull/110800#issuecomment-1522044456)).

r? `@notriddle`
2024-06-01 10:18:01 +00:00
Luv-Ray
d3c8e6788c check index value <= 0xFFFF_FF00 2024-06-01 09:40:46 +08:00
Matthias Krüger
619b3e8d4e
Rollup merge of #125807 - oli-obk:resolve_const_types, r=compiler-errors
Also resolve the type of constants, even if we already turned it into an error constant

error constants can still have arbitrary types, and in this case it was turned into an error constant because there was an infer var in the *type* not the *const*.

fixes #125760
2024-05-31 17:05:26 +02:00
Matthias Krüger
234ed6ae5b
Rollup merge of #125796 - scottmcm:more-inst-simplify, r=oli-obk
Also InstSimplify `&raw*`

We do this for `&*` and `&mut*` already; might as well do it for raw pointers too.

r? mir-opt
2024-05-31 17:05:25 +02:00
Matthias Krüger
5109a7668a
Rollup merge of #125776 - compiler-errors:translate-args, r=lcnr
Stop using `translate_args` in the new solver

It was unnecessary and also sketchy, since it was doing an out-of-search-graph fulfillment loop. Added a test for the only really minor subtlety of translating args, though not sure if it was being tested before, though I wouldn't be surprised if it wasn't.

r? lcnr
2024-05-31 17:05:25 +02:00
Matthias Krüger
7667a91778
Rollup merge of #125756 - Zalathar:branch-on-bool, r=oli-obk
coverage: Optionally instrument the RHS of lazy logical operators

(This is an updated version of #124644 and #124402. Fixes #124120.)

When `||` or `&&` is used outside of a branching context (such as the condition of an `if`), the rightmost value does not directly influence any branching decision, so branch coverage instrumentation does not treat it as its own true-or-false branch.

That is a correct and useful interpretation of “branch coverage”, but might be undesirable in some contexts, as described at #124120. This PR therefore adds a new coverage level `-Zcoverage-options=condition` that behaves like branch coverage, but also adds additional branch instrumentation to the right-hand-side of lazy boolean operators.

---

As discussed at https://github.com/rust-lang/rust/issues/124120#issuecomment-2092394586, this is mainly intended as an intermediate step towards fully-featured MC/DC instrumentation. It's likely that we'll eventually want to remove this coverage level (rather than stabilize it), either because it has been incorporated into MC/DC instrumentation, or because it's getting in the way of future MC/DC work. The main appeal of landing it now is so that work on tracking conditions can proceed concurrently with other MC/DC-related work.

````@rustbot```` label +A-code-coverage
2024-05-31 17:05:24 +02:00
Matthias Krüger
e9046602c5
Rollup merge of #125730 - mu001999-contrib:clippy-fix, r=oli-obk
Apply `x clippy --fix` and `x fmt` on Rustc

<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.

This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using

    r​? <reviewer name>
-->

Just run `x clippy --fix` and `x fmt`, and remove some changes like `impl Default`.
2024-05-31 17:05:24 +02:00
Matthias Krüger
4b41136a47
Rollup merge of #125652 - amandasystems:you-dropped-something, r=oli-obk
Revert propagation of drop-live information from Polonius

#64749 introduced a flow of drop-use data from Polonius to `LivenessResults::add_extra_drop_facts()`, which makes `LivenessResults` agree with Polonius on liveness in the presence of free regions that may be dropped. Later changes accidentally removed this flow. This PR restores it.
2024-05-31 17:05:23 +02:00
Michael Goulet
20699fe6b2 Stop using translate_args in the new solver 2024-05-31 09:42:30 -04:00
bors
99cb42c296 Auto merge of #124662 - zetanumbers:needs_async_drop, r=oli-obk
Implement `needs_async_drop` in rustc and optimize async drop glue

This PR expands on #121801 and implements `Ty::needs_async_drop` which works almost exactly the same as `Ty::needs_drop`, which is needed for #123948.

Also made compiler's async drop code to look more like compiler's regular drop code, which enabled me to write an optimization where types which do not use `AsyncDrop` can simply forward async drop glue to `drop_in_place`. This made size of the async block from the [async_drop test](67980dd6fb/tests/ui/async-await/async-drop.rs) to decrease by 12%.
2024-05-31 10:12:24 +00:00
Oli Scherer
06c4cc44b6 Also resolve the type of constants, even if we already turned it into an error constant 2024-05-31 08:56:38 +00:00
Matthias Krüger
c11e057989
Rollup merge of #125790 - WaffleLapkin:no-tail-recomputation-in-lower-stmts, r=lcnr
Don't recompute `tail` in `lower_stmts`

Does not really matter, but this is slightly nicer.

`@bors` rollup
2024-05-31 08:50:24 +02:00
Matthias Krüger
ab55d42b74
Rollup merge of #125786 - compiler-errors:fold-item-bounds, r=lcnr
Fold item bounds before proving them in `check_type_bounds` in new solver

Vaguely confident that this is sufficient to prevent rust-lang/trait-system-refactor-initiative#46 and rust-lang/trait-system-refactor-initiative#62.

This is not the "correct" solution, but will probably suffice until coinduction, at which point we implement the right solution (`check_type_bounds` must prove `Assoc<...> alias-eq ConcreteType`, normalizing requires proving item bounds).

r? lcnr
2024-05-31 08:50:23 +02:00
Matthias Krüger
4aafc1175e
Rollup merge of #125774 - mu001999-contrib:fix/125757, r=compiler-errors
Avoid unwrap diag.code directly in note_and_explain_type_err

<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.

This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using

    r​? <reviewer name>
-->

Fixes #125757
2024-05-31 08:50:23 +02:00
Matthias Krüger
379233242b
Rollup merge of #125635 - fmease:mv-type-binding-assoc-item-constraint, r=compiler-errors
Rename HIR `TypeBinding` to `AssocItemConstraint` and related cleanup

Rename `hir::TypeBinding` and `ast::AssocConstraint` to `AssocItemConstraint` and update all items and locals using the old terminology.

Motivation: The terminology *type binding* is extremely outdated. "Type bindings" not only include constraints on associated *types* but also on associated *constants* (feature `associated_const_equality`) and on RPITITs of associated *functions* (feature `return_type_notation`). Hence the word *item* in the new name. Furthermore, the word *binding* commonly refers to a mapping from a binder/identifier to a "value" for some definition of "value". Its use in "type binding" made sense when equality constraints (e.g., `AssocTy = Ty`) were the only kind of associated item constraint. Nowadays however, we also have *associated type bounds* (e.g., `AssocTy: Bound`) for which the term *binding* doesn't make sense.

---

Old terminology (HIR, rustdoc):

```
`TypeBinding`: (associated) type binding
├── `Constraint`: associated type bound
└── `Equality`: (associated) equality constraint (?)
    ├── `Ty`: (associated) type binding
    └── `Const`: associated const equality (constraint)
```

Old terminology (AST, abbrev.):

```
`AssocConstraint`
├── `Bound`
└── `Equality`
    ├── `Ty`
    └── `Const`
```

New terminology (AST, HIR, rustdoc):

```
`AssocItemConstraint`: associated item constraint
├── `Bound`: associated type bound
└── `Equality`: associated item equality constraint OR associated item binding (for short)
    ├── `Ty`: associated type equality constraint OR associated type binding (for short)
    └── `Const`: associated const equality constraint OR associated const binding (for short)
```

r? compiler-errors
2024-05-31 08:50:22 +02:00
Scott McMurray
4b96e44ebb Also InstSimplify &raw*
We do this for `&*` and `&mut*` already; might as well do it for raw pointers too.
2024-05-30 22:05:30 -07:00
r0cky
ed5205fe66 Avoid unwrap diag.code directly 2024-05-31 08:29:42 +08:00
Camille GILLOT
e110567dcd Revert "Auto merge of #115105 - cjgillot:dest-prop-default, r=oli-obk"
This reverts commit cfb730450f, reversing
changes made to 91c0823ee6.
2024-05-31 00:22:40 +00:00
Waffle Maybe
86afea97fd
Don't recompute tail in lower_stmts 2024-05-31 00:46:07 +02:00
León Orell Valerian Liehr
34c56c45cf
Rename HIR TypeBinding to AssocItemConstraint and related cleanup 2024-05-30 22:52:33 +02:00
Michael Goulet
2f4b7dc047 Fold item bound before checking that they hold 2024-05-30 15:52:29 -04:00
bors
6f3df08aad Auto merge of #125378 - lcnr:tracing-no-lines, r=oli-obk
remove tracing tree indent lines

This allows vscode to collapse nested spans without having to manually remove the indent lines. This is incredibly useful when logging the new solver. I don't mind making them optional depending on some environment flag if you prefer using indent lines

For a gist of the new output, see https://gist.github.com/lcnr/bb4360ddbc5cd4631f2fbc569057e5eb#file-example-output-L181

r? `@oli-obk`
2024-05-30 18:57:48 +00:00
bors
cfb730450f Auto merge of #115105 - cjgillot:dest-prop-default, r=oli-obk
Enable DestinationPropagation by default.

~~Based on https://github.com/rust-lang/rust/pull/115291.~~

This PR proposes to enable the destination propagation pass by default.
This pass is meant to reduce the amount of copies present in MIR.

At the same time, this PR removes the `RenameReturnPlace` pass, as it is currently unsound.
`DestinationPropagation` is not limited to `_0`, but does not handle borrowed locals.
2024-05-30 14:27:46 +00:00
lcnr
86cbabbb9d add logging to search graph 2024-05-30 15:26:48 +02:00
lcnr
97d2c3a6a7 remove tracing tree indent lines 2024-05-30 15:26:48 +02:00
bors
91c0823ee6 Auto merge of #124636 - tbu-:pr_env_unsafe, r=petrochenkov
Make `std::env::{set_var, remove_var}` unsafe in edition 2024

Allow calling these functions without `unsafe` blocks in editions up until 2021, but don't trigger the `unused_unsafe` lint for `unsafe` blocks containing these functions.

Fixes #27970.
Fixes #90308.
CC #124866.
2024-05-30 12:17:06 +00:00
Matthias Krüger
479d6cafb7
Rollup merge of #125754 - Zalathar:conditions-num, r=lqd
coverage: Rename MC/DC `conditions_num` to `num_conditions`

Updated version of #124571, without the other changes that were split out into #125108 and #125700.

This value represents a quantity of conditions, not an ID, so the new spelling is more appropriate.

Some of the code touched by this PR could perhaps use some other changes, but I would prefer to keep this PR as a simple renaming and avoid scope creep.

`@rustbot` label +A-code-coverage
2024-05-30 10:23:09 +02:00
Matthias Krüger
7ed5d469e8
Rollup merge of #125711 - oli-obk:const_block_ice2, r=Nadrieril
Make `body_owned_by` return the `Body` instead of just the `BodyId`

fixes #125677

Almost all `body_owned_by` callers immediately called `body`, too, so just return `Body` directly.

This makes the inline-const query feeding more robust, as all calls to `body_owned_by` will now yield a body for inline consts, too.

I have not yet figured out a good way to make `tcx.hir().body()` return an inline-const body, but that can be done as a follow-up
2024-05-30 10:23:07 +02:00
bors
32a3ed229c Auto merge of #125671 - BoxyUwU:remove_const_ty_eq, r=compiler-errors
Do not equate `Const`'s ty in `super_combine_const`

Fixes #114456

In #125451 we started relating the `Const`'s tys outside of a probe so it was no longer simply an assertion to catch bugs.

This was done so that when we _do_ provide a wrongly typed const argument to an item if we wind up relating it with some other instantiation we'll have a `TypeError` we can bubble up and taint the resulting mir allowing const eval to skip evaluation.

In this PR I instead change `ConstArgHasType` to correctly handle checking the types of const inference variables. Previously if we had something like `impl<const N: u32> Trait for [(); N]`, when using the impl we would instantiate it with infer vars and then check that `?x: u32` is of type `u32` and succeed. Then later we would infer `?x` to some `Const` of type `usize`.

We now stall on `?x` in `ConstArgHasType` until it has a concrete value that we can determine the type of. This allows us to fail using the erroneous implementation of `Trait` which allows us to taint the mir.

Long term we intend to remove the `ty` field on `Const` so we would have no way of accessing the `ty` of a const inference variable anyway and would have to do this. I did not fully update `ConstArgHasType` to avoid using the `ty` field as it's not entirely possible right now- we would need to lookup `ConstArgHasType` candidates in the env.

---

As for _why_ I think we should do this, relating the types of const's is not necessary for soundness of the type system. Originally this check started off as a plain `==` in `super_relate_consts` and gradually has been growing in complexity as we support more complicated types. It was never actually required to ensure that const arguments are correctly typed for their parameters however.

The way we currently check that a const argument has the correct type is a little convoluted and confusing (and will hopefully be less weird as time goes on). Every const argument has an anon const with its return type set to type of the const parameter it is an argument to. When type checking the anon const regular type checking rules require that the expression is the same type as the return type. This effectively ensure that no matter what every const argument _always_ has the correct type.

An extra bit of complexity is that during `hir_ty_lowering` we do not represent everything as a `ConstKind::Unevaluated` corresponding to the anon const. For generic parameters i.e. `[(); N]` we simply represent them as `ConstKind::Param` as we do not want `ConstKind::Unevaluated` with generic substs on stable under min const generics. The anon const still gets type checked resulting in errors about type mismatches.

Eventually we intend to not create anon consts for all const arguments (for example for `ConstKind::Param`) and instead check that the argument type is correct via `ConstArgHasType` obligations (these effectively also act as a check that the anon consts have the correctly set return type).

What this all means is that the the only time we should ever have mismatched types when relating two `Const`s is if we have messed up our logic for ensuring that const arguments are of the correct type. Having this not be an assert is:
- Confusing as it may incorrectly lead people to believe this is an important check that is actually required
- Opens the possibility for bugs or behaviour reliant on this (unnecessary) check existing

---

This PR makes two tests go from pass->ICE (`generic_const_exprs/ice-125520-layout-mismatch-mulwithoverflow.rs` and `tests/crashes/121858.rs`). This is caused by the fact that we evaluate anon consts even if their where clauses do not hold and is a pre-existing issue and only affects `generic_const_exprs`. I am comfortable exposing the brokenness of `generic_const_exprs` more with this PR

This PR makes a test go from ICE->pass (`const-generics/issues/issue-105821.rs`). I have no idea why this PR affects that but I believe that ICE is an unrelated issue to do with the fact that under `generic_const_exprs`/`adt_const_params` we do not handle lifetimes in const parameter types correctly. This PR is likely just masking this bug.

Note: this PR doesn't re-introduce the assertion that the two consts' tys are equal. I'm not really sure how I feel about this but tbh it has caused more ICEs than its found lately so 🤷‍♀️

r? `@oli-obk` `@compiler-errors`
2024-05-30 05:50:44 +00:00
Zalathar
35a8746832 coverage: Instrument the RHS value of lazy logical operators
When a lazy logical operator (`&&` or `||`) occurs outside of an `if`
condition, it normally doesn't have any associated control-flow branch, so we
don't have an existing way to track whether it was true or false.

This patch adds special code to handle this case, by inserting extra MIR blocks
in a diamond shape after evaluating the RHS. This gives us a place to insert
the appropriate marker statements, which can then be given their own counters.
2024-05-30 15:38:46 +10:00
Dorian Péron
fa563c1384 coverage: Add CLI support for -Zcoverage-options=condition 2024-05-30 15:38:46 +10:00
Zalathar
c671eaaaff coverage: Rename MC/DC conditions_num to num_conditions
This value represents a quantity of conditions, not an ID, so the new spelling
is more appropriate.
2024-05-30 13:16:07 +10:00
r0cky
dabd05bbab Apply x clippy --fix and x fmt 2024-05-30 09:51:27 +08:00
Camille GILLOT
5fa0ec6ad1 Enable DestinationPropagation by default. 2024-05-29 23:54:57 +00:00
León Orell Valerian Liehr
fdfffc0048
Rollup merge of #125734 - petrochenkov:macinattr, r=wesleywiser
ast: Revert a breaking attribute visiting order change

Fixes https://github.com/rust-lang/rust/issues/124535
Fixes https://github.com/rust-lang/rust/issues/125201
2024-05-30 01:12:38 +02:00
León Orell Valerian Liehr
1ae1388d2a
Rollup merge of #125733 - compiler-errors:async-fn-assoc-item, r=fmease
Add lang items for `AsyncFn*`, `Future`, `AsyncFnKindHelper`'s associated types

Adds lang items for `AsyncFnOnce::Output`, `AsyncFnOnce::CallOnceFuture`, `AsyncFnMut::CallRefFuture`, and uses them in the new solver. I'm mostly interested in doing this to help accelerate uplifting the new trait solver into a separate crate.

The old solver is kind of spaghetti, so I haven't moved that to use these lang items (i.e. it still uses `item_name`-based comparisons).

update: Also adds lang items for `Future::Output` and `AsyncFnKindHelper::Upvars`.

cc ``@lcnr``
2024-05-30 01:12:37 +02:00
Tobias Bucher
44f9f8bc33 Add deprecated_safe lint
It warns about usages of `std::env::{set_var, remove_var}` with an
automatic fix wrapping the call in an `unsafe` block.
2024-05-30 00:20:48 +02:00
Tobias Bucher
5d8f9b4dc1 Make std::env::{set_var, remove_var} unsafe in edition 2024
Allow calling these functions without `unsafe` blocks in editions up
until 2021, but don't trigger the `unused_unsafe` lint for `unsafe`
blocks containing these functions.

Fixes #27970.
Fixes #90308.
CC #124866.
2024-05-29 23:42:27 +02:00
Vadim Petrochenkov
6e67eaa311 ast: Revert a breaking attribute visiting order change 2024-05-29 21:55:24 +03:00
Michael Goulet
a03ba7fd2d Add lang item for AsyncFnKindHelper::Upvars 2024-05-29 14:28:53 -04:00
Michael Goulet
a9c7e024c0 Add lang item for Future::Output 2024-05-29 14:22:56 -04:00
Matthias Krüger
c09b89ea32
Rollup merge of #125705 - oli-obk:const_block_ice, r=compiler-errors
Reintroduce name resolution check for trying to access locals from an inline const

fixes #125676

I removed this without replacement in https://github.com/rust-lang/rust/pull/124650 without considering the consequences
2024-05-29 20:12:34 +02:00
Matthias Krüger
9a61146765
Rollup merge of #125700 - Zalathar:limit-overflow, r=nnethercote
coverage: Avoid overflow when the MC/DC condition limit is exceeded

Fix for the test failure seen in https://github.com/rust-lang/rust/pull/124571#issuecomment-2099620869.

If we perform this subtraction first, it can sometimes overflow to -1 before the addition can bring its value back to 0.

That behaviour seems to be benign, but it nevertheless causes test failures in compiler configurations that check for overflow.

``@rustbot`` label +A-code-coverage
2024-05-29 20:12:33 +02:00
Matthias Krüger
d0311c1303
Rollup merge of #124655 - Darksonn:fixed-x18, r=lqd,estebank
Add `-Zfixed-x18`

This PR is a follow-up to #124323 that proposes a different implementation. Please read the description of that PR for motivation.

See the equivalent flag in [the clang docs](https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-ffixed-x18).

MCP: https://github.com/rust-lang/compiler-team/issues/748
Fixes https://github.com/rust-lang/rust/issues/121970
r? rust-lang/compiler
2024-05-29 20:12:32 +02:00
Michael Goulet
7f11d6f4bf Add lang items for AsyncFn's associated types 2024-05-29 14:09:19 -04:00
Boxy
d5bd4e233d Partially implement ConstArgHasType 2024-05-29 17:06:54 +01:00