Extend `BYTE_SLICE_IN_PACKED_STRUCT_WITH_DERIVE`.
To temporarily allow a `str` field in a packed struct using `derive`, along with `[u8]`.
r? ``@RalfJung``
This is somewhat important because LLVM enables the pass based on
target architecture, but support by the target OS also matters.
For example, XRay attributes are processed by codegen for macOS
targets, but Apple linker fails to process relocations in XRay
data sections, so the feature as a whole is not supported there
for the time being.
Specify where XRay is supported. I only test ARM64 and x86_64, but hey
those others should work too, right? LLVM documentation says that MIPS
and PPC are also supported, but I don't have the hardware, so I won't
pretend. Naturally, more targets can be added later with more testing.
Add the attributes to functions according to the settings.
"xray-always" overrides "xray-never", and they both override
"xray-ignore-loops" and "xray-instruction-threshold", but we'll
let lints deal with warnings about silly attribute combinations.
Recognize all bells and whistles that LLVM's XRay pass is capable of.
The always/never settings are a bit dumb without attributes but they're
still there. The default instruction count is chosen by the compiler,
not LLVM pass. We'll do it later.
Rename `replace_bound_vars_with_*` to `instantiate_binder_with_*`
Mentioning "binder" rather than "bound vars", imo, makes it clearer that we're doing something to the binder as a whole.
Also, "instantiate" is the verb that I'm always reaching for when I'm looking for these functions, and the name that we use in the new solver anyways.
r? types
Make `derive_const` derive properly const-if-const impls
Fixes#107774Fixes#107666
Also fixes rendering of const-if-const bounds in pretty printing.
r? ```@oli-obk``` or ```@fee1-dead```
Change `arena_cache` to not alter the declared query result
This makes the return types a bit clearer, limiting `arena_cache`'s effect to just the computation side. It also makes it easier to potentially remove `arena_cache`.
r? ```@cjgillot```
Treat Drop as a rmw operation
Previously, a Drop terminator was considered a move in MIR. This commit changes the behavior to only treat Drop as a mutable access to the dropped place.
In order for this change to be correct, we need to guarantee that
1. A dropped value won't be used again
2. Places that appear in a drop won't be used again before a
subsequent initialization.
We can ensure this to be correct at MIR construction because Drop will only be emitted when a variable goes out of scope, thus having:
* (1) as there is no way of reaching the old value. drop-elaboration
will also remove any uninitialized drop.
* (2) as the place can't be named following the end of the scope.
However, the initialization status, previously tracked by moves, should also be tied to the execution of a Drop, hence the additional logic in the dataflow analyses.
From discussion in [this thread](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/.60DROP.60.20to.20.60DROP_IF.60.20compiler-team.23558), originating from https://github.com/rust-lang/compiler-team/issues/558.
See also https://github.com/rust-lang/rust/pull/104488#discussion_r1085556010
Remove astconv usage in diagnostic
Fixes#107775
Location of the test sucks, I know, but I needed to put it somewhere 😓
The issue here is that the root cause of the issue has nothing to do with what's being tested, so I couldn't really give it a better name. Oh well.
Rename `PointerSized` to `PointerLike`
The old name was unnecessarily vague. This PR renames a nightly language feature that I added, so I don't think it needs any additional approval, though anyone can feel free to speak up if you dislike the rename.
It's still unsatisfying that we don't the user which of {size, alignment} is wrong, but this trait really is just a stepping stone for a more generalized mechanism to create `dyn*`, just meant for nightly testing, so I don't think it really deserves additional diagnostic machinery for now.
Fixes#107696, cc ``@RalfJung``
r? ``@eholk``
Rollup of 8 pull requests
Successful merges:
- #100599 (Add compiler error E0523 long description and test)
- #107471 (rustdoc: do not include empty default-settings tag in HTML)
- #107555 (Modify existing bounds if they exist)
- #107662 (Turn projections into copies in CopyProp.)
- #107695 (Add test for Future inflating arg size to 3x )
- #107700 (Run the tools builder on all PRs)
- #107706 (Mark 'atomic_mut_ptr' methods const)
- #107709 (Fix problem noticed in PR106859 with char -> u8 suggestion)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
llvm-16: Use Triple.h from new header location.
LLVM 16 has moved Triple.h from ADT and into TargetParser.
LLVM [landed a commit](62c7f035b4) this morning moving the header. This change should make rustc continue to build against LLVM main.
Fix problem noticed in PR106859 with char -> u8 suggestion
HN reader `@ayosec` noticed that my #106859 a few weeks back, malfunctions if you have a Unicode escape, the code suggested b'\u{0}' if you tried to use '\u{0}' where a byte should be, when of course b'\u{0}' is not a byte literal, regardless of the codepoint you can't write Unicode escapes in a byte literal at all.
My proposed fix here just checks that the "character" you wrote is fewer than 5 bytes, thus allowing \x7F and similar escapes but conveniently forbidding even the smallest Unicode escape \u{0} before offering the suggestion as before.
I have provided an updated test which includes examples which do and don't work because of this additional rule.
Split fn_ctxt/adjust_fulfillment_errors from fn_ctxt/checks
This is a follow-up from #106477, addressing a small number of the `FIXME`s that were added, by moving some functions into the new(er) `adjust_fulfillment_errors` module.
More cleanup is possible for this file (and I'll hopefully get around to doing some of that soon) but the very first thing is to just move these functions out.
There should be no "real" changes in this PR, besides minor adjustments to imports and the functions being transferred.
Turn projections into copies in CopyProp.
The current implementation can leave behind projections that are moved out several times.
This PR widens the check to turn such moves into copies: a move out of a projection of a copy is equivalent to a copy of the original projection.
Modify existing bounds if they exist
Fixes#107335.
This implementation is kinda gross but I don't really see a better way to do it.
This primarily does two things: Modifies `suggest_constraining_type_param` to accept a new parameter that indicates a span to be replaced instead of added, if presented, and limit the additive suggestions to either suggest a new bound on an existing bound (see newly added unit test) or add the generics argument if a generics argument wasn't found.
The former change is required to retain the capability to add an entirely new bounds if it was entirely omitted.
r? ``@compiler-errors``
Fix suggestions rendering when the diff span is multiline
Fixes#92741
cc `@estebank`
I think, I finally fixed. I still want to go back and try to clean up the code a bit. I'm open to suggestions.
Some examples of the new suggestions:
```
help: consider removing the borrow
|
2 - &
|
```
```
help: consider removing the borrow
|
2 - &
3 - mut
|
```
```
help: consider removing the borrow
|
2 - &
3 - mut if true { true } else { false }
2 + if true { true } else { false }
|
```
Should we add a test to ensure this behavior doesn't disappear in the future?
There is a distinction between running this on wasm and i686, even though they should be
identical. This technically is not _incorrect_, it's just an unexpected difference, which is
worth investigating, but not for correctness.
Since we're changing a bunch of stuff, necessary to remove some codegen tests
which look for specific things. Also attempting to restart a test which timed out, maybe due to
fastly failing?
make &mut !Unpin not dereferenceable, and Box<!Unpin> not noalias
See https://github.com/rust-lang/unsafe-code-guidelines/issues/381 and [this LLVM discussion](https://discourse.llvm.org/t/interaction-of-noalias-and-dereferenceable/66979). The exact semantics of how `noalias` and `dereferenceable` interact are unclear, and `@comex` found a case of LLVM actually exploiting that ambiguity for optimizations. I think for now we should treat LLVM `dereferenceable` as implying a "fake read" to happen immediately at the top of the function (standing in for the spurious reads that LLVM might introduce), and that fake read is subject to all the usual `noalias` restrictions. This means we cannot put `dereferenceable` on `&mut !Unpin` references as those references can alias with other references that are being read and written inside the function (e.g. for self-referential generators), meaning the fake read introduces aliasing conflicts with those other accesses.
For `&` this is already not a problem due to https://github.com/rust-lang/rust/pull/98017 which removed the `dereferenceable` attribute for other reasons.
Regular `&mut Unpin` references are unaffected, so I hope the impact of this is going to be tiny.
The first commit does some refactoring of the `PointerKind` enum since I found the old code very confusing each time I had to touch it. It doesn't change behavior.
Fixes https://github.com/rust-lang/miri/issues/2714
EDIT: Turns out our `Box<!Unpin>` treatment was incorrect, too, so the PR also fixes that now (in codegen and Miri): we do not put `noalias` on these boxes any more.
interpret: move discriminant reading and writing to separate file
This is quite different from the otherwise fairly general read and write functions in place.rs and operand.rs, and also it's nice to have these two functions close together as they are basically inverses of each other.
Sort Generator `print-type-sizes` according to their yield points
Especially when trying to diagnose runaway future sizes, it might be more intuitive to sort the variants according to the control flow (aka their yield points) rather than the size of the variants.
Refine error spans for "The trait bound `T: Trait` is not satisfied" when passing literal structs/tuples
This PR adds a new heuristic which refines the error span reported for "`T: Trait` is not satisfied" errors, by "drilling down" into individual fields of structs/enums/tuples to point to the "problematic" value.
Here's a self-contained example of the difference in error span:
```rs
struct Burrito<Filling> {
filling: Filling,
}
impl <Filling: Delicious> Delicious for Burrito<Filling> {}
fn eat_delicious_food<Food: Delicious>(food: Food) {}
fn will_type_error() {
eat_delicious_food(Burrito { filling: Kale });
// ^~~~~~~~~~~~~~~~~~~~~~~~~ (before) The trait bound `Kale: Delicious` is not satisfied
// ^~~~ (after) The trait bound `Kale: Delicious` is not satisfied
}
```
(kale is fine, this is just a silly food-based example)
Before this PR, the error span is identified as the entire argument to the generic function `eat_delicious_food`. However, since only `Kale` is the "problematic" part, we can point at it specifically. In particular, the primary error message itself mentions the missing `Kale: Delicious` trait bound, so it's much clearer if this part is called out explicitly.
---
The _existing_ heuristic tries to label the right function argument in `point_at_arg_if_possible`. It goes something like this:
- Look at the broken base trait `Food: Delicious` and find which generics it mentions (in this case, only `Food`)
- Look at the parameter type definitions and find which of them mention `Filling` (in this case, only `food`)
- If there is exactly one relevant parameter, label the corresponding argument with the error span, instead of the entire call
This PR extends this heuristic by further refining the resulting expression span in the new `point_at_specific_expr_if_possible` function. For each `impl` in the (broken) chain, we apply the following strategy:
The strategy to determine this span involves connecting information about our generic `impl`
with information about our (struct) type and the (struct) literal expression:
- Find the `impl` (`impl <Filling: Delicious> Delicious for Burrito<Filling>`)
that links our obligation (`Kale: Delicious`) with the parent obligation (`Burrito<Kale>: Delicious`)
- Find the "original" predicate constraint in the impl (`Filling: Delicious`) which produced our obligation.
- Find all of the generics that are mentioned in the predicate (`Filling`).
- Examine the `Self` type in the `impl`, and see which of its type argument(s) mention any of those generics.
- Examing the definition for the `Self` type, and identify (for each of its variants) if there's a unique field
which uses those generic arguments.
- If there is a unique field mentioning the "blameable" arguments, use that field for the error span.
Before we do any of this logic, we recursively call `point_at_specific_expr_if_possible` on the parent
obligation. Hence we refine the `expr` "outwards-in" and bail at the first kind of expression/impl we don't recognize.
This function returns a `Result<&Expr, &Expr>` - either way, it returns the `Expr` whose span should be
reported as an error. If it is `Ok`, then it means it refined successfull. If it is `Err`, then it may be
only a partial success - but it cannot be refined even further.
---
I added a new test file which exercises this new behavior. A few existing tests were affected, since their error spans are now different. In one case, this leads to a different code suggestion for the autofix - although the new suggestion isn't _wrong_, it is different from what used to be.
This change doesn't create any new errors or remove any existing ones, it just adjusts the spans where they're presented.
---
Some considerations: right now, this check occurs in addition to some similar logic in `adjust_fulfillment_error_for_expr_obligation` function, which tidies up various kinds of error spans (not just trait-fulfillment error). It's possible that this new code would be better integrated into that function (or another one) - but I haven't looked into this yet.
Although this code only occurs when there's a type error, it's definitely not as efficient as possible. In particular, there are definitely some cases where it degrades to quadratic performance (e.g. for a trait `impl` with 100+ generic parameters or 100 levels deep nesting of generic types). I'm not sure if these are realistic enough to worry about optimizing yet.
There's also still a lot of repetition in some of the logic, where the behavior for different types (namely, `struct` vs `enum` variant) is _similar_ but not the same.
---
I think the biggest win here is better targeting for tuples; in particular, if you're using tuples + traits to express variadic-like functions, the compiler can't tell you which part of a tuple has the wrong type, since the span will cover the entire argument. This change allows the individual field in the tuple to be highlighted, as in this example:
```
// NEW
LL | want(Wrapper { value: (3, q) });
| ---- ^ the trait `T3` is not implemented for `Q`
// OLD
LL | want(Wrapper { value: (3, q) });
| ---- ^~~~~~~~~~~~~~~~~~~~~~~~~ the trait `T3` is not implemented for `Q`
```
Especially with large tuples, the existing error spans are not very effective at quickly narrowing down the source of the problem.
Rollup of 5 pull requests
Successful merges:
- #107553 (Suggest std::ptr::null if literal 0 is given to a raw pointer function argument)
- #107580 (Recover from lifetimes with default lifetimes in generic args)
- #107669 (rustdoc: combine duplicate rules in ayu CSS)
- #107685 (Suggest adding a return type for async functions)
- #107687 (Adapt SROA MIR opt for aggregated MIR)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Adapt SROA MIR opt for aggregated MIR
The pass was broken by https://github.com/rust-lang/rust/pull/107267.
This PR extends it to replace:
```
x = Struct { 0: a, 1: b }
y = move? x
```
by assignment between locals
```
x_0 = a
x_1 = b
y_0 = move? x_0
y_1 = move? x_1
```
The improved pass runs to fixpoint, so we can flatten nested field accesses.
Suggest std::ptr::null if literal 0 is given to a raw pointer function argument
Implementation feels a little sus (we're parsing the span for a `0`) but it seems to fall in line the string-expected-found-char condition right above this check, so I think it's fine.
Feedback appreciated on help text? I think it's consistent but it does sound a little awkward maybe?
Fixes#107517
Adds the extended error documentation for E0523 to indicate that the
error is no longer produced by the compiler.
Update the E0464 documentation to include example code that produces the
error.
Remove the error message E0523 from the compiler and replace it with an
internal compiler error.
The code that consumes PointerKind (`adjust_for_rust_scalar` in rustc_ty_utils)
ended up using PointerKind variants to talk about Rust reference types (& and
&mut) anyway, making the old code structure quite confusing: one always had to
keep in mind which PointerKind corresponds to which type. So this changes
PointerKind to directly reflect the type.
This does not change behavior.
don't point at nonexisting code beyond EOF when warning about delims
Previously we would show this:
```
warning: unnecessary braces around block return value
--> /tmp/bad.rs:1:8
|
1 | fn a(){{{
| ^ ^
|
= note: `#[warn(unused_braces)]` on by default
help: remove these braces
|
1 - fn a(){{{
1 + fn a(){{
|
```
which is now hidden in this case.
We would create a span spanning between the pair of redundant {}s but there is only EOF instead of the `}` so we would previously point at nothing. This would cause the debug assertion ice to trigger. I would have loved to just only point at the second delim and say "you can remove that" but I'm not sure how to do that without refactoring the entire diagnostic which seems tricky. :( But given that this does not seem to regress any other tests we have, I think this edge-casey enough be acceptable.
Fixes https://github.com/rust-lang/rust/issues/107423
r? `@compiler-errors`
Especially when trying to diagnose runaway future sizes, it might be
more intuitive to sort the variants according to the control flow
(aka their yield points) rather than the size of the variants.
Change wording from "nullable" to "default".
Introduce a trait `IsDefault` for detecting values that are encoded as zeros or not encoded at all.
Add panics to impossible cases.
Some other minor cleanups.
Less import overhead for errors
This removes huge (3+ lines) import lists found in files that had their error reporting migrated. These lists are bad for developer workflows as adding, removing, or editing a single error's name might cause a chain reaction that bloats the git diff. As the error struct names are long, the likelihood of such chain reactions is high.
Follows the suggestion by `@Nilstrieb` in the [zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics/topic/massive.20use.20statements) to replace the `use errors::{FooErr, BarErr};` with `use errors;` and then changing to `errors::FooErr` on the usage sites.
I have used sed to do most of the changes, i.e. something like:
```
sed -i -E 's/(create_err|create_feature_err|emit_err|create_note|emit_fatal|emit_warning)\(([[:alnum:]]+|[A-Z][[:alnum:]:]*)( \{|\))/\1(errors::\2\3/' path/to/file.rs
```
& then I manually fixed the errors that occured. Most manual changes were required in `compiler/rustc_parse/src/parser/expr.rs`.
r? `@compiler-errors`
Move code in `rustc_driver` out to a new `rustc_driver_impl` crate to allow pipelining
That adds a `rustc_shared` library which contains all the rustc library crates in a single dylib. It takes over this role from `rustc_driver`. This is done so that `rustc_driver` can be compiled in parallel with other crates. `rustc_shared` is intentionally left empty so it only does linking.
An alternative could be to move the code currently in `rustc_driver` into a new crate to avoid changing the name of the distributed library.
Previously we would show this:
```
warning: unnecessary braces around block return value
--> /tmp/bad.rs:1:8
|
1 | fn a(){{{
| ^ ^
|
= note: `#[warn(unused_braces)]` on by default
help: remove these braces
|
1 - fn a(){{{
1 + fn a(){{
|
```
which is now hidden in this case.
We would create a span spanning between the pair of redundant {}s but there is only EOF instead of the `}` so we would previously point at nothing.
This would cause the debug assertion ice to trigger.
I would have loved to just only point at the second delim and say "you can remove that" but I'm not sure how to do that without refactoring the entire diagnostic which seems tricky. :(
But given that this does not seem to regress any other tests we have, I think this edge-casey enough be acceptable.
Fixes https://github.com/rust-lang/rust/issues/107423
r? @compiler-errors
Retry opening proc-macro DLLs a few times on Windows.
On Windows, the compiler [sometimes](https://users.rust-lang.org/t/error-loadlibraryexw-failed/77603) fails with the message `error: LoadLibraryExW failed` when trying to load a proc-macro crate. The error seems to occur intermittently, similar to https://github.com/rust-lang/rust/issues/86929, however, it seems to be almost impossible to reproduce outside of CI environments and thus very hard to debug. The fact that the error only occurs intermittently makes me think that this is a timing related issue.
This PR is an attempt to mitigate the issue by letting the compiler retry a few times when encountering this specific error (which resolved the issue described in https://github.com/rust-lang/rust/issues/86929).
Fix suggestion for coercing Option<&String> to Option<&str>
Fixes#107604
This also makes the diagnostic `MachineApplicable`, and runs `rustfix` to check we're not producing incorrect code.
``@rustbot`` label +A-diagnostics
Don't cause a cycle when formatting query description that references a FnDef
When a function returns `-> _`, we use typeck to compute what the resulting type of the body _should_ be. If we call another query inside of typeck and hit a cycle error, we attempt to report the cycle error which requires us to compute all of the query descriptions for the stack.
However, if one of the queries in that cycle has a query description that references this function as a FnDef type, we'll cause a *second* cycle error from within the cycle error reporting code, since rendering a FnDef requires us to compute its signature. This causes an unwrap to ICE, since during the *second* cycle reporting code, we try to look for a job that isn't in the active jobs list.
We can avoid this by using `with_no_queries!` when computing these query descriptions.
Fixes#107089
The only drawback is that the rendering of opaque types in cycles regresses a bit :| I'm open to alternate suggestions about how we may handle this...
Emit warnings on unused parens in index expressions
Fixes: #96606.
I am not sure what the best term for "index expression" is. Is there a better term we could use?
Don't generate unecessary `&&self.field` in deriving Debug
Since unsized fields may only be the last one in a struct, we only need to generate a double reference (`&&self.field`) for the final one.
cc `@nnethercote`
ast: Optimize list and value extraction primitives for attributes
It's not necessary to convert the whole attribute into a meta item to extract something specific.
Suggest `{var:?}` when finding `{?:var}` in inline format strings
Link to issue: https://github.com/rust-lang/rust/issues/106572
This is my first PR to this project, so hopefully I can get some good pointers with me from the first PR.
Currently my idea was to test out whether or not this is the correct solution to this issue and then hopefully expand upon the idea to not only work for Debug formatting but for all of them. If this is a valid solution, I will create a new issue to give a better error message to a broader range of wrong-order formatting.
The motivation here is to eliminate the `Option<(Delimiter,
DelimSpan)>`, which is `None` for the outermost token stream and `Some`
for all other token streams.
We are already treating the innermost frame specially -- this is the
`frame` vs `stack` distinction in `TokenCursor`. We can push that
further so that `frame` only contains the cursor, and `stack` elements
contain the delimiters for their children. When we are in the outermost
token stream `stack` is empty, so there are no stored delimiters, which
is what we want because the outermost token stream *has* no delimiters.
This change also shrinks `TokenCursor`, which shrinks `Parser` and
`LazyAttrTokenStreamImpl`, which is nice.
Sometimes the parser needs to desugar a doc comment into `#[doc =
r"foo"]`. Currently it does this in a hacky way: by pushing a "fake" new
frame (one without a delimiter) onto the `TokenCursor` stack.
This commit changes things so that the token stream itself is modified
in place. The nice thing about this is that it means
`TokenCursorFrame::delim_sp` is now only `None` for the outermost frame.
Erase regions before doing uninhabited check in borrowck
~Also, fingerprint query keys/values when debug assertions are enabled. This should make it easier to check for issues like this without `-Cincremental`, and make UI tests a bit cleaner.~ edit: moving that to a separate PR
Fixes#107505
Remove both StorageLive and StorageDead in CopyProp.
Fixes https://github.com/rust-lang/rust/issues/107511https://github.com/rust-lang/rust/pull/106908 removed StorageDead without the accompanying StorageLive. In loops, execution would see repeated StorageLive, without any StorageDead, which is UB.
So when removing storage statements, we have to remove both StorageLive and StorageDead.
~I also added a MIR validation pass for StorageLive. It may be a bit overzealous.~
Improve pretty-printing of `HirIdValidator` errors
This now uses `node_to_string` for both missing and seen Ids, which includes the snippet of code for which the Id was allocated. Also removes the duplicated printing of `HirId`, as `node_to_string` also includes that.
Improve diagnostic for missing space in range pattern
Improves the diagnostic in #107425 by turning it into a note explaining the parsing issue.
r? `@compiler-errors`
Revert "Teach parser to understand fake anonymous enum syntax" and related commits
anonymous enum types are currently ambiguous in positions like:
* `|` operator: `a as fn() -> B | C`
* closure args: `|_: as fn() -> A | B`
I first tried to thread around `RecoverAnonEnum` into all these positions, but the resulting complexity in the compiler is IMO not worth it, or at least worth a bit more thinking time. In the mean time, let's revert this syntax for now, so we can go back to the drawing board.
Fixes#107461
cc: `@estebank` `@cjgillot` #106960
---
### Squashed revert commits:
Revert "review comment: Remove AST AnonTy"
This reverts commit 020cca8d36.
Revert "Ensure macros are not affected"
This reverts commit 12d18e4031.
Revert "Emit fewer errors on patterns with possible type ascription"
This reverts commit c847a01a3b.
Revert "Teach parser to understand fake anonymous enum syntax"
This reverts commit 2d82420665.
Revert "review comment: Remove AST AnonTy"
This reverts commit 020cca8d36.
Revert "Ensure macros are not affected"
This reverts commit 12d18e4031.
Revert "Emit fewer errors on patterns with possible type ascription"
This reverts commit c847a01a3b.
Revert "Teach parser to understand fake anonymous enum syntax"
This reverts commit 2d82420665.
Fix syntax in `-Zunpretty-expanded` output for derived `PartialEq`.
If you do `derive(PartialEq)` on a packed struct, the output shown by `-Zunpretty=expanded` includes expressions like this:
```
{ self.x } == { other.x }
```
This is invalid syntax. This doesn't break compilation, because the AST nodes are constructed within the compiler. But it does mean anyone using `-Zunpretty=expanded` output as a guide for hand-written impls could get a nasty surprise.
This commit fixes things by instead using this form:
```
({ self.x }) == ({ other.x })
```
r? ``@RalfJung``
Remove confusing 'while checking' note from opaque future type mismatches
Maybe I'm just misinterpreting the wording of the note. The only value I can see in this note is that it points out where the async's opaque future is coming from, but the way it's doing it is misleading IMO.
For example:
```rust
note: while checking the return type of the `async fn`
--> $DIR/dont-suggest-missing-await.rs:7:24
|
LL | async fn make_u32() -> u32 {
| ^^^ checked the `Output` of this `async fn`, found opaque type
```
We point at the type `u32` in the HIR, but then say "found opaque type". We also say "while checking"... but we're typechecking a totally different function when we get this type mismatch!
r? ``@estebank`` but feel free to reassign and/or take your time reviewing this. I'd be inclined to also discuss reworking the presentation of this type mismatch to restore some of these labels in a way that makes it more clear what it's trying to point out.
Remove hardcoded iOS version of clang target for Mac Catalyst
## Background
From `clang` 13.x, `-target x86_64-apple-ios13.0-macabi` fails while linking:
```
= note: clang: error: invalid version number in '-target x86_64-apple-ios13.0-macabi'
```
<details>
<summary>Verbose output</summary>
```
error: linking with `cc` failed: exit status: 1
|
= note: LC_ALL="C" PATH="[removed]" VSLANG="1033" ZERO_AR_DATE="1" "cc" "-Wl,-exported_symbols_list,/var/folders/p8/qpmzbsdn07g5gxykwfxxw7y40000gn/T/rustci8tkvp/list" "-target" "x86_64-apple-ios13.0-macabi" "/var/folders/p8/qpmzbsdn07g5gxykwfxxw7y40000gn/T/rustci8tkvp/symbols.o" "/path/to/my/[project]/[user]/target/x86_64-apple-ios-macabi/release/deps/[user].[user].a2ccc648-cgu.0.rcgu.o" "-L" "/path/to/my/[project]/[user]/target/x86_64-apple-ios-macabi/release/deps" "-L" "/path/to/my/[project]/[user]/target/release/deps" "-L" "/path/to/my/[project]/[user]/target/x86_64-apple-ios-macabi/release/build/blake3-74e6ba91506ce712/out" "-L" "/path/to/my/[project]/[user]/target/x86_64-apple-ios-macabi/release/build/blake3-74e6ba91506ce712/out" "-L" "/Users/[user]/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/x86_64-apple-ios-macabi/lib" "/var/folders/p8/qpmzbsdn07g5gxykwfxxw7y40000gn/T/rustci8tkvp/libblake3-343c1616c8f62c66.rlib" "/path/to/my/[project]/[user]/target/x86_64-apple-ios-macabi/release/deps/libcompiler_builtins-15d4f20b641cf9ef.rlib" "-framework" "Security" "-framework" "CoreFoundation" "-framework" "Security" "-liconv" "-lSystem" "-lobjc" "-framework" "Security" "-framework" "Foundation" "-lc" "-lm" "-isysroot" "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk" "-Wl,-syslibroot" "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk" "-L" "/Users/[user]/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/x86_64-apple-ios-macabi/lib" "-o" "/path/to/my/[project]/[user]/target/x86_64-apple-ios-macabi/release/deps/lib[user].dylib" "-Wl,-dead_strip" "-dynamiclib" "-Wl,-dylib" "-nodefaultlibs"
= note: clang: error: invalid version number in '-target x86_64-apple-ios13.0-macabi'
warning: `[user]` (lib) generated 6 warnings
error: could not compile `[user]` due to previous error; 6 warnings emitted
```
</details>
### Minimal example
C code:
```c
#include <stdio.h>
void main() {
int a = 1;
int b = 2;
int c = a + b;
printf("%d", c);
}
```
`clang` command sample:
```
➜ 202301 clang -target x86_64-apple-ios13.0-macabi main.c
clang: error: invalid version number in '-target x86_64-apple-ios13.0-macabi'
➜ 202301 clang -target x86_64-apple-ios14.0-macabi main.c
main.c:2:1: warning: return type of 'main' is not 'int' [-Wmain-return-type]
void main() {
^
main.c:2:1: note: change return type to 'int'
void main() {
^~~~
int
1 warning generated.
➜ 202301 clang -target x86_64-apple-ios15.0-macabi main.c
main.c:2:1: warning: return type of 'main' is not 'int' [-Wmain-return-type]
void main() {
^
main.c:2:1: note: change return type to 'int'
void main() {
^~~~
int
1 warning generated.
➜ 202301 clang -target x86_64-apple-ios-macabi main.c
main.c:2:1: warning: return type of 'main' is not 'int' [-Wmain-return-type]
void main() {
^
main.c:2:1: note: change return type to 'int'
void main() {
^~~~
int
1 warning generated.
➜ 202301 clang --version
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: arm64-apple-darwin22.2.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
```
This PR is a simplified version of #96392, inspired by https://github.com/rust-lang/cc-rs/pull/727
The check previously matched this, and suggested adding a missing
`struct`:
pub Foo(...):
It was probably intended to match this instead (semicolon instead of
colon):
pub Foo(...);
This now uses `node_to_string` for both missing and seen Ids, which includes
the snippet of code for which the Id was allocated.
Also removes the duplicated printing of `HirId`, as `node_to_string` includes that already.
Similarly, changes all other users of `node_to_string` that do so, and changes the output of `node_to_string`, which is now "$hirid ($what `$span` in $path)".
Strengthen validation of FFI attributes
Previously, `codegen_attrs` validated the attributes `#[ffi_pure]`, `#[ffi_const]`, and `#[ffi_returns_twice]` to make sure that they were only used on foreign functions. However, this validation was insufficient in two ways:
1. `codegen_attrs` only sees items for which code must be generated, so it was unable to raise errors when the attribute was incorrectly applied to macros and the like.
2. the validation code only checked that the item with the attr was foreign, but not that it was a foreign function, allowing these attributes to be applied to foreign statics as well.
This PR moves the validation to `check_attr`, which sees all items. It additionally changes the validation to ensure that the attribute's target is `Target::ForeignFunction`, only allowing the attributes on foreign functions and not foreign statics. Because these attributes are unstable, there is no risk for backwards compatibility. The changes also ending up making the code much easier to read.
This PR is best reviewed commit by commit. Additionally, I was considering moving the tests to the `attribute` subdirectory, to get them out of the general UI directory. I could do that as part of this PR or a follow-up, as the reviewer prefers.
CC: #58328, #58329
Do not depend on Generator trait when deducing closure signature
1. Do not depend on `Generator` trait when deducing closure signature.
2. Compare the name of the `Generator::Return` associated item, rather than its order in the trait. Seems more stable this way.
Fixing confusion between mod and remainder
Like many programming languages, rust too confuses remainder and modulus. The `%` operator and the associated `Rem` trait is (as the trait name suggests) the remainder, but since most people are linguistically more familiar with the modulus the documentation sometimes claims otherwise. This PR tries to fix this problem in rustc.
If you do `derive(PartialEq)` on a packed struct, the output shown by
`-Zunpretty=expanded` includes expressions like this:
```
{ self.x } == { other.x }
```
This is invalid syntax. This doesn't break compilation, because the AST
nodes are constructed within the compiler. But it does mean anyone using
`-Zunpretty=expanded` output as a guide for hand-written impls could get
a nasty surprise.
This commit fixes things by instead using this form:
```
({ self.x }) == ({ other.x })
```
PointeeInfo is advisory only
https://github.com/rust-lang/rust/pull/107248 fixed PointeeInfo being used in ways that don't actually work. Hopefully this comments helps avoid such issues in the future.
Cc ``@eddyb``
Track bound types like bound regions
When we instantiate bound types into placeholder types, we throw away the names for some reason. These names are particularly useful for error reporting once we have `for<T>` binders.
r? types
small refactor to new projection code
extract `eq_term_and_make_canonical_response` into a helper function which also is another guarantee that the expected term does not influence candidate selection for projections.
also change `evaluate_all(vec![single_goal])` to use `evaluate_goal`.
the second commit now also adds a `debug_assert!` to `evaluate_goal`.
make unaligned_reference a hard error
The `unaligned_references` lint has been warn-by-default since Rust 1.53 (https://github.com/rust-lang/rust/pull/82525) and deny-by-default with mention in cargo future-incompat reports since Rust 1.62 (https://github.com/rust-lang/rust/pull/95372). Current nightly will become Rust 1.66, so (unless major surprises show up with crater) I think it is time we make this a hard error, and close this old soundness gap in the language.
EDIT: Turns out this will only land for Rust 1.67, so there is another 6 weeks of time here for crates to adjust.
Fixes https://github.com/rust-lang/rust/issues/82523.
Bump bootstrap compiler to 1.68
This also changes our stage0.json to include the rustc component for the rustfmt pinned nightly toolchain, which is currently necessary due to rustfmt dynamically linking to that toolchain's librustc_driver and libstd.
r? `@pietroalbini`
Modify primary span label for E0308
Looking at the reactions to https://hachyderm.io/`@ekuber/109622160673605438,` a lot of people seem to have trouble understanding the current output, where the primary span label on type errors talks about the specific types that diverged, but these can be deeply nested type parameters. Because of that we could see "expected i32, found u32" in the label while the note said "expected Vec<i32>, found Vec<u32>". This understandably confuses people. I believe that once people learn to read these errors it starts to make more sense, but this PR changes the output to be more in line with what people might expect, without sacrificing terseness.
Fix#68220.
incremental: migrate diagnostics
- Apply the diagnostic migration lints to more functions on `Session`, namely: `span_warn`, `span_warn_with_code`, `warn` `note_without_error`, `span_note_without_error`, `struct_note_without_error`.
- Add impls of `IntoDiagnosticArg` for `std::io::Error`, `std::path::Path` and `std::path::PathBuf`.
- Migrate the `rustc_incremental` crate's diagnostics to translatable diagnostic structs.
r? `@compiler-errors`
cc #100717
Rollup of 8 pull requests
Successful merges:
- #107245 (Implement unsizing in the new trait solver)
- #107445 (Remove `GenFuture` from core)
- #107473 (Update books)
- #107476 (rustdoc: remove unnecessary wrapper `div.item-decl` from HTML)
- #107477 (Migrate last part of CSS themes to CSS variables)
- #107479 (Use `ObligationCtxt::new_in_snapshot` in `satisfied_from_param_env`)
- #107482 (rustdoc: remove meta keywords from HTML)
- #107494 (fix link in std::path::Path::display())
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Use `ObligationCtxt::new_in_snapshot` in `satisfied_from_param_env`
We can evaluate nested `ConstEvaluatable` obligations in an evaluation probe, which will ICE if we use `ObligationCtxt::new`.
Fixes#107474Fixes#106666
r? `@BoxyUwU` but feel free to reassign
cc `@JulianKnodt` who i think added this assertion code
Not sure if the rustdoc test is needed, but can't hurt. They're the same root cause, though.
Implement unsizing in the new trait solver
This makes hello world compile! Ignore the first commit, that's just #107146 which is waiting on merge.
I'll leave some comments inline about design choices that might be debatable.
r? `@lcnr` (until we have a new trait solver reviewer group...)
Fix invalid float literal suggestions when recovering an integer
Only suggest adding a zero to integers with a preceding dot when the change will result in a valid floating point literal.
For example, `.0x0` should not be turned into `0.0x0`.
r? nnethercote
Only suggest adding a zero to integers with a preceding dot when the change will
result in a valid floating point literal.
For example, `.0x0` should not be turned into `0.0x0`.
assume MIR types are fully normalized in ascribe_user_type
This FIXME was introduced in c6a17bf8bc but it should've been restricted to `ascribe_user_type_skip_wf`.
Forward the `Display` implementation for `CrateType` to
`IntoDiagnosticArg` so that it can be used in diagnostic structs.
Signed-off-by: David Wood <david.wood@huawei.com>
Implement `IntoDiagnosticArg` for `&'a T` when `T` implements
`IntoDiagnosticArg` and `Clone`. Makes it easier to write diagnostic
structs that borrow something which implements `IntoDiagnosticArg`.
Signed-off-by: David Wood <david.wood@huawei.com>
Support for emission of notes was added in f8ebc72 but `emit_note` and
`create_note` functions weren't added to `Handler`.
Signed-off-by: David Wood <david.wood@huawei.com>
Currently, deriving on packed structs has some non-trivial limitations,
related to the fact that taking references on unaligned fields is UB.
The current approach to field accesses in derived code:
- Normal case: `&self.0`
- In a packed struct that derives `Copy`: `&{self.0}`
- In a packed struct that doesn't derive `Copy`: `&self.0`
Plus, we disallow deriving any builtin traits other than `Default` for any
packed generic type, because it's possible that there might be
misaligned fields. This is a fairly broad restriction.
Plus, we disallow deriving any builtin traits other than `Default` for most
packed types that don't derive `Copy`. (The exceptions are those where the
alignments inherently satisfy the packing, e.g. in a type with
`repr(packed(N))` where all the fields have alignments of `N` or less
anyway. Such types are pretty strange, because the `packed` attribute is
not having any effect.)
This commit introduces a new, simpler approach to field accesses:
- Normal case: `&self.0`
- In a packed struct: `&{self.0}`
In the latter case, this requires that all fields impl `Copy`, which is
a new restriction. This means that the following example compiles under
the old approach and doesn't compile under the new approach.
```
#[derive(Debug)]
struct NonCopy(u8);
#[derive(Debug)
#[repr(packed)]
struct MyType(NonCopy);
```
(Note that the old approach's support for cases like this was brittle.
Changing the `u8` to a `u16` would be enough to stop it working. So not
much capability is lost here.)
However, the other constraints from the old rules are removed. We can now
derive builtin traits for packed generic structs like this:
```
trait Trait { type A; }
#[derive(Hash)]
#[repr(packed)]
pub struct Foo<T: Trait>(T, T::A);
```
To allow this, we add a `T: Copy` bound in the derived impl and a `T::A:
Copy` bound in where clauses. So `T` and `T::A` must impl `Copy`.
We can now also derive builtin traits for packed structs that don't derive
`Copy`, so long as the fields impl `Copy`:
```
#[derive(Hash)]
#[repr(packed)]
pub struct Foo(u32);
```
This includes types that hand-impl `Copy` rather than deriving it, such as the
following, that show up in winapi-0.2:
```
#[derive(Clone)]
#[repr(packed)]
struct MyType(i32);
impl Copy for MyType {}
```
The new approach is simpler to understand and implement, and it avoids
the need for the `unsafe_derive_on_repr_packed` check.
One exception is required for backwards-compatibility: we allow `[u8]`
fields for now. There is a new lint for this,
`byte_slice_in_packed_struct_with_derive`.
Previously, a Drop terminator was considered a move in MIR.
This commit changes the behavior to only treat Drop as a mutable
access to the dropped place.
In order for this change to be correct, we need to guarantee that
a) A dropped value won't be used again
b) Places that appear in a drop won't be used again before a
subsequent initialization.
We can ensure this to be correct at MIR construction because Drop
will only be emitted when a variable goes out of scope,
thus having:
(a) as there is no way of reaching the old value. drop-elaboration
will also remove any uninitialized drop.
(b) as the place can't be named following the end of the scope.
However, the initialization status, previously tracked by moves,
should also be tied to the execution of a Drop, hence the
additional logic in the dataflow analyses.
Update wording of invalid_doc_attributes docs.
There was a typo in the original docs for `invalid_doc_attributes`. I felt it could use a little rewording to try to clarify the reasoning for the lint. Also, this adds the future-incompatible notice.
Output tree representation on thir-tree
The current output of `-Zunpretty=thir-tree` is really cumbersome to work with, using an actual tree representation should make it easier to see what the thir looks like.
Insert whitespace to avoid ident concatenation in suggestion
This PR tweaks the suggestion of removing misplaced parentheses around trait bounds so as to avoid concatenating two identifiers. Although subtle, this should make outputs less surprising especially when applying the `MachineApplicable` suggestions automatically.
Implement simple CopyPropagation based on SSA analysis
This PR extracts the "copy propagation" logic from https://github.com/rust-lang/rust/pull/106285.
MIR may produce chains of assignment between locals, like `_x = move? _y`.
This PR attempts to remove such chains by unifying locals.
The current implementation is a bit overzealous in turning moves into copies, and in removing storage statements.
Skip possible where_clause_object_safety lints when checking `multiple_supertrait_upcastable`
Fix#106247
To achieve this, I lifted the `WhereClauseReferencesSelf` out from `object_safety_violations` and move it into `is_object_safe` (which is changed to a new query).
cc `@dtolnay`
r? `@compiler-errors`
Rollup of 8 pull requests
Successful merges:
- #106618 (Disable `linux_ext` in wasm32 and fortanix rustdoc builds.)
- #107097 (Fix def-use dominance check)
- #107154 (library/std/sys_common: Define MIN_ALIGN for m68k-unknown-linux-gnu)
- #107397 (Gracefully exit if --keep-stage flag is used on a clean source tree)
- #107401 (remove the usize field from CandidateSource::AliasBound)
- #107413 (make more pleasant to read)
- #107422 (Also erase substs for new infcx in pin move error)
- #107425 (Check for missing space between fat arrow and range pattern)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Check for missing space between fat arrow and range pattern
Fixes#107420
Ideally we wouldn't emit an error about expecting `=>` etc., but I'm not sure how to recover from this.
`@rustbot` label +A-diagnostics
Also erase substs for new infcx in pin move error
The code originally correctly erased the regions of the type it passed to the newly created infcx. But after the `fn_sig` query was made to return an `EarlyBinder<T>`, some substs that were around were substituted there without erasing their regions. They were then passed into the newly cerated infcx, which caused the ICE.
Fixes#107419
r? compiler-errors who reviewed the original PR adding this diagnostic
Fix def-use dominance check
A definition does not dominate a use in the same statement. For example
in MIR generated for compound assignment x += a (when overflow checks
are disabled).
Use stable metric for const eval limit instead of current terminator-based logic
This patch adds a `MirPass` that inserts a new MIR instruction `ConstEvalCounter` to any loops and function calls in the CFG. This instruction is used during Const Eval to count against the `const_eval_limit`, and emit the `StepLimitReached` error, replacing the current logic which uses Terminators only.
The new method of counting loops and function calls should be more stable across compiler versions (i.e., not cause crates that compiled successfully before, to no longer compile when changes to the MIR generation/optimization are made).
Also see: #103877
Special-case deriving `PartialOrd` for enums with dataless variants
I was able to get slightly better codegen by flipping the derived `PartialOrd` logic for two-variant enums. I also tried to document the implementation of the derive macro to make the special-case logic a little clearer.
```rs
#[derive(PartialEq, PartialOrd)]
pub enum A<T> {
A,
B(T)
}
```
```diff
impl<T: ::core::cmp::PartialOrd> ::core::cmp::PartialOrd for A<T> {
#[inline]
fn partial_cmp(
&self,
other: &A<T>,
) -> ::core::option::Option<::core::cmp::Ordering> {
let __self_tag = ::core::intrinsics::discriminant_value(self);
let __arg1_tag = ::core::intrinsics::discriminant_value(other);
- match ::core::cmp::PartialOrd::partial_cmp(&__self_tag, &__arg1_tag) {
- ::core::option::Option::Some(::core::cmp::Ordering::Equal) => {
- match (self, other) {
- (A::B(__self_0), A::B(__arg1_0)) => {
- ::core::cmp::PartialOrd::partial_cmp(__self_0, __arg1_0)
- }
- _ => ::core::option::Option::Some(::core::cmp::Ordering::Equal),
- }
+ match (self, other) {
+ (A::B(__self_0), A::B(__arg1_0)) => {
+ ::core::cmp::PartialOrd::partial_cmp(__self_0, __arg1_0)
}
- cmp => cmp,
+ _ => ::core::cmp::PartialOrd::partial_cmp(&__self_tag, &__arg1_tag),
}
}
}
```
Godbolt: [Current](https://godbolt.org/z/GYjEzG1T8), [New](https://godbolt.org/z/GoK78qx15)
I'm not sure how common a case comparing two enums like this (such as `Option`) is, and if it's worth the slowdown of adding a special case to the derive. If it causes overall regressions it might be worth just manually implementing this for `Option`.
The code originally correctly erased the regions of the type it passed
to the newly created infcx. But after the `fn_sig` query was made to
return an `EarlyBinder<T>`, some substs that were around were
substituted there without erasing their regions. They were then passed
into the newly cerated infcx, which caused the ICE.
Remove HirId -> LocalDefId map from HIR.
Having this map in HIR prevents the creating of new definitions after HIR has been built.
Thankfully, we do not need it.
Based on https://github.com/rust-lang/rust/pull/103902
Remove `ControlFlow::{BREAK, CONTINUE}`
Libs-API decided to remove these in #102697.
Follow-up to #107023, which removed them from `compiler/`, but a couple new ones showed up since that was merged.
r? libs
Use `FallibleTypeFolder` for `ConstInferUnifier` not `TypeRelation`
I am not sure why this was using a `TypeRelation`, maybe it predates the ability to have fallible type folders
Detect references to non-existant messages in Fluent resources
Should help with cases like #107091, where `{variable}` (a message reference) is accidentally typed, rather than `{$variable}` (a variable reference)
Fixes#107370
```@rustbot``` label +A-translation
Improve unexpected close and mismatch delimiter hint in TokenTreesReader
Fixes#103882Fixes#68987Fixes#69259
The inner indentation mismatching will be covered by outer block, the new added function `report_error_prone_delim_block` will find out the error prone candidates for reporting.
Remove overlapping parts of multipart suggestions
This PR adds a debug assertion that the parts of a single substitution cannot overlap, fixes a overlapping substitution from the testsuite, and fixes https://github.com/rust-lang/rust/issues/106870.
Note that a single suggestion can still have multiple overlapping substitutions / possible edits, we just don't suggest overlapping replacements in a single edit anymore.
I've also included a fix for an unrelated bug where rustfix for `explicit_outlives_requirements` would produce multiple trailing commas for a where clause.
Rollup of 8 pull requests
Successful merges:
- #107022 (Implement `SpecOptionPartialEq` for `cmp::Ordering`)
- #107100 (Use proper `InferCtxt` when probing for associated types in astconv)
- #107103 (Use new solver in `evaluate_obligation` query (when new solver is enabled))
- #107190 (Recover from more const arguments that are not wrapped in curly braces)
- #107306 (Correct suggestions for closure arguments that need a borrow)
- #107339 (internally change regions to be covariant)
- #107344 (Minor tweaks in the new solver)
- #107373 (Don't merge vtables when full debuginfo is enabled.)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Don't merge vtables when full debuginfo is enabled.
This PR makes the compiler not emit the `unnamed_addr` attribute for vtables when full debuginfo is enabled, so that they don't get merged even if they have the same contents. This allows debuggers to more reliably map from a dyn pointer to the self-type of a trait object by looking at the vtable's debuginfo.
The PR only changes the behavior of the LLVM backend as other backends don't emit vtable debuginfo (as far as I can tell).
The performance impact of this change should be small as [measured](https://github.com/rust-lang/rust/pull/103514#issuecomment-1290833854) in a previous PR.
Minor tweaks in the new solver
1. `InferCtxt::probe` is not needed in `compute_subtype_goal` and `compute_well_formed_goal`.
2. Add a handful of comments.
3. Add a micro-optimization in `consider_assumption` where we check the def-ids of the assumption and goal match before instantiating any binders.
r? ``@lcnr``
internally change regions to be covariant
Surprisingly, we consider the reference type `&'a T` to be contravaraint in its lifetime parameter. This is confusing and conflicts with the documentation we have in the reference, rustnomicon, and rustc-dev-guide. This also arguably not the correct use of terminology since we can use `&'static u8` in a place where `&' a u8` is expected, this implies that `&'static u8 <: &' a u8` and consequently `'static <: ' a`, hence covariance.
Because of this, when relating two types, we used to switch the argument positions in a confusing way:
`Subtype(&'a u8 <: &'b u8) => Subtype('b <: 'a) => Outlives('a: 'b) => RegionSubRegion('b <= 'a)`
The reason for the current behavior is probably that we wanted `Subtype('b <: 'a)` and `RegionSubRegion('b <= 'a)` to be equivalent, but I don' t think this is a good reason since these relations are sufficiently different in that the first is a relation in the subtyping lattice and is intrinsic to the type-systems, while the the second relation is an implementation detail of regionck.
This PR changes this behavior to use covariance, so..
`Subtype(&'a u8 <: &'b u8) => Subtype('a <: 'b) => Outlives('a: 'b) => RegionSubRegion('b <= 'a) `
Resolves#103676
r? `@lcnr`
Correct suggestions for closure arguments that need a borrow
Fixes#107301 by dealing with binders correctly
Fixes another issue where we were suggesting adding just `&` when we expected `&mut _` in a closure arg
Recover from more const arguments that are not wrapped in curly braces
Recover from some array, borrow, tuple & arithmetic expressions in const argument positions that lack curly braces and provide a suggestion to fix the issue continuing where #92884 left off. Examples of such expressions: `[]`, `[0]`, `[1, 2]`, `[0; 0xff]`, `&9`, `("", 0)` and `(1 + 2) * 3` (we previously did not recover from them).
I am not entirely happy with my current solution because the code that recovers from `[0]` (coinciding with a malformed slice type) and `[0; 0]` (coinciding with a malformed array type) is quite fragile as the aforementioned snippets are actually successfully parsed as types by `parse_ty` since it itself already recovers from them (returning `[⟨error⟩]` and `[⟨error⟩; 0]` respectively) meaning I have to manually look for `TyKind::Err`s and construct a separate diagnostic for the suggestion to attach to (thereby emitting two diagnostics in total).
Fixes#81698.
`@rustbot` label A-diagnostics
r? diagnostics
Use new solver in `evaluate_obligation` query (when new solver is enabled)
(only when `-Ztrait-solver=next`, of course)
... Does this make sense? It seems to me like it should be reasonable, but maybe there's some reason why this is a bad idea.
r? ``@lcnr``
Needs a perf run because I guess this `solver == TraitSolver::Next` check is on a hot path.
Libs-API decided to remove these in #102697.
Follow-up to #107023, which removed them from `compiler/`, but a couple new ones showed up since that was merged.
Compute generator saved locals on MIR
Generators are currently type-checked by introducing a `witness` type variable, which is unified with a `GeneratorWitness(captured types)` whose purpose is to ensure that the auto traits correctly migrate from the captured types to the `witness` type. This requires computing the captured types on HIR during type-checking, only to re-do it on MIR later.
This PR proposes to drop the HIR-based computation, and only keep the MIR one. This is done in 3 steps.
1. During type-checking, the `witness` type variable is never unified. This allows to stall all the obligations that depend on it until the end of type-checking. Then, the stalled obligations are marked as successful, and saved into the typeck results for later verification.
2. At type-checking writeback, `witness` is replaced by `GeneratorWitnessMIR(def_id, substs)`. From this point on, all trait selection involving `GeneratorWitnessMIR` will fetch the MIR-computed locals, similar to what opaque types do. There is no lifetime to be preserved here: we consider all the lifetimes appearing in this witness type to be higher-ranked.
3. After borrowck, the stashed obligations are verified against the actually computed types, in the `check_generator_obligations` query. If any obligation was wrongly marked as fulfilled in step 1, it should be reported here.
There are still many issues:
- ~I am not too happy having to filter out some locals from the checked bounds, I think this is MIR building that introduces raw pointers polluting the analysis;~ solved by a check specific to static variables.
- the diagnostics for captured types don't show where they are used/dropped;
- I do not attempt to support chalk.
cc `@eholk` `@jyn514` for the drop-tracking work
r? `@oli-obk` as you warned me of potential unsoundness
solver comments + remove `TyCtxt::evaluate_goal`
from the `RustcContributor::explore` session yesterday.
This also removes `TyCtxt::evaluate_goal` because to canonicalize you have to use an `InferCtxt` anyways at which point we should just always get people to use `evaluate_root_goal`.
r? ``@spastorino``
Replace format flags u32 by enums and bools.
This gets rid of the `flags: u32` field where each bit has a special meaning, and replaces it by simple enums and booleans.
Part of #99012
rustdoc: Collect "rustdoc-reachable" items during early doc link resolution
This pass only needs to know about visibilities, attributes and reexports, so it can be run early, similarly to `compute_effective_visibilities` in rustc.
Results of this pass can be used to prune the list of extern impls early thus improving performance of https://github.com/rust-lang/rust/pull/94857.
rustc_metadata: Fix `encode_attrs`
This function didn't do what the authors intended it to do.
- Due to `move` in the closure `is_public` wasn't captured by mutalbe reference and wasn't used as a cache.
- Due to iterator cloning all the `should_encode_attr` logic run for the second time to calculate `may_have_doc_links`
This PR fixes these issues, and calculates all the needed attribute flags in one go.
(Noticed while implementing https://github.com/rust-lang/rust/pull/107136.)
core: Support variety of atomic widths in width-agnostic functions
Before this change, the following functions and macros were annotated with `#[cfg(target_has_atomic = "8")]` or
`#[cfg(target_has_atomic_load_store = "8")]`:
* `atomic_int`
* `strongest_failure_ordering`
* `atomic_swap`
* `atomic_add`
* `atomic_sub`
* `atomic_compare_exchange`
* `atomic_compare_exchange_weak`
* `atomic_and`
* `atomic_nand`
* `atomic_or`
* `atomic_xor`
* `atomic_max`
* `atomic_min`
* `atomic_umax`
* `atomic_umin`
However, none of those functions and macros actually depend on 8-bit width and they are needed for all atomic widths (16-bit, 32-bit, 64-bit etc.). Some targets might not support 8-bit atomics (i.e. BPF, if we would enable atomic CAS for it).
This change fixes that by removing the `"8"` argument from annotations, which results in accepting the whole variety of widths.
Fixes#106845Fixes#106795
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
Sync rustc_codegen_cranelift
For cg_clif itself there have been a couple of bug fixes since the last sync, a Cranelift update and implemented all remaining simd platform intrinsics used by `std::simd`. (`std::arch` still misses a lot though) Most of the diff is from reworking of the cg_clif build system though.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
A definition does not dominate a use in the same statement. For example
in MIR generated for compound assignment x += a (when overflow checks
are disabled).
make `output_filenames` a real query
part of #105462
This may be a perf regression and is not obviously the right way forward. We may store this information in the resolver after freezing it for example.
Rollup of 8 pull requests
Successful merges:
- #106904 (Preserve split DWARF files when building archives.)
- #106971 (Handle diagnostics customization on the fluent side (for one specific diagnostic))
- #106978 (Migrate mir_build's borrow conflicts)
- #107150 (`ty::tls` cleanups)
- #107168 (Use a type-alias-impl-trait in `ObligationForest`)
- #107189 (Encode info for Adt in a single place.)
- #107322 (Custom mir: Add support for some remaining, easy to support constructs)
- #107323 (Disable ConstGoto opt in cleanup blocks)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Disable ConstGoto opt in cleanup blocks
Fixes#107315 .
There is probably a smaller hammer that we could use here, but none that is super obviously correct. We can always revisit this in the future.
Could not add a test because custom mir does not support cleanup blocks. However, did check that the fallible_iterator crate no longer ICEs with the other PR cherry picked.
r? `@tmiasko`
Custom mir: Add support for some remaining, easy to support constructs
Some documentation for previous changes and support for `Deinit`, checked binops, len, and array repetition
r? ```@oli-obk``` or ```@tmiasko```
`ty::tls` cleanups
Pull it out into a separate file, make the conditional compilation more obvious and give the internal functions better names.
Pulled out of #106311
r? cjgillot
Migrate mir_build's borrow conflicts
This also changes the error message slightly, for two reasons:
- I'm not a fan of saying "value borrowed, by `x`, here"
- it simplifies the error implementation significantly.
Move format_args!() into AST (and expand it during AST lowering)
Implements https://github.com/rust-lang/compiler-team/issues/541
This moves FormatArgs from rustc_builtin_macros to rustc_ast_lowering. For now, the end result is the same. But this allows for future changes to do smarter things with format_args!(). It also allows Clippy to directly access the ast::FormatArgs, making things a lot easier.
This change turns the format args types into lang items. The builtin macro used to refer to them by their path. After this change, the path is no longer relevant, making it easier to make changes in `core`.
This updates clippy to use the new language items, but this doesn't yet make clippy use the ast::FormatArgs structure that's now available. That should be done after this is merged.
Use `can_eq` to compare types for default assoc type error
This correctly handles inference variables like `{integer}`. I had to move all of this `note_and_explain` code to `rustc_infer`, it made no sense for it to be in `rustc_middle` anyways.
The commits are reviewed separately.
Fixes#106968
remove unnecessary check for opaque types
this isn't needed and may hide some errors.
after analysis there are no opaque types so it's a noop anyways
before analysis there are opaque types but due to `Reveal::UserFacing` we don't reveal them. `is_subtype` simply discards the opaque type constraints as these will get checked again during mir borrowck.
r? types
want to land this after the beta-cutoff as mir validator changes are apparently pretty scary
Append .dwp to the binary filename instead of replacing the existing extension.
gdb et al. expect to find the dwp file at `<binary>`.dwp, even if <binary> already has an extension (e.g. libfoo.so's dwp is expected to be at libfoo.so.dwp).
Rollup of 11 pull requests
Successful merges:
- #106407 (Improve proc macro attribute diagnostics)
- #106960 (Teach parser to understand fake anonymous enum syntax)
- #107085 (Custom MIR: Support binary and unary operations)
- #107086 (Print PID holding bootstrap build lock on Linux)
- #107175 (Fix escaping inference var ICE in `point_at_expr_source_of_inferred_type`)
- #107204 (suggest qualifying bare associated constants)
- #107248 (abi: add AddressSpace field to Primitive::Pointer )
- #107272 (Implement ObjectSafe and WF in the new solver)
- #107285 (Implement `Generator` and `Future` in the new solver)
- #107286 (ICE in new solver if we see an inference variable)
- #107313 (Add Style Team Triagebot config)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
ICE in new solver if we see an inference variable
By construction, we do not expect to see any `ty::Infer(ty::TyVar(_))` inference types in the solver (we treat this as ambiguous, since we need to be able to structurally resolve the self type at least one layer to assemble candidates for it). Additionally, since we're doing no freshening, we also don't expect to see any fresh vars of any kind in the solver.
Let's make that an ICE so we can catch any mistakes.
When #107282 lands, we should also ICE there too if we see a non-int/float infer.
r? `@lcnr`
abi: add AddressSpace field to Primitive::Pointer
...and remove it from `PointeeInfo`, which isn't meant for this.
There are still various places (marked with FIXMEs) that assume all pointers
have the same size and alignment. Fixing this requires parsing non-default
address spaces in the data layout string (and various other changes),
which will be done in a followup.
(That is, if it's actually worth it to support multiple different pointer sizes.
There is a lot of code that would be affected by that.)
Fixes#106367
r? ``@oli-obk``
cc ``@Patryk27``
Fix escaping inference var ICE in `point_at_expr_source_of_inferred_type`
Fixes#107158
`point_at_expr_source_of_inferred_type` uses `lookup_probe` to adjust the self type of a method receiver -- but that method returns inference variables from inside a probe. That means that the ty vars are no longer valid, so we can't use any infcx methods on them.
Also, pass some extra span info to hack a quick solution to bad labels, resulting in this diagnostic improvement:
```rust
fn example2() {
let mut x = vec![1];
x.push("");
}
```
```diff
error[E0308]: mismatched types
--> src/main.rs:5:12
|
5 | x.push("");
| ---- ^^
| | |
| | expected integer, found `&str`
- | | this is of type `&'static str`, which causes `x` to be inferred as `Vec<{integer}>`
| arguments to this method are incorrect
```
(since that "which causes `x` to be inferred as `Vec<{integer}>` part is wrong)
r? `@estebank`
(we really should make this code better in general, cc #106590, but that's a bit bigger issue that needs some more thinking about)
Custom MIR: Support binary and unary operations
Lower binary and unary operations directly to corresponding unchecked MIR
operations. Ultimately this might not be syntax we want, but it allows for
experimentation in the meantime.
r? ````@oli-obk```` ````@JakobDegen````
Teach parser to understand fake anonymous enum syntax
Parse `Ty | OtherTy` in function argument and return types.
Parse type ascription in top level patterns.
Minimally address #100741.
InstCombine away intrinsic validity assertions
This optimization (currently) fires 246 times on the standard library. It seems to fire hardly at all on the big crates in the benchmark suite. Interesting.
Delete `SimplifyArmIdentity` and `SimplifyBranchSame` mir opts
I had attempted to fix the first of these opts in #94177 . However, despite that PR already being a full re-write, it still did not fix some of the core soundness issues. The optimizations that are attempted here are likely to be desirable, but I do not expect any of the currently written code to survive into a sound implementation. Deleting the code keeps us from having to maintain the passes in the meantime.
Closes#77359 , closes#72800 , closes#78628
r? ```@cjgillot```
Add hint for missing lifetime bound on trait object when type alias is used
Fix issue #103582.
The problem: When a type alias is used to specify the return type of the method in a trait impl, the suggestion for fixing the problem of "missing lifetime bound on trait object" of the trait impl will not be created. The issue caused by the code which searches for the return trait objects when constructing the hint suggestion is not able to find the trait objects since they are specified in the type alias path instead of the return path of the trait impl.
The solution: Trace the trait objects in the type alias path and provide them along with the alias span to generate the suggestion in case the type alias is used in return type of the method in the trait impl.
use `LocalDefId` instead of `HirId` in trait resolution to simplify the obligation clause resolution
This commit introduces a refactoring suggested by `@lcnr` to simplify the obligation clause resolution.
This is just the first PR that introduces a type of refactoring, but others PRs will follow this to introduce name changing to change from the variable name from `body_id` to something else.
Fixes https://github.com/rust-lang/rust/issues/104827
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
`@rustbot` r? `@lcnr`
Add suggestion to remove if in let..else block
Adds an additional hint to failures where we encounter an else keyword while we're parsing an if-let expression.
This is likely that the user has accidentally mixed if-let and let..else together.
Fixes#103791.
rustc_metadata: Support non-`Option` nullable values in metadata tables
This is a convenience feature for cases in which "no value in the table" and "default value in the table" are equivalent.
Tables using `Table<DefIndex, ()>` are migrated in this PR, some other cases can be migrated later.
This helps `DocFlags` in https://github.com/rust-lang/rust/pull/107136 in particular.
Allow setting CFG_DISABLE_UNSTABLE_FEATURES to 0
Two locations check whether this build-time environment variable is defined. Allowing it to be explicitly disabled with a "0" value is useful, especially for integrating with external build systems.
This function didn't do what the authors intended it to do.
- Due to `move` in the closure `is_public` wasn't captured by mutalbe reference and wasn't used as a cache.
- Due to iterator cloning all the `should_encode_attr` logic run for the second time to calculate `may_have_doc_links`
This PR fixes these issues, and calculates all the needed attribute flags in one go.
Atomic operations for different widths (8-bit, 16-bit, 32-bit etc.) are
guarded by `target_has_atomic = "value"` symbol (i.e. `target_has_atomic
= "8"`) (and the other derivatives), but before this change, there was
no width-agnostic symbol indicating a general availability of atomic
operations.
This change introduces:
* `target_has_atomic_load_store` symbol when atomics for any integer
width are supported by the target.
* `target_has_atomic` symbol when also CAS is supported.
Fixes#106845
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
- On compiler-error's suggestion of moving this lower down the stack,
along the path of `report_mismatched_types()`, which is used
by `rustc_hir_analysis` and `rustc_hir_typeck`.
- update ui tests, add test
- add suggestions for references to fn pointers
- modify `TypeErrCtxt::same_type_modulo_infer` to take `T: relate::Relate` instead of `Ty`
Previously, we verified that FFI attrs were used on foreign items,
but this allowed them on both foreign functions and foreign statics.
This change only allows them on foreign functions.
Adds an additional hint to failures where we encounter an else keyword
while we're parsing an if-let block.
This is likely that the user has accidentally mixed if-let and let...else
together.
- Remove logic that limits const eval based on terminators, and use the
stable metric instead (back edges + fn calls)
- Add unstable flag `tiny-const-eval-limit` to add UI tests that do not
have to go up to the regular 2M step limit
This patch adds a `MirPass` that tracks the number of back-edges and
function calls in the CFG, adds a new MIR instruction to increment a
counter every time they are encountered during Const Eval, and emit a
warning if a configured limit is breached.
This is a convenience feature for cases in which "no value in the table" and "default value in the table" are equivalent.
Tables using `Table<DefIndex, ()>` are migrated in this PR, some other cases can be migrated later.
This helps `DocFlags` in https://github.com/rust-lang/rust/pull/107136 in particular.
use LocalDefId instead of HirId in trait resolution to simplify
the obligation clause resolution
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Consistently use dominates instead of is_dominated_by
There is a number of APIs that answer dominance queries. Previously they were named either "dominates" or "is_dominated_by". Consistently use the "dominates" form.
No functional changes.
Instantiate dominators algorithm only once
Remove inline from BasicBlocks::dominators to instantiate the dominator algorithm only once - in the rustc_middle crate.
remove error code from `E0789`, add UI test/docs
`E0789` shouldn't have an error code, it's explicitly internal-only and is tiny in scope. (I wonder if we can tighten the standard for this in the RFC?) I also added a UI test and error docs (done like `E0208`, they are "no longer emitted").
r? `@GuillaumeGomez` (shouldn't need a compiler review, it's pretty minor)
BPF: Disable atomic CAS
Enabling CAS for BPF targets (https://github.com/rust-lang/rust/pull/105708) breaks the build of core library.
The failure occurs both when building rustc for BPF targets and when
building crates for BPF targets with the current nightly.
The LLVM BPF backend does not correctly lower all `atomicrmw` operations
and crashes for unsupported ones.
Before we can enable CAS for BPF in Rust, we need to fix the LLVM BPF
backend first.
Fixes#106795
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
rustc_metadata: Encode `doc(hidden)` flag to metadata
To retrieve these flags rustdoc currently has to mass decode full attributes for items in the whole crate tree, so it's better to pre-compute it in advance.
This is especially important for short-term performance of https://github.com/rust-lang/rust/pull/107054 because resolver cannot use memoization of query results yet.
Consider doc(alias) when providing typo suggestions
This means that
```rust
impl Foo {
#[doc(alias = "quux")]
fn bar(&self) {}
}
fn main() {
(Foo {}).quux();
}
```
will suggest `bar`. This currently uses the "there is a method with a similar name" help text, because the point where we choose and emit a suggestion is different from where we gather the suggestions. Changes have mainly been made to the latter.
The selection code will now fall back to aliased candidates, but generally only if there is no candidate that matches based on the existing Levenshtein methodology.
Fixes#83968.
...and remove it from `PointeeInfo`, which isn't meant for this.
There are still various places (marked with FIXMEs) that assume all pointers
have the same size and alignment. Fixing this requires parsing non-default
address spaces in the data layout string, which will be done in a followup.
there were fixmes for this already
i am about to remove is_ptr (since callers need to properly distinguish
between pointers in different address spaces), so might as well do this
at the same time
This means that
```rust
impl Foo {
#[doc(alias = "quux")]
fn bar(&self) {}
}
fn main() {
(Foo {}).quux();
}
```
will suggest `bar`. This currently uses the "there is a method with a
similar name" help text, because the point where we choose and emit a
suggestion is different from where we gather the suggestions. Changes
have mainly been made to the latter.
The selection code will now fall back to aliased candidates, but
generally only if there is no candidate that matches based on the
existing Levenshtein methodology.
Fixes#83968.
