Fix ICE when `main` is declared in an `extern` block
Changes in #84401 to implement `imported_main` changed how the crate entry point is found, and a declared `main` in an `extern` block was detected erroneously. This was causing the ICE described in #86110.
This PR adds a check for this case and emits an error instead. Previously a `main` declaration in an `extern` block was not detected as an entry point at all, so emitting an error shouldn't break anything that worked previously. In 1.52.1 stable this is demonstrated, with a `` `main` function not found`` error.
Fixes#86110
Remove unused dependencies from compiler crates
Various compiler crates have dependencies that they don't appear to use. I used some scripting to detect such dependencies, filtered them based on some manual review, and removed those that do indeed appear to be entirely unused.
Test cross-crate usage of `feature(const_trait_impl)`
This PR does two things:
- Fixes metadata not encoded properly for functions in const trait impls.
- Adds tests for using const trait impls cross-crate with the feature gate on the user crate either enabled or disabled.
AFAIK, this means we can now constify some trait impls in the standard library 🎉
See #67792 for the tracking issue, cc `@oli-obk`
Check node kind to avoid ICE in `check_expr_return()`
This PR fixes#86721. The ICE described there is apparently due to a misunderstanding:
e98897e5dc/compiler/rustc_typeck/src/check/expr.rs (L684-L685)
Intuitively, one would think that calling `expect_item()` after `get_parent_item()` should succeed, but as it turns out, `get_parent_item()` can also return foreign, trait, and impl items as well as crates, whereas `expect_item()` specifically expects a `Node::Item`. I have therefore added an extra check to prevent this ICE.
Introduce -Zprofile-closures to evaluate the impact of 2229
This creates a CSV with name "closure_profile_XXXXX.csv", where the
variable part is the process id of the compiler.
To profile a cargo project you can run one of the following depending on
if you're compiling a library or a binary:
```
cargo +nightly rustc --lib -- -Zprofile-closures
cargo +nightly rustc --bin {binary_name} -- -Zprofile-closures
```
r? `@nikomatsakis`
Only include lint in future_incompatible lint group if not an edition lint
A follow up to #86330 - this only includes lints annotated with `FutureIncompatibleInfo` in the `future_incompatibile` lint group if the future compatibility is not tied to an edition.
We probably want to rename `FutureIncompatibleInfo` to something else since this type is now used to indicate future breakages of all kinds (even those that happen in editions). I'd prefer to do that in a separate PR though.
r? `@nikomatsakis`
Change vtable memory representation to use tcx allocated allocations.
This fixes https://github.com/rust-lang/rust/issues/86324. However i suspect there's more to change before it can land.
r? `@bjorn3`
cc `@rust-lang/miri`
Don't make `rustc_insignificant_dtor` feature gate
This isn't a feature gate, it's an attribute that is feature gated behind the `rustc_attrs` attribute. Closes#85680.
Fix garbled suggestion for missing lifetime specifier
This PR fixes#86667. The suggestion code currently checks whether there is a generic parameter that is not a synthetic `impl Trait` parameter and, if so, suggests to insert a new lifetime `'a` before that generic parameter. However, it does not make sense to insert `'a` in front of an elided lifetime parameter, since these are synthetic as well, which leads to the garbled suggestion in #86667.
Turn non_fmt_panic into a future_incompatible edition lint.
This turns the `non_fmt_panic` lint into a future_incompatible edition lint, so it becomes part of the `rust_2021_compatibility` group. See https://github.com/rust-lang/rust/issues/85894.
This lint produces both warnings about semantical changes (e.g. `panic!("{{")`) and things that will become hard errors (e.g. `panic!("{")`). So I added a `explain_reason: false` that supresses the default "this will become a hard error" or "the semantics will change" message, and instead added a note depending on the situation. (cc `@rylev)`
r? `@nikomatsakis`
Fix `future_prelude_collision` false positive
Fixes#86633
The lint for checking if method resolution of methods named `try_into` will fail in 2021 edition previously would fire on all inherent methods, however for inherent methods that consume `self`, this takes priority over `TryInto::try_into` due to being inherent, while trait method and methods that take `&self` or `&mut self` don't take priority, and thus aren't affected by this false positive.
This fix is rather simple: simply checking if the inherent method doesn't auto-deref or auto-ref (and thus takes `self`) and if so, prevents the lint from firing.
This prevents mistakes where the feature is in the list of incomplete
features but not actually a feature by making the incompleteness a part
of the declaration.
This creates a CSV with name "closure_profile_XXXXX.csv", where the
variable part is the process id of the compiler.
To profile a cargo project you can run one of the following depending on
if you're compiling a library or a binary:
```
cargo +stage1 rustc --lib -- -Zprofile-closures
cargo +stage1 rustc --bin -- -Zprofile-closures
```
Fix type checking of return expressions outside of function bodies
This pull request fixes#86188. The problem is that the current code for type-checking `return` expressions stops if the `return` occurs outside of a function body, while the correct behavior is to continue type-checking the return value expression (otherwise an ICE happens later on because variables declared in the return value expression don't have a type).
Also, I have noticed that it is sometimes not obvious why a `return` is outside of a function body; for instance, in the example from #86188 (which currently causes an ICE):
```rust
fn main() {
[(); return || {
let tx;
}]
}
```
I have changed the error message to also explain why the `return` is considered outside of the function body:
```
error[E0572]: return statement outside of function body
--> ice0.rs:2:10
|
1 | / fn main() {
2 | | [(); return || {
| |__________^
3 | || let tx;
4 | || }]
| ||_____^ the return is part of this body...
5 | | }
| |_- ...not the enclosing function body
```
Reserve prefixed identifiers and literals (RFC 3101)
This PR denies any identifiers immediately followed by one of three tokens `"`, `'` or `#`, which is stricter than the requirements of RFC 3101 but may be necessary according to the discussion at [Zulip].
[Zulip]: https://rust-lang.zulipchat.com/#narrow/stream/268952-edition-2021/topic/reserved.20prefixes/near/238470099
The tracking issue #84599 says we'll add a feature gate named `reserved_prefixes`, but I don't think I can do this because it is impossible for the lexer to know whether a feature is enabled or not. I guess determining the behavior by the edition information should be enough.
Fixes#84599
2229: Capture box completely in move closures
Even if the content from box is used in a sharef-ref context,
we capture the box entirerly.
This is motivated by:
1) We only capture data that is on the stack.
2) Capturing data from within the box might end up moving more data than
the user anticipated.
Closes https://github.com/rust-lang/project-rfc-2229/issues/50
r? `@nikomatsakis`
