rustc_target: Add a compatibility layer to separate internal and user-facing linker flavors
I want to do some refactorings in `rustc_target` - merge `lld_flavor` and `linker_is_gnu` into `linker_flavor`, support combination gcc+lld (https://github.com/rust-lang/rust/pull/96827).
This PR adds some compatibility infra that makes that possible without making any changes to user-facing interfaces - `-Clinker-flavor` values and json target specs. (For json target specs this infra may eventually go away since they are not very stable.)
The second commit does some light refactoring of internal linker flavors (applies changes from 53eca42973 that don't require mass-editing target specs).
Uplift the `let_underscore` lints from clippy into rustc.
This PR resolves#97241.
This PR adds three lints from clippy--`let_underscore_drop`, `let_underscore_lock`, and `let_underscore_must_use`, which are meant to capture likely-incorrect uses of `let _ = ...` bindings (in particular, doing this on a type with a non-trivial `Drop` causes the `Drop` to occur immediately, instead of at the end of the scope. For a type like `MutexGuard`, this effectively releases the lock immediately, which is almost certainly the wrong behavior)
In porting the lints from clippy I had to copy over a bunch of utility functions from `clippy_util` that these lints also relied upon. Is that the right approach?
Note that I've set the `must_use` and `drop` lints to Allow by default and set `lock` to Deny by default (this matches the same settings that clippy has). In talking with `@estebank` he informed me to do a Crater run (I am not sure what type of Crater run to request here--I think it's just "check only"?)
On the linked issue, there's some discussion about using `must_use` and `Drop` together as a heuristic for when to warn--I did not implement this yet.
r? `@estebank`
Simplify the `define_query` macro
This moves a bunch of control flow out of the macro into generic functions, leaving the macro just to call the function with a new generic parameter for each query.
It may be possible to improve compile-times / icache by instantiating the generic functions only with the query key, not the query type itself, but I'm going to leave that for a follow-up PR.
Helps with https://github.com/rust-lang/rust/issues/96524.
r? `@cjgillot`
- Parameterize DepKindStruct over `'tcx`
This allows passing in an invariant function pointer in `query_callback`,
rather than having to try and make it work for any lifetime.
- Add a new `execute_query` function to `QueryDescription` so we can call `tcx.$name` without needing to be in a macro context
`Builder::expr_into_pattern` has a single call site. Currently the
`pattern` argument at the call site is always cloned.
This commit changes things so that we instead do a clone within
`expr_into_pattern`, but only if the pattern has the
`PatKind::AscribeUserType` kind, and we only clone the annotation within
the pattern instead of the entire pattern.
`thir::Pat::kind` is a `Box<PatKind>`, which doesn't follow the usual
pattern in AST/HIR/THIR which is that the "kind" enum for a node is
stored inline within the parent struct.
This commit makes the `PatKind` directly inline within the `Pat`. This
requires using `Box<Pat>` in all the types that hold a `Pat.
Ideally, `Pat` would be stored in `Thir` like `Expr` and `Stmt` and
referred to with a `PatId` rather than `Box<Pat>`. But this is hard to
do because lots of `Pat`s get created after the destruction of the `Cx`
that does normal THIR building. But this does get us a step closer to
`PatId`, because all the `Box<Pat>` occurrences would be replaced with
`PatId` if `PatId` ever happened.
At 128 bytes, `Pat` is large. Subsequent commits will shrink it.
Add `special_module_name` lint
Declaring `lib` as a module is one of the most common beginner mistakes when trying to setup a binary and library target in the same crate. `special_module_name` lints against it, as well as `mod main;`
```
warning: found module declaration for main.rs
--> $DIR/special_module_name.rs:4:1
|
LL | mod main;
| ^^^^^^^^^
|
= note: a binary crate cannot be used as library
warning: found module declaration for lib.rs
--> $DIR/special_module_name.rs:1:1
|
LL | mod lib;
| ^^^^^^^^
|
= note: `#[warn(special_module_name)]` on by default
= note: lib.rs is the root of this crate's library target
= help: to refer to it from other targets, use the library's name as the path
```
Note that the help message is not the best in that it doesn't provide an example of an import path (`the_actual_crate_name::`), and doesn't check whether the current file is part of a library/binary target to provide more specific error messages. I'm not sure where this lint would have to be run to access that information.
Remove EntryKind from metadata.
This PR continues the refactor of metadata emission to be more systematic, iterating on definitions and filtering based on each definition's `DefKind`. This allows to remove the large `EntryKind` enum, replaced by linear tables in metadata.
This reimplements ac638c1, which had to be reverted in the previous
commit because it contains a rebase accident that itself reverted
significant unrelated changes to SessionSubdiagnostic.
This reverts parts of commit ac638c1f5f.
During rebase, this commit accidentally reverted unrelated changes to
the subdiagnostic derive (those allowing multipart_suggestions to be
derived). This commit reverts all changes to the subdiagnostic code made
in ac638c1f5f, the next commit will reintroduce the actually intended
changes.
compiler/rustc_codegen_ssa/src/mir/place.rs: Remove LLVM bug workaround
This memset was inserted as a workaround to Rust issue #34427, which was
an LLVM bug that apparently no longer manifests.
Replace `rustc_data_structures::thin_vec::ThinVec` with `thin_vec::ThinVec`
`rustc_data_structures::thin_vec::ThinVec` looks like this:
```
pub struct ThinVec<T>(Option<Box<Vec<T>>>);
```
It's just a zero word if the vector is empty, but requires two
allocations if it is non-empty. So it's only usable in cases where the
vector is empty most of the time.
This commit removes it in favour of `thin_vec::ThinVec`, which is also
word-sized, but stores the length and capacity in the same allocation as
the elements. It's good in a wider variety of situation, e.g. in enum
variants where the vector is usually/always non-empty.
The commit also:
- Sorts some `Cargo.toml` dependency lists, to make additions easier.
- Sorts some `use` item lists, to make additions easier.
- Changes `clean_trait_ref_with_bindings` to take a
`ThinVec<TypeBinding>` rather than a `&[TypeBinding]`, because this
avoid some unnecessary allocations.
r? `@spastorino`
Fix a bunch of typo
This PR will fix some typos detected by [typos].
I only picked the ones I was sure were spelling errors to fix, mostly in
the comments.
[typos]: https://github.com/crate-ci/typos
proc_macro/bridge: send diagnostics over the bridge as a struct
This removes some RPC when creating and emitting diagnostics, and
simplifies the bridge slightly.
After this change, there are no remaining methods which take advantage
of the support for `&mut` references to objects in the store as
arguments, meaning that support for them could technically be removed if
we wanted. The only remaining uses of immutable references into the
store are `TokenStream` and `SourceFile`.
r? `@eddyb`
lint: avoid linting diag functions with diag lints
Functions annotated with `#[rustc_lint_diagnostics]` are used by the diagnostic migration lints to know when to lint, but functions that are annotated with this attribute shouldn't themselves be linted.
cc #100717https://github.com/rust-lang/rust/pull/101041#discussion_r959303706
Fix uintended diagnostic caused by `drain(..)`
Calling `drain(..)` makes later `suggestable_variants.is_empty()` always true, which makes the diagnostics unintended.
migrate rustc_query_system to use SessionDiagnostic
issues:
* variable list is not supported in fluent
* ~~cannot have two sub diagnostic with the same tag (eg. 2 .note or 2 .help)~~
allow multiple tag with SessionSubdiagnostic derive
- ... when creating diagnostics in rustc_metadata
- use the error_code! macro
- pass macro output to diag.code()
- use fluent from within manual implementation of SessionDiagnostic
- emit the untested errors in case they occur in the wild
- stop panicking in the probably-not-dead code, add fixme to write test