| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
This will allow us to eagerly translate messages on a top-level
diagnostic, such as a `LintDiagnostic`. As a bonus, we can remove the
awkward closure passed into Subdiagnostic and make better use of
`Into`.
|
|
|
|
Uplift `clippy::invalid_null_ptr_usage` lint as `invalid_null_arguments`
This PR aims at uplifting the `clippy::invalid_null_ptr_usage` lint into rustc, this is similar to the [`clippy::invalid_utf8_in_unchecked` uplift](https://github.com/rust-lang/rust/pull/111543) a few months ago, in the sense that those two lints lint on invalid parameter(s), here a null pointer where it is unexpected and UB to pass one.
*For context: GitHub Search reveals that just for `slice::from_raw_parts{_mut}` [~20 invalid usages](hhttps://github.com/search?q=lang%3Arust+%2Fslice%3A%3Afrom_raw_parts%28_mut%29%3F%5C%28ptr%3A%3Anull%2F+NOT+path%3A%2F%5Eclippy_lints%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Erust%5C%2Fsrc%5C%2Ftools%5C%2Fclippy%5C%2Fclippy_lints%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Esrc%5C%2Ftools%5C%2Fclippy%5C%2Fclippy_lints%5C%2Fsrc%5C%2F%2F&type=code) with `ptr::null` and an additional [4 invalid usages](https://github.com/search?q=lang%3Arust+%2Fslice%3A%3Afrom_raw_parts%5C%280%28%5C%29%7C+as%29%2F+NOT+path%3A%2F%5Eclippy_lints%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Erust%5C%2Fsrc%5C%2Ftools%5C%2Fclippy%5C%2Fclippy_lints%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Esrc%5C%2Ftools%5C%2Fclippy%5C%2Fclippy_lints%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Eutils%5C%2Ftinystr%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Eutils%5C%2Fzerovec%5C%2Fsrc%5C%2F%2F+NOT+path%3A%2F%5Eprovider%5C%2Fcore%5C%2Fsrc%5C%2F%2F&type=code) with `0 as *const ...`-ish casts.*
-----
## `invalid_null_arguments`
(deny-by-default)
The `invalid_null_arguments` lint checks for invalid usage of null pointers.
### Example
```rust
// Undefined behavior
unsafe { std::slice::from_raw_parts(ptr::null(), 1); }
```
Produces:
```
error: calling this function with a null pointer is Undefined Behavior, even if the result of the function is unused
--> $DIR/invalid_null_args.rs:21:23
|
LL | let _: &[usize] = std::slice::from_raw_parts(ptr::null_mut(), 0);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^---------------^^^^
| |
| null pointer originates from here
|
= help: for more information, visit <https://doc.rust-lang.org/std/ptr/index.html> and <https://doc.rust-lang.org/reference/behavior-considered-undefined.html>
```
### Explanation
Calling methods whose safety invariants requires non-null pointer with a null pointer is undefined behavior.
-----
The lint use a list of functions to know which functions and arguments to checks, this could be improved in the future with a rustc attribute, or maybe even with a `#[diagnostic]` attribute.
This PR also includes some small refactoring to avoid some ambiguities in naming, those can be done in another PR is desired.
`@rustbot` label: +I-lang-nominated
r? compiler
|
|
|
|
|
|
crates
|
|
|
|
```
warning: cannot find macro `in_root` in the crate root
--> $DIR/key-value-expansion-scope.rs:1:10
|
LL | #![doc = in_root!()]
| ^^^^^^^ not found in the crate root
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #124535 <https://github.com/rust-lang/rust/issues/124535>
= help: import `macro_rules` with `use` to make it callable above its definition
= note: `#[warn(out_of_scope_macro_calls)]` on by default
```
|
|
Most of these just format the ABI string, so... just format ExternAbi?
This makes it more consistent and less jank when we can do it.
|
|
Use identifiers more in diagnostics code
This should make the diagnostics code slightly more correct when rendering idents in mixed crate edition situations. Kinda a no-op, but a cleanup regardless.
r? oli-obk or reassign
|
|
|
|
|
|
Make the wasm_c_abi future compat warning a hard error
This is the next step in getting rid of the broken C abi for wasm32-unknown-unknown.
The lint was made deny-by-default in https://github.com/rust-lang/rust/pull/129534 3 months ago. This still keeps the `-Zwasm-c-abi` flag set to `legacy` by default. It will be flipped in a future PR.
cc https://github.com/rust-lang/rust/issues/122532
|
|
remove long-deprecated no-op attributes no_start and crate_id
These have emitted a deprecation warning since forever (https://github.com/rust-lang/rust/pull/64471) and they already don't do anything. In fact they [apparently](https://github.com/rust-lang/rust/pull/64471#issuecomment-531517332) have done nothing since pre-1.0, so... do we even need a crater run? Doesn't seem worth it.
|
|
r=compiler-errors
Forbid usage of `hir` `Infer` const/ty variants in ambiguous contexts
The feature `generic_arg_infer` allows providing `_` as an argument to const generics in order to infer them. This introduces a syntactic ambiguity as to whether generic arguments are type or const arguments. In order to get around this we introduced a fourth `GenericArg` variant, `Infer` used to represent `_` as an argument to generic parameters when we don't know if its a type or a const argument.
This made hir visitors that care about `TyKind::Infer` or `ConstArgKind::Infer` very error prone as checking for `TyKind::Infer`s in `visit_ty` would find *some* type infer arguments but not *all* of them as they would sometimes be lowered to `GenericArg::Infer` instead.
Additionally the `visit_infer` method would previously only visit `GenericArg::Infer` not *all* infers (e.g. `TyKind::Infer`), this made it very easy to override `visit_infer` and expect it to visit all infers when in reality it would only visit *some* infers.
---
This PR aims to fix those issues by making the `TyKind` and `ConstArgKind` types generic over whether the infer types/consts are represented by `Ty/ConstArgKind::Infer` or out of line (e.g. by a `GenericArg::Infer` or accessible by overiding `visit_infer`). We then make HIR Visitors convert all const args and types to the versions where infer vars are stored out of line and call `visit_infer` in cases where a `Ty`/`Const` would previously have had a `Ty/ConstArgKind::Infer` variant:
API Summary
```rust
enum AmbigArg {}
enum Ty/ConstArgKind<Unambig = ()> {
...
Infer(Unambig),
}
impl Ty/ConstArg {
fn try_as_ambig_ty/ct(self) -> Option<Ty/ConstArg<AmbigArg>>;
}
impl Ty/ConstArg<AmbigArg> {
fn as_unambig_ty/ct(self) -> Ty/ConstArg;
}
enum InferKind {
Ty(Ty),
Const(ConstArg),
Ambig(InferArg),
}
trait Visitor {
...
fn visit_ty/const_arg(&mut self, Ty/ConstArg<AmbigArg>) -> Self::Result;
fn visit_infer(&mut self, id: HirId, sp: Span, kind: InferKind) -> Self::Result;
}
// blanket impl'd, not meant to be overriden
trait VisitorExt {
fn visit_ty/const_arg_unambig(&mut self, Ty/ConstArg) -> Self::Result;
}
fn walk_unambig_ty/const_arg(&mut V, Ty/ConstArg) -> Self::Result;
fn walk_ty/const_arg(&mut V, Ty/ConstArg<AmbigArg>) -> Self::Result;
```
The end result is that `visit_infer` visits *all* infer args and is also the *only* way to visit an infer arg, `visit_ty` and `visit_const_arg` can now no longer encounter a `Ty/ConstArgKind::Infer`. Representing this in the type system means that it is now very difficult to mess things up, either accessing `TyKind::Infer` "just works" and you won't miss *some* type infers- or it doesn't work and you have to look at `visit_infer` or some `GenericArg::Infer` which forces you to think about the full complexity involved.
Unfortunately there is no lint right now about explicitly matching on uninhabited variants, I can't find the context for why this is the case :woman_shrugging:
I'm not convinced the framing of un/ambig ty/consts is necessarily the right one but I'm not sure what would be better. I somewhat like calling them full/partial types based on the fact that `Ty<Partial>`/`Ty<Full>` directly specifies how many of the type kinds are actually represented compared to `Ty<Ambig>` which which leaves that to the reader to figure out based on the logical consequences of it the type being in an ambiguous position.
---
tool changes have been modified in their own commits for easier reviewing by anyone getting cc'd from subtree changes. I also attempted to split out "bug fixes arising from the refactoring" into their own commit so they arent lumped in with a big general refactor commit
Fixes #112110
|
|
This is the next step in getting rid of the broken C abi for
wasm32-unknown-unknown.
|
|
amy-kwan:amy-kwan/reprc-struct-diagnostic-power-alignment, r=workingjubilee
[AIX] Lint on structs that have a different alignment in AIX's C ABI
This PR adds a linting diagnostic on AIX for repr(C) structs that are required to follow
the power alignment rule. A repr(C) struct needs to follow the power alignment rule if
the struct:
- Has a floating-point data type (greater than 4-bytes) as its first member, or
- The first member of the struct is an aggregate, whose recursively first member is a
floating-point data type (greater than 4-bytes).
The power alignment rule for eligible structs is currently unimplemented, so a linting
diagnostic is produced when such a struct is encountered.
|
|
|
|
|
|
Edit dangling pointers
Closes: #132283
|
|
|
|
|
|
`rustc_span::symbol` defines some things that are re-exported from
`rustc_span`, such as `Symbol` and `sym`. But it doesn't re-export some
closely related things such as `Ident` and `kw`. So you can do `use
rustc_span::{Symbol, sym}` but you have to do `use
rustc_span::symbol::{Ident, kw}`, which is inconsistent for no good
reason.
This commit re-exports `Ident`, `kw`, and `MacroRulesNormalizedIdent`,
and changes many `rustc_span::symbol::` qualifiers in `compiler/` to
`rustc_span::`. This is a 200+ net line of code reduction, mostly
because many files with two `use rustc_span` items can be reduced to
one.
|
|
Remove `rustc::existing_doc_keyword` lint
The check doesn't require a lint.
r? ``@GuillaumeGomez``
|
|
`CheckAttrVisitor::check_doc_keyword` checks `#[doc(keyword = "..")]`
attributes to ensure they are on an empty module, and that the value is
a non-empty identifier.
The `rustc::existing_doc_keyword` lint checks these attributes to ensure
that the value is the name of a keyword.
It's silly to have two different checking mechanisms for these
attributes. This commit does the following.
- Changes `check_doc_keyword` to check that the value is the name of a
keyword (avoiding the need for the identifier check, which removes a
dependency on `rustc_lexer`).
- Removes the lint.
- Updates tests accordingly.
There is one hack: the `SelfTy` FIXME case used to used to be handled by
disabling the lint, but now is handled with a special case in
`is_doc_keyword`. That hack will go away if/when the FIXME is fixed.
Co-Authored-By: Guillaume Gomez <guillaume1.gomez@gmail.com>
|
|
|
|
|
|
Add external macros specific diagnostics for check-cfg
This PR adds specific check-cfg diagnostics for unexpected cfg in external macros.
As well as hiding the some of the Cargo specific help/suggestions as they distraction for external macros and are generally not the right solution.
Follow-up to #132577
`@rustbot` label +L-unexpected_cfgs
r? compiler
|
|
Revert <https://github.com/rust-lang/rust/pull/131669> due to ICE
reports:
- <https://github.com/rust-lang/rust/issues/134059> (real-world)
- <https://github.com/rust-lang/rust/issues/134060> (fuzzing)
The changes can be re-landed with those cases addressed.
This reverts commit 703bb982303ecab02fec593899639b4c3faecddd, reversing
changes made to f415c07494b98e4559e4b13a9c5f867b0e6b2444.
|
|
help messages
|
|
Co-authored-by: Urgau <3616612+Urgau@users.noreply.github.com>
|
|
|
|
Add lint against function pointer comparisons
This is kind of a follow-up to https://github.com/rust-lang/rust/pull/117758 where we added a lint against wide pointer comparisons for being ambiguous and unreliable; well function pointer comparisons are also unreliable. We should IMO follow a similar logic and warn people about it.
-----
## `unpredictable_function_pointer_comparisons`
*warn-by-default*
The `unpredictable_function_pointer_comparisons` lint checks comparison of function pointer as the operands.
### Example
```rust
fn foo() {}
let a = foo as fn();
let _ = a == foo;
```
### Explanation
Function pointers comparisons do not produce meaningful result since they are never guaranteed to be unique and could vary between different code generation units. Furthermore different function could have the same address after being merged together.
----
This PR also uplift the very similar `clippy::fn_address_comparisons` lint, which only linted on if one of the operand was an `ty::FnDef` while this PR lints proposes to lint on all `ty::FnPtr` and `ty::FnDef`.
```@rustbot``` labels +I-lang-nominated
~~Edit: Blocked on https://github.com/rust-lang/libs-team/issues/323 being accepted and it's follow-up pr~~
|
|
Lint against Symbol::intern on a string literal
Disabled in tests where this doesn't make much sense
|
|
|
|
|
|
fix confusing diagnostic for reserved `##`
Closes #131615
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Make deprecated_cfg_attr_crate_type_name a hard error
Turns the forward compatibility lint added by #83744 into a hard error, so now, while the `#![crate_name]` and `#![crate_type]` attributes are still allowed in raw form, they are now forbidden to be nested inside a `#![cfg_attr()]` attribute.
The following will now be an error:
```Rust
#![cfg_attr(foo, crate_name = "foobar")]
#![cfg_attr(foo, crate_type = "bin")]
```
This code will continue working and is not deprecated:
```Rust
#![crate_name = "foobar"]
#![crate_type = "lib"]
```
The reasoning for this is explained in #83744: it allows us to not have to cfg-expand in order to determine the crate's type and name.
As of filing the PR, exactly two years have passed since #99784 has been merged, which has turned the lint's default warning level into an error, so there has been ample time to move off the now-forbidden syntax.
cc #91632 - tracking issue for the lint
|
|
|
|
Stabilize `const_float_classify`
Tracking issue: https://github.com/rust-lang/rust/issues/72505
Also reverts https://github.com/rust-lang/rust/pull/114486
Closes https://github.com/rust-lang/rust/issues/72505
Stabilized const API:
```rust
impl f32 {
pub const fn is_nan(self) -> bool;
pub const fn is_infinite(self) -> bool;
pub const fn is_finite(self) -> bool;
pub const fn is_subnormal(self) -> bool;
pub const fn is_normal(self) -> bool;
pub const fn classify(self) -> FpCategory;
pub const fn is_sign_positive(self) -> bool;
pub const fn is_sign_negative(self) -> bool;
}
impl f64 {
pub const fn is_nan(self) -> bool;
pub const fn is_infinite(self) -> bool;
pub const fn is_finite(self) -> bool;
pub const fn is_subnormal(self) -> bool;
pub const fn is_normal(self) -> bool;
pub const fn classify(self) -> FpCategory;
pub const fn is_sign_positive(self) -> bool;
pub const fn is_sign_negative(self) -> bool;
}
```
cc `@rust-lang/wg-const-eval` `@rust-lang/libs-api`
|
|
Reverts PR https://github.com/rust-lang/rust/pull/114486 (commit 1305a43d0a0c02cb224ab626745bd94af59c6098)
|
