dropck: must assume `Box<Trait + 'a>` has a destructor of interest.
Fix#25199.
This detail was documented in [RFC 769]; the implementation was just missing.
[breaking-change]
The breakage here falls into both obvious and non-obvious cases.
The obvious case: if you were relying on the unsoundness this exposes (namely being able to reference dead storage from a destructor, by doing it via a boxed trait object bounded by the lifetime of the dead storage), then this change disallows that.
The non-obvious cases: The way dropck works, it causes lifetimes to be extended to longer extents than they covered before. I.e. lifetimes that are attached as trait-bounds may become longer than they were previously.
* This includes lifetimes that are only *implicitly* attached as trait-bounds (due to [RFC 599]). So you may have code that was e.g. taking a parameter of type `&'a Box<Trait>` (which expands to `&'a Box<Trait+'a>`), that now may need to be assigned type `&'a Box<Trait+'static>` to ensure that `'a` is not inadvertantly inferred to a region that is actually too long. (See commit ee06263 for an example of this.)
[RFC 769]: https://github.com/rust-lang/rfcs/blob/master/text/0769-sound-generic-drop.md#the-drop-check-rule
[RFC 599]: https://github.com/rust-lang/rfcs/blob/master/text/0599-default-object-bound.md
Implements this (previously overlooked) note from [RFC 769]:
> (Note: When encountering a D of the form `Box<Trait+'b>`, we
> conservatively assume that such a type has a Drop implementation
> parametric in 'b.)
Fix#25199.
[breaking-change]
The breakage here falls into both obvious and non-obvious cases.
The obvious case: if you were relying on the unsoundness this exposes
(namely being able to reference dead storage from a destructor, by
doing it via a boxed trait object bounded by the lifetime of the dead
storage), then this change disallows that.
The non-obvious cases: The way dropck works, it causes lifetimes to be
extended to longer extents than they covered before. I.e. lifetimes
that are attached as trait-bounds may become longer than they were
previously.
* This includes lifetimes that are only *implicitly* attached as
trait-bounds (due to [RFC 599]). So you may have code that was
e.g. taking a parameter of type `&'a Box<Trait>` (which expands to
`&'a Box<Trait+'a>`), that now may need to be assigned type `&'a
Box<Trait+'static>` to ensure that `'a` is not inadvertantly
inferred to a region that is actually too long. (See earlier commit
in this PR for an example of this.)
[RFC 769]: https://github.com/rust-lang/rfcs/blob/master/text/0769-sound-generic-drop.md#the-drop-check-rule
[RFC 599]: https://github.com/rust-lang/rfcs/blob/master/text/0599-default-object-bound.md
typeck: Make sure casts from other types to fat pointers are illegal
Fixes ICEs where non-fat pointers and scalars are cast to fat pointers,
Fixes#21397Fixes#22955Fixes#23237Fixes#24100
Hi! While researching stuff for the reference and the grammar, I came across a few mentions of using the `priv` keyword that was removed in 0.11.0 (#13547, #8122, rust-lang/rfcs#26, [RFC 0026](https://github.com/rust-lang/rfcs/blob/master/text/0026-remove-priv.md)).
One occurrence is a mention in the reference, a few are in comments, and a few are marking test functions. I left the test that makes sure you can't name an ident `priv` since it's still a reserved keyword. I did a little grepping around for `priv `, priv in backticks, `Private` etc and I think the remaining instances are fine, but if anyone knows anywhere in particular I should check for any other lingering mentions of `priv`, please let me know and I would be happy to! 🍂🌊
This uses a (per-trait) hash-table to separate impls from different TraitDefs, and makes coherence go so much quicker. I will post performance numbers tomorrow.
This is still WIP, as when there's an overlap error, impls can get printed in the wrong order, which causes a few issues. Should I pick the local impl with the smallest NodeId to print?
Could you take a look at this @nikomatsakis?
Puts implementations in bins hashed by the fast-reject key, and
only looks up the relevant impls, reducing O(n^2)-ishness
Before: 688.92user 5.08system 8:56.70elapsed 129%CPU (0avgtext+0avgdata 1208164maxresident)k, LLVM 379.142s
After: 637.78user 5.11system 8:17.48elapsed 129%CPU (0avgtext+0avgdata 1201448maxresident)k LLVM 375.552s
Performance increase is +7%-ish
The former stopped making sense when we started interning substs and made
TraitRef a 2-word copy type, and I'm moving the latter into an arena as
they live as long as the type context.
I've been working on improving the diagnostic registration system so that it can:
* Check uniqueness of error codes *across the whole compiler*. The current method using `errorck.py` is prone to failure as it relies on simple text search - I found that it breaks when referencing an error's ident within a string (e.g. `"See also E0303"`).
* Provide JSON output of error metadata, to eventually facilitate HTML output, as well as tracking of which errors need descriptions. The current schema is:
```
<error code>: {
"description": <long description>,
"use_site": {
"filename": <filename where error is used>,
"line": <line in file where error is used>
}
}
```
[Here's][metadata-dump] a pretty-printed sample dump for `librustc`.
One thing to note is that I had to move the diagnostics arrays out of the diagnostics modules. I really wanted to be able to capture error usage information, which only becomes available as a crate is compiled. Hence all invocations of `__build_diagnostics_array!` have been moved to the ends of their respective `lib.rs` files. I tried to avoid moving the array by making a plugin that expands to nothing but couldn't invoke it in item position and gave up on hackily generating a fake item. I also briefly considered using a lint, but it seemed like it would impossible to get access to the data stored in the thread-local storage.
The next step will be to generate a web page that lists each error with its rendered description and use site. Simple mapping and filtering of the metadata files also allows us to work out which error numbers are absent, which errors are unused and which need descriptions.
[metadata-dump]: https://gist.github.com/michaelsproul/3246846ff1bea71bd049
These are useful when you want to catch the signals, like when you're making a kernel, or if you just don't want the overhead. (I don't know if there are any of the second kind of people, I don't think it's a good idea, but hey, choice is good).
[breaking-change]
What does this break? Basically, code that implements `Drop` and is
using `T:Copy` for one of its type parameters and is relying on the
Drop Check rule not applying to it.
Here is an example:
```rust
#![allow(dead_code,unused_variables,unused_assignments)]
struct D<T:Copy>(T);
impl<T:Copy> Drop for D<T> { fn drop(&mut self) { } }
trait UserT { fn c(&self) { } }
impl<T:Copy> UserT for T { }
struct E<T:UserT>(T);
impl<T:UserT> Drop for E<T> { fn drop(&mut self) { } }
// This one will start breaking.
fn foo() { let (d2, d1); d1 = D(34); d2 = D(&d1); }
#[cfg(this_one_does_and_should_always_break)]
fn bar() { let (e2, e1); e1 = E(34); e2 = E(&e1); }
fn main() {
foo();
}
```
Closes#17841.
The majority of the work should be done, e.g. trait and inherent impls, different forms of UFCS syntax, defaults, and cross-crate usage. It's probably enough to replace the constants in `f32`, `i8`, and so on, or close to good enough.
There is still some significant functionality missing from this commit:
- ~~Associated consts can't be used in match patterns at all. This is simply because I haven't updated the relevant bits in the parser or `resolve`, but it's *probably* not hard to get working.~~
- Since you can't select an impl for trait-associated consts until partway through type-checking, there are some problems with code that assumes that you can check constants earlier. Associated consts that are not in inherent impls cause ICEs if you try to use them in array sizes or match ranges. For similar reasons, `check_static_recursion` doesn't check them properly, so the stack goes ka-blooey if you use an associated constant that's recursively defined. That's a bit trickier to solve; I'm not entirely sure what the best approach is yet.
- Dealing with consts associated with type parameters will raise some new issues (e.g. if you have a `T: Int` type parameter and want to use `<T>::ZERO`). See rust-lang/rfcs#865.
- ~~Unused associated consts don't seem to trigger the `dead_code` lint when they should. Probably easy to fix.~~
Also, this is the first time I've been spelunking in rustc to such a large extent, so I've probably done some silly things in a couple of places.
An actual typeck error is the cause of many failed compilations but an
unrelated bug is being reported instead. It is triggered because a typeck
error is presumably not yet identified during compiler execution, which
would normally bypass an invariant in the presence of other errors. In
this particular situation, we delay the reporting of the bug until
abort_if_errors().
Closes#23827, closes#24356, closes#23041, closes#22897, closes#23966,
closes#24013, and closes#23729
**There is at least one situation where this bug may still be genuinely
triggered (#23437).**
These new intrinsics are comparable to `atomic_signal_fence` in C++,
ensuring the compiler will not reorder memory accesses across the
barrier, nor will it emit any machine instructions for it.
Closes#24118, implementing RFC 888.
Rather than storing the relations between free-regions in a global
table, introduce a `FreeRegionMap` data structure. regionck computes the
`FreeRegionMap` for each fn and stores the result into the tcx so that
borrowck can use it (this could perhaps be refactored to have borrowck
recompute the map, but it's a bid tedious to recompute due to the
interaction of closures and free fns). The main reason to do this is
because of #22779 -- using a global table was incorrect because when
validating impl method signatures, we want to use the free region
relationships from the *trait*, not the impl.
Fixes#22779.
PR #24242 added the ability to the compiler to directly give suggestions about
how to modify code to fix an error. The new errors look like this:
foobar.rs:5:12: 5:25 error: expected a path on the left-hand side of `+`,
not `&'static Copy` [E0178]
foobar.rs:5 let x: &'static Copy + 'static;
^~~~~~~~~~~~~
foobar.rs:5:12: 5:35 help: try adding parentheses (per RFC 438):
foobar.rs: let x: &'static (Copy + 'static);
foobar.rs:2:13: 2:23 error: cast to unsized type: `&_` as `core::marker::Copy`
foobar.rs:2 let x = &1 as Copy;
^~~~~~~~~~
foobar.rs:2:19: 2:23 help: try casting to a reference instead:
foobar.rs: let x = &1 as &Copy;
foobar.rs:7:24: 7:25 error: expected expression, found `;`
foobar.rs:7 let x = box (1 + 1);
^
foobar.rs:7:13: 7:16 help: try using `box()` instead:
foobar.rs: let x = box() (1 + 1);
This also modifies compiletest to give the ability to directly test suggestions
given by error messages.
table, introduce a `FreeRegionMap` data structure. regionck computes the
`FreeRegionMap` for each fn and stores the result into the tcx so that
borrowck can use it (this could perhaps be refactored to have borrowck
recompute the map, but it's a bid tedious to recompute due to the
interaction of closures and free fns). The main reason to do this is
because of #22779 -- using a global table was incorrect because when
validating impl method signatures, we want to use the free region
relationships from the *trait*, not the impl.
Fixes#22779.
This makes it illegal to have unconstrained lifetimes that appear in an associated type definition. Arguably, we should prohibit all unconstrained lifetimes -- but it would break various macros. It'd be good to evaluate how large a break change it would be. But this seems like the minimal change we need to do to establish soundness, so we should land it regardless. Another variant would be to prohibit all lifetimes that appear in any impl item, not just associated types. I don't think that's necessary for soundness -- associated types are different because they can be projected -- but it would feel a bit more consistent and "obviously" safe. I'll experiment with that in the meantime.
r? @aturon
Fixes#22077.
which get mentioned in an associated type are constrained. Arguably we
should just require that all regions are constrained, but that is more
of a breaking change.
