Warn about unused crate deps
Implements #57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`.
Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`.
If a crate has multiple aliases (eg using `foo = { package = "bar" }` in `Cargo.toml`), then it will warn about each unused alias.
This does not consider crate added by some other means than `--extern`, including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this).
Unfortunately this probably [does not yet work well with Cargo](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) as it will over-specify crates, causing spurious warnings. As a result, this lint is "allow" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.
JS cleanup
The goal here is just to improve the source code a bit. I recommend to review one commit at a time, otherwise it might not make much sense. :)
The biggest commit is the second one: to prevent to have "global" variables declared in `main.js` (and thus prevent name conflict or overwriting), I moved such code into anonymous functions.
r? @kinnison
cc @rust-lang/rustdoc
add a lint against references to packed fields
Creating a reference to an insufficiently aligned packed field is UB and should be disallowed, both inside and outside of `unsafe` blocks. However, currently there is no stable alternative (https://github.com/rust-lang/rust/issues/64490) so all we do right now is have a future incompatibility warning when doing this outside `unsafe` (https://github.com/rust-lang/rust/issues/46043).
This adds an allow-by-default lint. @retep998 suggested this can help early adopters avoid issues. It also means we can then do a crater run where this is deny-by-default as suggested by @joshtriplett.
I guess the main thing to bikeshed is the lint name. I am not particularly happy with "packed_references" as it sounds like the packed field has reference type. I chose this because it is similar to "safe_packed_borrows". What about "reference_to_packed" or "unaligned_reference" or so?
This will print a diagnostic for crates which are mentioned as `--extern`
arguments on the command line, but are never referenced from the source.
This diagnostic is controlled by `-Wunused-crate-dependencies` or
`#![warn(unused_crate_dependencies)]` and is "allow" by default.
There are cases where certain crates need to be linked in but are not
directly referenced - for example if they are providing symbols for C
linkage. In this case the warning can be suppressed with
`use needed_crate as _;`.
Thanks to @petrochenkov for simplified core.
Resolves issue #57274
Fix bug in shebang handling
Shebang handling was too agressive in stripping out the first line in cases where it is actually _not_ a shebang, but instead, valid rust (#70528). This is a second attempt at resolving this issue (the first attempt was reverted, for, among other reasons, causing an ICE in certain cases (#71372, #71471).
The behavior is now codified by a number of UI tests, but simply:
For the first line to be a shebang, the following must all be true:
1. The line must start with `#!`
2. The line must contain a non-whitespace character after `#!`
3. The next character in the file, ignoring comments & whitespace must not be `[`
I believe this is a strict superset of what we used to allow, so perhaps a crater run is unnecessary, but probably not a terrible idea.
Fixes#70528
Perform MIR NRVO even if types don't match
This is the most straightforward way to resolve#72428, but it could cause problems in codegen since the type of `_0` may no longer match the return type of the body.
add regression tests for stalled_on const vars
closes#70180
Afaict this has been fixed sometime after #70213
`trait_ref_type_vars` correctly adds const infers and I did not find any remaining `FIXME`s which correspond to this issue.
7c59a81a5f/src/librustc_trait_selection/traits/fulfill.rs (L555-L557)
Added both examples from the issue as regression tests and renamed `trait_ref_type_vars` -> `trait_ref_infer_vars`.
r? @eddyb
Rollup of 4 pull requests
Successful merges:
- #72153 (exhaustively check `ty::Kind` during structural match checking)
- #72308 (Emit a better diagnostic when function actually has a 'self' parameter)
- #72560 (Enable `glacier` command via triagebot)
- #72567 (Clean up E0608 explanation)
Failed merges:
r? @ghost
Emit a better diagnostic when function actually has a 'self' parameter
Fixes#66898
When we are unable to resolve a reference to `self`, we current assume
that the containing function doesn't have a `self` parameter, and
emit an error message accordingly.
However, if the reference to `self` was created by a macro invocation,
then resolution will correctly fail, due to hygiene. In this case, we
don't want to tell the user that the containing fuction doesn't have a
'self' paramter if it actually has one.
This PR checks for the precense of a 'self' parameter, and adjusts the
error message we emit accordingly.
TODO: The exact error message we emit could probably be improved. Should
we explicitly mention hygiene?
exhaustively check `ty::Kind` during structural match checking
This was prone to errors as we may forget new kinds in the future.
I am also not yet sure about some kinds.
`ty::GeneratorWitness(..) | ty::Infer(_) | ty::Placeholder(_) | ty::UnnormalizedProjection(..) | ty::Bound(..)` might be unreachable here.
We may want to forbid `ty::Projection`, similar to `ty::Param`.
`ty::Opaque` seems fine afaict, should not be possible in a match atm.
I believe `ty::Foreign` should not be structurally match, as I don't even know what
that would actually mean.
r? @pnkfelix cc @eddyb
Shebang handling was too agressive in stripping out the first line in cases where it is actually _not_ a shebang, but instead, valid rust (#70528). This is a second attempt at resolving this issue (the first attempt was flawed, for, among other reasons, causing an ICE in certain cases (#71372, #71471).
The behavior is now codified by a number of UI tests, but simply:
For the first line to be a shebang, the following must all be true:
1. The line must start with `#!`
2. The line must contain a non whitespace character after `#!`
3. The next character in the file, ignoring comments & whitespace must not be `[`
I believe this is a strict superset of what we used to allow, so perhaps a crater run is unnecessary, but probably not a terrible idea.
First draft documenting Debug stability.
Debug implementations of std types aren't stable, and neither are derived Debug implementations for any types, including user-defined types. This commit adds a section to the Debug documentation noting this stability status.
This issue is tracked by #62794.
librustc_middle: Rename upvars query to upvars_mentioned
As part of supporting RFC 2229, we will be capturing all the Places that
were mentioned in the closure.
This commit modifies the name of the upvars query to upvars_mentioned.
r? @nikomatsakis @blitzerr @matthewjasper
Miri casts: do not blindly rely on dest type
Make sure that we notice when the MIR is bad and the casted-to and destination type are e.g. of different size, as suggested by @eddyb.
Add `len` and `slice_from_raw_parts` to `NonNull<[T]>`
This follows the precedent of the recently-added `<*const [T]>::len` (adding to its tracking issue https://github.com/rust-lang/rust/issues/71146) and `ptr::slice_from_raw_parts`.
Debug implementations of std types aren't stable, and neither are
derived Debug implementations for any types, including user-defined
types. This commit adds a section to the Debug documentatio noting this
stability status.
Store tokens inside `ast::Expr`
This is a smaller version of #70091.
We now store captured tokens inside `ast::Expr`, which allows us to avoid some reparsing in `nt_to_tokenstream`. To try to mitigate the performance impact, we only collect tokens when we've seen an outer attribute.
This makes progress towards solving #43081. There are still many things left to do:
* Collect tokens for other AST items.
* Come up with a way to handle inner attributes (we need to be collecting tokens by the time we encounter them)
* Avoid re-parsing when a `#[cfg]` attr is used.
However, this is enough to fix spans for a simple example, which I've included as a test case.
Rollup of 5 pull requests
Successful merges:
- #72402 (Remove all uses of `NodeId` in `ResolverOutputs`)
- #72527 (bootstrap: propagate test-args to miri and clippy test suites)
- #72530 (Clean up E0602 explanation)
- #72532 (Use `dyn` trait syntax in more comments and docs)
- #72535 (Use sort_unstable_by in its own docs)
Failed merges:
r? @ghost
As part of supporting RFC 2229, we will be capturing all the Places that
were mentioned in the closure.
This commit modifies the name of the upvars query to upvars_mentioned.
Co-authored-by: Aman Arora <me@aman-arora.com>
Co-authored-by: Chris Pardy <chrispardy36@gmail.com>
