Individualize feature gates for const fn invocation
This PR changes the meaning of `#![feature(const_fn)]` so it is only required to declare a const fn but not to call one. Based on discussion at #24111. I was hoping we could have an FCP here in order to move that conversation forward.
This sets the stage for future stabilization of the constness of several functions in the standard library (listed below), so could someone please tag the lang team for review.
- `std::cell`
- `Cell::new`
- `RefCell::new`
- `UnsafeCell::new`
- `std::mem`
- `size_of`
- `align_of`
- `std::ptr`
- `null`
- `null_mut`
- `std::sync`
- `atomic`
- `Atomic{Bool,Ptr,Isize,Usize}::new`
- `once`
- `Once::new`
- primitives
- `{integer}::min_value`
- `{integer}::max_value`
Some other functions are const but they are also unstable or hidden, e.g. `Unique::new` so they don't have to be considered at this time.
After this stabilization, the following `*_INIT` constants in the standard library can be deprecated. I wasn't sure whether to include those deprecations in the current PR.
- `std::sync`
- `atomic`
- `ATOMIC_{BOOL,ISIZE,USIZE}_INIT`
- `once`
- `ONCE_INIT`
Extend E0623 for fn items
This fixes#44516
The below example now gives
```
error[E0623]: lifetime mismatch
--> gg.rs:3:10
|
2 | fn foo(x:fn(&u8, &u8), y: Vec<&u8>, z: &u8) {
| --- --- these two types are declared with different lifetimes...
3 | y.push(z);
| ^ ...but data from `z` flows into `y` here
error: aborting due to previous error
```
r? @nikomatsakis
cc @arielb1
Fix mispositioned error indicators
Fixes#38384
Most of the Rust community uses 4 spaces for indentation,
but there are also tab users of Rust (including myself!).
This patch fixes a bug in error printing which mispositions
error indicators when near code with tabs.
The code attempted to fix the issue by replacing spaces
with tabs, but it sadly wasn't enough, as sometimes
you may not print spaces but _ or ^ instead.
This patch employs the reverse strategy: it replaces each
tab with a space, so that the number of _ and ^ and spaces
in error indicators below the code snippet line up
perfectly.
In a study [1] preceeding this patch, we could see that
this strategy is also chosen by gcc version 6.3.0.
Its not perfect, as the output is not beautiful, but its
the easiest to implement. If anyone wants to improve on
this, be my guest! This patch is meant as improvement of
the status quo, not as perfect end status. It fixes the
actual issue of mispositioning error indicators.
[1]: https://github.com/rust-lang/rust/issues/38384#issuecomment-326813710
Extend E0623 for LateBound and EarlyBound Regions
This is a fix for #43882
```
fn foo<'a,'b>(x: &mut Vec<&'a u8>, y: &'b u8) {
x.push(y);
}
```
now gives
```
error[E0623]: lifetime mismatch
--> $DIR/ex3-both-anon-regions-latebound-regions.rs:12:12
|
11 | fn foo<'a,'b>(x: &mut Vec<&'a u8>, y: &'b u8) {
| ------ ------ these two types are declared with different lifetimes...
12 | x.push(y);
| ^ ...but data from `y` flows into `x` here
```
cc @nikomatsakis @arielb1
Please ignore the second commit. It will be merged in a separate PR.
Allow Drop types in const's too, with #![feature(drop_types_in_const)].
Implements the remaining amendment, see #33156. cc @SergioBenitez
r? @nikomatsakis
Fixes#38384
Most of the Rust community uses 4 spaces for indentation,
but there are also tab users of Rust (including myself!).
This patch fixes a bug in error printing which mispositions
error indicators when near code with tabs.
The code attempted to fix the issue by replacing spaces
with tabs, but it sadly wasn't enough, as sometimes
you may not print spaces but _ or ^ instead.
This patch employs the reverse strategy: it replaces each
tab with a space, so that the number of _ and ^ and spaces
in error indicators below the code snippet line up
perfectly.
In a study [1] preceeding this patch, we could see that
this strategy is also chosen by gcc version 6.3.0.
Its not perfect, as the output is not beautiful, but its
the easiest to implement. If anyone wants to improve on
this, be my guest! This patch is meant as improvement of
the status quo, not as perfect end status. It fixes the
actual issue of mispositioning error indicators.
[1]: https://github.com/rust-lang/rust/issues/38384#issuecomment-326813710
rustc: Remove the `used_unsafe` field on TyCtxt
Now that lint levels are available for the entire compilation, this can be an
entirely local lint in `effect.rs`
cc #44137
add a lowercase suggestion to unknown_lints
I recently wrote some tests for a clippy lint, copied the (uppercase) lint name into my test file and forgot to toggle the case. This PR adds a suggestion that would have saved me 10 minutes of debugging, so it's likely a net win 🙂 . Also it adds a UI test for the `unknown_lints` lint.
Remove the trait selection impl in method::probe
This removes the hacky trait selection reimplementation in `method::probe`, which occasionally comes and causes problems.
There are 2 issues I've found with this approach:
1. The older implementation sometimes had a "guess" type from an impl, which allowed subtyping to work. This is why I needed to make a change in `libtest`: there's an `impl<A> Clone for fn(A)` and we're calling `<for<'a> fn(&'a T) as Clone>::clone`. The older implementation would do a subtyping between the impl type and the trait type, so it would do the check for `<fn(A) as Clone>::clone`, and confirmation would continue with the subtyping. The newer implementation directly passes `<for<'a> fn(&'a T) as Clone>::clone` to selection, which fails. I'm not sure how big of a problem that would be in reality, especially after #43690 would remove the `Clone` problem, but I still want a crater run to avoid breaking the world.
2. The older implementation "looked into" impls to display error messages. I'm not sure that's an advantage - it looked exactly 1 level deep.
r? @eddyb
feature error span on attribute for fn_must_use, SIMD/align reprs, macro reëxport
There were several feature-gated attributes for which the feature-not-available
error spans would point to the item annotated with the gated attribute, when it
would make more sense for the span to point to the attribute itself: if the
attribute is removed, the function/struct/_&c._ likely still makes sense and the
program will compile. (Note that we decline to make the analogous change for
the `main`, `start`, and `plugin_registrar` features, for in those cases it
makes sense for the span to implicate the entire function, of which there is
little hope of using without the gated attribute.)
There were several feature-gated attributes for which the
feature-not-available error spans would point to the item annotated with
the gated attribute, when it would make more sense for the span to point
to the attribute itself: if the attribute is removed, the
function/struct/&c. likely still makes sense and the program will
compile. (Note that we decline to make the analogous change for the
`main`, `start`, and `plugin_registrar` features, for in those cases it
makes sense for the span to implicate the entire function, of which
there is little hope of using without the gated attribute.)
Fix a byte/char confusion issue in the error emitter
Fixes#44078. Fixes#44023.
The start_col member is given in chars, while the code previously assumed it was given in bytes.
The more basic issue #44080 doesn't get fixed.
Fixes#44078. Fixes#44023.
The start_col member is given in chars,
while the code previously assumed it was given in bytes.
The more basic issue #44080 doesn't get fixed.
Adding E0623 for structs
This is a fix to #43275
The error message is
```
+error[E0623]: lifetime mismatch
+ --> $DIR/ex3-both-anon-regions-both-are-structs.rs:15:12
+ |
+14 | fn foo(mut x: Vec<Ref>, y: Ref) {
+ | --- --- these structs are declared with different lifetimes...
+15 | x.push(y);
+ | ^ ...but data from `y` flows into `x` here
+
+error: aborting due to previous error
```
r? @nikomatsakis
We'll actually want a new "soft" warning-only gate to maintain
backwards-compatibility, but it's cleaner to start out with the established,
well-understood gate before implementing the alternative warn-only behavior in
a later commit.
This is in the matter of #43302.
