This permits all coercions to be performed in casts, but adds lints to warn in those cases.
Part of this patch moves cast checking to a later stage of type checking. We acquire obligations to check casts as part of type checking where we previously checked them. Once we have type checked a function or module, then we check any cast obligations which have been acquired. That means we have more type information available to check casts (this was crucial to making coercions work properly in place of some casts), but it means that casts cannot feed input into type inference.
[breaking change]
* Adds two new lints for trivial casts and trivial numeric casts, these are warn by default, but can cause errors if you build with warnings as errors. Previously, trivial numeric casts and casts to trait objects were allowed.
* The unused casts lint has gone.
* Interactions between casting and type inference have changed in subtle ways. Two ways this might manifest are:
- You may need to 'direct' casts more with extra type information, for example, in some cases where `foo as _ as T` succeeded, you may now need to specify the type for `_`
- Casts do not influence inference of integer types. E.g., the following used to type check:
```
let x = 42;
let y = &x as *const u32;
```
Because the cast would inform inference that `x` must have type `u32`. This no longer applies and the compiler will fallback to `i32` for `x` and thus there will be a type error in the cast. The solution is to add more type information:
```
let x: u32 = 42;
let y = &x as *const u32;
```
* The lint visitor's visit_ty method did not recurse, and had a
reference to the now closed#10894
* The newly enabled recursion has only affected the `deprectated` lint
which now detects uses of deprecated items in trait impls and
function return types
* Renamed some references to `CowString` and `CowVec` to `Cow<str>` and
`Cow<[T]>`, respectively, which appear outside of the crate which
defines them
* Replaced a few instances of `InvariantType<T>` with
`PhantomData<Cell<T>>`
* Disabled the `deprecated` lint in several places that
reference/implement traits on deprecated items which will get cleaned
up in the future
* Disabled the `exceeding_bitshifts` lint for
compile-fail/huge-array-simple test so it doesn't shadow the expected
error on 32bit systems
* Unfortunately, this means that if a library declares
`#![deny(deprecated)]` and marks anything as deprecated, it will have
to disable the lint for any uses of said item, e.g. any impl the now
deprecated item
For any library that denies deprecated items but has deprecated items
of its own, this is a [breaking-change]
This pulls out the implementations of most built-in lints into a
separate crate, to reduce edit-compile-test iteration times with
librustc_lint and increase parallelism. This should enable lints to be
refactored, added and deleted much more easily as it slashes the
edit-compile cycle to get a minimal working compiler to test with (`make
rustc-stage1`) from
librustc -> librustc_typeck -> ... -> librustc_driver ->
libcore -> ... -> libstd
to
librustc_lint -> librustc_driver -> libcore -> ... libstd
which is significantly faster, mainly due to avoiding the librustc build
itself.
The intention would be to move as much as possible of the infrastructure
into the crate too, but the plumbing is deeply intertwined with librustc
itself at the moment. Also, there are lints for which diagnostics are
registered directly in the compiler code, not in their own crate
traversal, and their definitions have to remain in librustc.
This is a [breaking-change] for direct users of the compiler APIs:
callers of `rustc::session::build_session` or
`rustc::session::build_session_` need to manually call
`rustc_lint::register_builtins` on their return value.
This should make #22206 easier.
We were recording stability attributes applied to fields in the
compiler, and even annotating it in the libs, but the compiler didn't
actually do the checks to give errors/warnings in user crates.
aatch's cfg revisions, namely to match expressions
Revise handling of match expressions so that arms branch to next arm.
Update the graphviz tests accordingly.
Fixes#22073. (Includes regression test for the issue.)
This is not a complete implementation of the RFC:
- only existing methods got updated, no new ones added
- doc comments are not extensive enough yet
- optimizations got lost and need to be reimplemented
See https://github.com/rust-lang/rfcs/pull/528
Technically a
[breaking-change]
This allows warning or forbidding all uses of unsafe code, whereas
previously only unsafe blocks were caught by the lint.
The lint has been renamed from `unsafe-blocks` to `unsafe-code` to
reflect its new purpose.
This is a minor [breaking-change]
Closes#22430
Checks include declaration/implementation of unsafe functions, traits,
and methods.
This allows warning or forbidding all uses of unsafe code, whereas
previously only unsafe blocks were caught by the lint.
The lint has been renamed from `unsafe-blocks` to `unsafe-code` to
reflect its new purpose.
This is a minor [breaking-change]
Closes#22430
This commit is an implementation of [RFC 823][rfc] which is another pass over
the `std::hash` module for stabilization. The contents of the module were not
entirely marked stable, but some portions which remained quite similar to the
previous incarnation are now marked `#[stable]`. Specifically:
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0823-hash-simplification.md
* `std::hash` is now stable (the name)
* `Hash` is now stable
* `Hash::hash` is now stable
* `Hasher` is now stable
* `SipHasher` is now stable
* `SipHasher::new` and `new_with_keys` are now stable
* `Hasher for SipHasher` is now stable
* Many `Hash` implementations are now stable
All other portions of the `hash` module remain `#[unstable]` as they are less
commonly used and were recently redesigned.
This commit is a breaking change due to the modifications to the `std::hash` API
and more details can be found on the [RFC][rfc].
Closes#22467
[breaking-change]
* Move the type parameter on the `AsciiExt` trait to an associated type named
`Owned`.
* Move `ascii::escape_default` to using an iterator.
This is a breaking change due to the removal of the type parameter on the
`AsciiExt` trait as well as the modifications to the `escape_default` function
to returning an iterator. Manual implementations of `AsciiExt` (or `AsciiExt`
bounds) should be adjusted to remove the type parameter and using the new
`escape_default` should be relatively straightforward.
[breaking-change]
Previously an implementation of a stable trait allows implementations of
unstable methods. This updates the stability pass to ensure that all items of an
impl block of a trait are indeed stable on the trait itself.
Add `#[rustc_error]` annotation, which causes trans to signal an error
if found on the `main()` function. This lets you write tests that live
in `compile-fail` but are expected to compile successfully. This is
handy when you have many small variations on a theme that you want to
keep together, and you are just testing the type checker, not the
runtime semantics.
r? @pnkfelix
if found on the `main()` function. This lets you write tests that live
in `compile-fail` but are expected to compile successfully. This is
handy when you have many small variations on a theme that you want to
keep together, and you are just testing the type checker, not the
runtime semantics.
There are a number of holes that the stability lint did not previously cover,
including:
* Types
* Bounds on type parameters on functions and impls
* Where clauses
* Imports
* Patterns (structs and enums)
These holes have all been fixed by overriding the `visit_path` function on the
AST visitor instead of a few specialized cases. This change also necessitated a
few stability changes:
* The `collections::fmt` module is now stable (it was already supposed to be).
* The `thread_local:👿:Key` type is now stable (it was already supposed to
be).
* The `std::rt::{begin_unwind, begin_unwind_fmt}` functions are now stable.
These are required via the `panic!` macro.
* The `std::old_io::stdio::{println, println_args}` functions are now stable.
These are required by the `print!` and `println!` macros.
* The `ops::{FnOnce, FnMut, Fn}` traits are now `#[stable]`. This is required to
make bounds with these traits stable. Note that manual implementations of
these traits are still gated by default, this stability only allows bounds
such as `F: FnOnce()`.
Closes#8962Closes#16360Closes#20327
This renames the PrivateNoMangleFns lint to allow both to happen in a
single pass, since they do roughly the same work.
Closes#21856
Open questions:
[ ]: Do the tests actually pass (I'm running make check and running out the door now)
[ ]: Is the name of this lint ok. it seems to mostly be fine with [convention](cc53afbe5d/text/0344-conventions-galore.md (lints))
[ ]: I'm not super thrilled about the warning text
r? @kmcallister (Shamelessly nominating because you were looking at my other ticket)
