Deriving: Include bound generic params in type parameters for where clause
Fixes#89188.
The `derive` macro ignored the `for<'s>` needed with the `Fn` trait in that code example.
edit: I'm unsure if this might cause regressions. I'm not an experienced compiler developer so I'm not used to thinking about unwanted side effects code changes like this might have.
For some reason unboxed_closures supresses the feature gate for
min_specialization when implementing TrustedStep. min_specialization is
the true feature that is used.
The previous macro_rules! parsers failed when an additional modifier was added
with ambiguity errors. The error is pretty unclear as to what exactly the cause
here is, but this change simplifies the argument parsing code such that the
error is avoided.
resolve: Cache module loading for all foreign modules
It was previously cached for modules loaded from `fn get_module`, but not for modules loaded from `fn build_reduced_graph_for_external_crate_res`.
This also makes all foreign modules use their real parent, span and expansion instead of possibly a parent/span/expansion of their reexport.
Modules are also often compared using referential equality (`ptr::eq`), this change makes such comparisons correct in all cases.
An ICE happening on attempt to decode expansions for foreign enums and traits is avoided.
Also local enums and traits are now added to the module map.
Follow up to https://github.com/rust-lang/rust/pull/88872.
r? `@cjgillot`
It was previously cached for modules loaded from `fn get_module`, but not for modules loaded from `fn build_reduced_graph_for_external_crate_res`.
This also makes all foreign modules use their real parent, span and expansion instead of possibly a parent/span/expansion of their reexport.
An ICE happening on attempt to decode expansions for foreign enums and traits is avoided.
Also local enums and traits are now added to the module map.
Avoid nondeterminism in trimmed_def_paths
Previously this query depended on the global interning order of Symbols, which
meant that irrelevant changes could influence the query and cause
recompilations. This commit ensures that the return set is stable and will not
be affected by the global order by deterministically (in lexicographic order)
choosing a name to use if there are multiple names for a single DefId.
This should fix the cause of the [regressions] in #83343.
[regressions]: https://perf.rust-lang.org/compare.html?start=9620f3a84b079decfdc2e557be007580b097fe43&end=addb4da686a97da46159f0123cb6cdc2ce3d7fdb
Fix clippy lints
I'm currently working on allowing clippy to run on librustdoc after a discussion I had with `@Mark-Simulacrum.` So in the meantime, I fixed a few lints on the compiler crates.
The checks removed here caused a small perf regression:
https://github.com/rust-lang/rust/pull/88824#issuecomment-932664761
Since the attribute is currently only applied to traits, I don't think
it's worth keeping the additional checks for now.
If/when we decide to apply the attribute somewhere else, we can
(partially) revert this and evaluate if the perf impact is acceptable.
A subset of places referred to 'super-trait', so this changes them
to all use 'supertrait'. This matches 'supertype' and some other
usages. An exception is 'auto-trait' which is consistently used
in that manner.
Rollup of 7 pull requests
Successful merges:
- #85223 (rustdoc: Clarified the attribute which prompts the warning)
- #88847 (platform-support.md: correct ARMv7+MUSL platform triple notes)
- #88963 (Coerce const FnDefs to implement const Fn traits )
- #89376 (Fix use after drop in self-profile with llvm events)
- #89422 (Replace whitespaces in doctests' name with dashes)
- #89440 (Clarify a sentence in the documentation of Vec (#84488))
- #89441 (Normalize after substituting via `field.ty()`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Normalize after substituting via `field.ty()`
Back in https://github.com/rust-lang/rust/issues/72476 I hadn't understood where the problem was coming from, and only worked around the issue. What happens is that calling `field.ty()` on a field of a generic struct substitutes the appropriate generics but doesn't normalize the resulting type.
As a consumer of types I'm surprised that one would substitute without normalizing, feels like a footgun, so I added a comment.
Fixes https://github.com/rust-lang/rust/issues/89393.
Fix use after drop in self-profile with llvm events
self-profile with `-Z self-profile-events=llvm` have failed with a segmentation fault due to this use after drop.
this type of events can be more useful now that the new passmanager is the default.
Coerce const FnDefs to implement const Fn traits
You can now pass a FnDef to a function expecting `F` where `F: ~const FnTrait`.
r? ``@oli-obk``
``@rustbot`` label T-compiler F-const_trait_impl
Rework HIR API to make invocations of the hir_crate query harder.
`hir_crate` forces the recomputation of queries that depend on it.
This PR aims at avoiding useless invocations of `hir_crate` by making dependent code go through `tcx.hir()`.
This commit removes the restriction of `InstanceDef::Item` on
polymorphization, so that shims can now be polymorphized.
Signed-off-by: David Wood <david.wood@huawei.com>
rustc adds notes to errors which happen post-monomorphization to
provide the user with helpful context (as these errors may rely on the
specific instantiations). To prevent this note being added where it is
not appropriate, the node is checked to originate outwith the current
crate. However, when polymorphization is enabled, this can result in
some errors (produced by `optimized_mir`) to occur earlier in
compilation than they normally would, during the collection of shims.
Some shims have ids that originate in the standard library, but these
should not receive the PME note, so instances for compiler-generated
functions no longer receive this note.
Signed-off-by: David Wood <david.wood@huawei.com>
This commit removes all logic which marks parameters as used based on
their presence in predicates - given rust-lang/rust#75675, this will
enable more polymorphization and avoid the symbol clashes that predicate
logic previously sidestepped.
Signed-off-by: David Wood <david@davidtw.co>
Correct caller/callsite confusion in inliner message
`callee_body` is the MIR `Body` for the `callsite.callee` so this message basically says `"Inline {bar span} into bar"` when it should say `"Inline bar into foo"`.
Extracted out of #82280
Improve error message for `printf`-style format strings
Fixes#89173. The following is actually supported today:
```rust
fn main() {
let num = 5;
let width = 20;
print!("%*2$x", num, width);
}
```
```
error: multiple unused formatting arguments
--> src/main.rs:4:21
|
4 | print!("%*2$x", num, width);
| ------- ^^^ ^^^^^ argument never used
| || |
| || argument never used
| |help: format specifiers use curly braces: `{:1$x}`
| multiple missing formatting specifiers
|
= note: printf formatting not supported; see the documentation for `std::fmt`
```
However, as noted in #89173, something like
```rust
print!("%0*x", width, num);
```
does not give a helpful suggestion. I think this is partly intended, because there actually _is_ no Rust equivalent to this; you always have to use a positional or named argument to specify the width (instead of just using the "next" argument, as `printf` or even `.*` as a precision specifier in Rust would). Therefore, I have added a note:
```
[...]
note: format specifiers use curly braces, and you have to use a positional or named parameter for the width
--> t2.rs:4:13
|
4 | print!("%0*x", width, num);
| ^^^^
= note: printf formatting not supported; see the documentation for `std::fmt`
```
This is not perfect, but it should at least point the user in the right direction, instead of issuing no explanation at all.
cc ```@lcnr```
Added -Z randomize-layout flag
An implementation of #77316, it currently randomly shuffles the fields of `repr(rust)` types based on their `DefPathHash`
r? ``@eddyb``
Rollup of 7 pull requests
Successful merges:
- #88838 (Do not suggest importing inaccessible items)
- #89251 (Detect when negative literal indices are used and suggest appropriate code)
- #89321 (Rebase resume argument projections during state transform)
- #89327 (Pick one possible lifetime in case there are multiple choices)
- #89344 (Cleanup lower_generics_mut and make span be the bound itself)
- #89397 (Update `llvm` submodule to fix function name mangling on x86 Windows)
- #89412 (Add regression test for issues #88969 and #89119 )
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Cleanup lower_generics_mut and make span be the bound itself
Closes#86298 (supersedes those changes)
r? `@cjgillot` since you reviewed the other PR
(Used wrong branch for #89338)
Pick one possible lifetime in case there are multiple choices
In case a lifetime variable is created, but doesn't have an obvious lifetime in the list of named lifetimes that it should be inferred to, just pick the first one for the diagnostic.
This happens e.g. in
```rust
fn foo<'a, 'b>(a: Struct<'a>, b: Struct<'b>) -> impl Trait<'a, 'b> {
if bar() { a } else { b }
}
```
where we get a lifetime variable that combines the lifetimes of `a` and `b` creating a lifetime that is the intersection of both. Right now the type system cannot express this and thus we get an error, but that error also can't express this.
I can also create an entirely new diagnostic that mentions all involved lifetimes, so it would actually mention `'a` and `'b` instead of just `'b`.
Rebase resume argument projections during state transform
When remapping a resume argument with projections rebase them on top of
the new base.
The case where resume argument has projections is unusual, but might
arise with box syntax where the assignment is performed directly into
the box without an intermediate temporary.
Fixes#85635.
Do not suggest importing inaccessible items
Fixes#88472. For this example:
```rust
mod a {
struct Foo;
}
mod b {
type Bar = Foo;
}
```
rustc currently emits:
```
error[E0412]: cannot find type `Foo` in this scope
--> test.rs:6:16
|
6 | type Bar = Foo;
| ^^^ not found in this scope
|
help: consider importing this struct
|
6 | use a::Foo;
|
```
this is incorrect, as applying this suggestion leads to
```
error[E0603]: struct `Foo` is private
--> test.rs:6:12
|
6 | use a::Foo;
| ^^^ private struct
|
note: the struct `Foo` is defined here
--> test.rs:2:5
|
2 | struct Foo;
| ^^^^^^^^^^^
```
With my changes, I get:
```
error[E0412]: cannot find type `Foo` in this scope
--> test.rs:6:16
|
6 | type Bar = Foo;
| ^^^ not found in this scope
|
= note: this struct exists but is inaccessible:
a::Foo
```
As for the wildcard mentioned in #88472, I would argue that the warning is actually correct, since the import _is_ unused. I think the real issue is the wrong suggestion, which I have fixed here.
CTFE: tweak aggregate rvalue handling
I have not looked at this code in ages... I think Miri does not even hit it, since (most?) aggregate rvalues are lowered somewhere in the MIR pipeline, but CTFE does hit it.
So this adds some extra sanity assertions, and removes a ZST special case -- ZST should only be special cased fairly late (when the actual memory access happens); e.g. `!` is a ZST and we still want `copy_op` to be called for it since it will perform validation (and raise UB, since `!` is never valid).
