The "hint" mechanism is essentially used as a workaround to compute
types for expressions which have not yet been type-checked. This
commit clarifies that usage, and limits the effects to the places
where it is currently necessary.
Fixes#26210.
r? @eddyb
Adding new variants is annoying as one needs to modify all these places that **don't** handle the new variant.
I chose not to use `Display` as I don't think it is appropriate.
This also changes how variant values are printed in errors, they are no
longer printed in their parent scope. As far as I can tell, this is
leftover from pre-namespacing of enums.
Closes#17546.
The "hint" mechanism is essentially used as a workaround to compute
types for expressions which have not yet been type-checked. This
commit clarifies that usage, and limits the effects to the places
where it is currently necessary.
Fixes#26210.
Transition to the new object lifetime defaults, replacing the old defaults completely.
r? @pnkfelix
This is a [breaking-change] as specified by [RFC 1156][1156] (though all cases that would break should have been receiving warnings starting in Rust 1.2). Types like `&'a Box<Trait>` (or `&'a Rc<Trait>`, etc) will change from being interpreted as `&'a Box<Trait+'a>` to `&'a Box<Trait+'static>`. To restore the old behavior, write the `+'a` explicitly. For example, the function:
```rust
trait Trait { }
fn foo(x: &Box<Trait>) { ... }
```
would be rewritten as:
```rust
trait Trait { }
fn foo(x: &'a Box<Trait+'a>) { ... }
```
if one wanted to preserve the current typing.
[1156]: https://github.com/rust-lang/rfcs/blob/master/text/1156-adjust-default-object-bounds.md
This also changes how variant values are printed in errors, they are no
longer printed in their parent scope. As far as I can tell, this is
leftover from pre-namespacing of enums.
Closes#17546.
Adds two error codes, one for duplicate associated constants and one for types. I'm not certain these should each have their own code, but E0201 is already solely for duplicate associated functions so at least it kinda matches. This will lead to somewhat redundant error explanations, but that's nothing new!
Fixes#23969.
The error now looks like this:
```
<anon>:4:9: 4:10 error: use of moved value: `x` [E0382]
<anon>:4 foo(x);
^
<anon>:3:9: 3:10 note: `x` moved here because it has type `Box<i32>`, which is moved by default
<anon>:3 let y = x;
^
<anon>:3:9: 3:10 help: use `ref` to take a reference instead:
<anon>: let ref y = x;
```
Expands E0201 to be used for any duplicate associated items, not just duplicate
methods/functions. It also correctly detects when two different kinds of items
(like a constant and a method) have the same name.
Fixes#23969.
Fixes#23302.
Note that there's an odd situation regarding the following, most likely due to some inadequacy in `const_eval`:
```rust
enum Y {
A = 1usize,
B,
}
```
In this case, `Y::B as usize` might be considered a constant expression in some cases, but not others. (See #23513, for a related problem where there is only one variant, with no discriminant, and it doesn't behave nicely as a constant expression either.)
Most of the complexity in this PR is basically future-proofing, to ensure that when `Y::B as usize` is fully made to be a constant expression, it can't be used to set `Y::A`, and thus indirectly itself.
Fixes#24249
I've tagged all items that were missing docs to allow them to compile for now, the ones in core/num should probably be documented at least.
This is also a breaking change for any crates using `#[deny(missing_docs)]` that have undocumented constants, not sure there is any way to avoid this without making it a separate lint?
bound that is likely to change. In that case, it will change to 'static,
so then scan down the graph to see whether there are any hard
constraints that would prevent 'static from being a valid value
here. Report a warning.
This doesn't add a test for the main problem in #8640 since it seems that
was already fixed (including a test) in PR #19522. This just adds a test
for a program mentioned in the comments that used to erroneously compile.
Closes#8640.
This was originally motivated by checking for HRTB hygiene, but I found several other bugs on the way.
This does not fix the biggest user of ty_walk, which is dtorck - I would prefer to coordinate that with @pnkfelix.
r? @eddyb
This catches the case when a trait defines a default method that calls
itself, but on a type that isn't necessarily `Self`, e.g. there's no
reason that `T = Self` in the following, so the call isn't necessarily
recursive (`T` may override the call).
trait Bar {
fn method<T: Bar>(&self, x: &T) {
x.method(x)
}
}
Fixes#26333.
This makes them compliant with the new version of RFC 401 (i.e.
RFC 1052).
Fixes#26391. I *hope* the tests I have are enough.
This is a [breaking-change]
r? @nrc
This commit shards the all-encompassing `core`, `std_misc`, `collections`, and `alloc` features into finer-grained components that are much more easily opted into and tracked. This reflects the effort to push forward current unstable APIs to either stabilization or removal. Keeping track of unstable features on a much more fine-grained basis will enable the library subteam to quickly analyze a feature and help prioritize internally about what APIs should be stabilized.
A few assorted APIs were deprecated along the way, but otherwise this change is just changing the feature name associated with each API. Soon we will have a dashboard for keeping track of all the unstable APIs in the standard library, and I'll also start making issues for each unstable API after performing a first-pass for stabilization.
Currently in the E0252 message, traits and modules are all called types (as in "a type named `Foo` has already been imported", even when `Foo` was a trait or module). This commit changes that to additionally detect when the import in question is a trait or module and report it accordingly.
Fixes#25396.
This makes them compliant with the new version of RFC 401 (i.e.
RFC 1052).
Fixes#26391. I *hope* the tests I have are enough.
This is a [breaking-change]
Previously, it said "import `Foo` conflicts with existing submodule" even
when it was a type alias, enum, or trait. The message now says the conflict
is with "type in this module" in the case of the first two, and "trait in
this module" for the last one.
Fixes#24081.
Unlike coercing from reference to unsafe pointer, coercing between two
unsafe pointers doesn't need an AutoDerefRef, because there is no region
that regionck would need to know about.
In unoptimized libcore, this reduces the number of "auto_deref" allocas
from 174 to 4.
Currently in the E0252 message, traits and modules are all called types
(as in "a type named `Foo` has already been imported", even when `Foo` was
a trait or module). This commit changes that to additionally detect when
the import in question is a trait or module and report it accordingly.
Fixes#25396.
When we successfully resolve a trait reference with no type/lifetime parameters, like `i32: Foo` or `Box<u32>: Sized`, this is in fact globally true. This patch adds a simple global to the tcx to cache such cases. The main advantage of this is really about caching things like `Box<Vec<Foo>>: Sized`. It also points to the need to revamp our caching infrastructure -- the current caches make selection cost cheaper, but we still wind up paying a high cost in the confirmation process, and in particular unrolling out dependent obligations. Moreover, we should probably do caching more uniformly and with a key that takes the where-clauses into account. But that's for later.
For me, this shows up as a reasonably nice win (20%) on Servo's script crate (when built in dev mode). This is not as big as my initial measurements suggested, I think because I was building my rustc with more debugging enabled at the time. I've not yet done follow-up profiling and so forth to see where the new hot spots are. Bootstrap times seem to be largely unaffected.
cc @pcwalton
This is technically a [breaking-change] in that functions with unsatisfiable where-clauses may now yield errors where before they may have been accepted. Even before, these functions could never have been *called* by actual code. In the future, such functions will probably become illegal altogether, but in this commit they are still accepted, so long as they do not rely on the unsatisfiable where-clauses. As before, the functions still cannot be called in any case.
Previously, it said "import `Foo` conflicts with existing submodule" even
when it was a type alias, enum, or trait. The message now says the conflict
is with "type in this module" in the case of the first two, and "trait in
this module" for the last one.
Fixes#24081.
Unlike coercing from reference to unsafe pointer, coercing between two
unsafe pointers doesn't need an AutoDerefRef, because there is no region
that regionck would need to know about.
In unoptimized libcore, this reduces the number of "auto_deref" allocas
from 174 to 4.
again, do it once and then just remember the expanded form. At the same
time, filter globally nameable predicates out of the environment, since
they can cause cache errors (and they are not necessary in any case).
Two commits here: one which removes a bunch of tests, and re-enables a few that work.
Second updates the syntax of one of the failing tests. It still doesn't pass, but at least it compiles.
Most of these are old, but some specific messages for specific tests:
* trait-contravariant-self.rs: failed due to a soundess hole:
05e3248a79
* process-detatch: 15966c3c1f
says "this test is being ignored until signals are implemented" That's
not happening for a long time, and when it is, we'll write tests for
it.
* deep-vector{,2}.rs: "too big for our poor macro infrastructure", and has
been ignored over a year.
* borrowck-nested-calls.rs's FIXME #6268 was closed in favor of
rust-lang/rfcs#811
* issue-15167.rs works properly now
* issue-9737.rs works properly now
* match-var-hygiene.rs works properly now
Addresses a chunk of #3965
Part of #24407.
Currently the diagnostics for range patterns are a bit wrong:
```rust
fn main() {
match 5u32 {
0 ... 10 => (),
'a' ... 10 => (),
10 ... 'z' => (),
"what" ... 10 => (),
"what" ... "well" => (),
10 ... "what" => ()
}
}
```
```
range.rs:4:9: 4:19 error: mismatched types in range:
expected integral variable,
found char [E0211]
range.rs:4 'a' ... 10 => (),
^~~~~~~~~~
range.rs:4:9: 4:16 error: only char and numeric types are allowed in range [E0029]
range.rs:4 'a' ... 10 => (),
^~~~~~~
range.rs:4:9: 4:19 error: mismatched types:
expected `u32`,
found `char`
(expected u32,
found char) [E0308]
range.rs:4 'a' ... 10 => (),
^~~~~~~~~~
range.rs:5:9: 5:19 error: mismatched types in range:
expected char,
found integral variable [E0211]
range.rs:5 10 ... 'z' => (),
^~~~~~~~~~
range.rs:5:9: 5:15 error: only char and numeric types are allowed in range [E0029]
range.rs:5 10 ... 'z' => (),
^~~~~~
range.rs:6:9: 6:22 error: mismatched types in range:
expected integral variable,
found &-ptr [E0211]
range.rs:6 "what" ... 10 => (),
^~~~~~~~~~~~~
range.rs:6:9: 6:19 error: only char and numeric types are allowed in range [E0029]
range.rs:6 "what" ... 10 => (),
^~~~~~~~~~
range.rs:6:9: 6:22 error: mismatched types:
expected `u32`,
found `&'static str`
(expected u32,
found &-ptr) [E0308]
range.rs:6 "what" ... 10 => (),
^~~~~~~~~~~~~
range.rs:7:9: 7:19 error: only char and numeric types are allowed in range [E0029]
range.rs:7 "what" ... "well" => (),
^~~~~~~~~~
range.rs:7:9: 7:26 error: mismatched types:
expected `u32`,
found `&'static str`
(expected u32,
found &-ptr) [E0308]
range.rs:7 "what" ... "well" => (),
^~~~~~~~~~~~~~~~~
range.rs:8:9: 8:22 error: mismatched types in range:
expected &-ptr,
found integral variable [E0211]
range.rs:8 10 ... "what" => ()
^~~~~~~~~~~~~
range.rs:8:9: 8:15 error: only char and numeric types are allowed in range [E0029]
range.rs:8 10 ... "what" => ()
^~~~~~
error: aborting due to 12 previous errors
```
The problems here are:
1. The type of the end of the range is used to predict the type of the start (only mildly counter intuitive).
2. E0029 is erroneously generated for `char ... num` and `num ... char`.
2. `u32` is mentioned.
3. Errors which are essentially the same are reported multiple times.
I've attempted to fix this by checking the requirements in a different order. The output I've achieved for the above example is:
```
/home/michael/Temp/range.rs:4:17: 4:22 error: mismatched types in range:
expected char,
found integral variable [E0211]
/home/michael/Temp/range.rs:4 'a' ... 10 => (),
^~~~~
/home/michael/Temp/range.rs:5:16: 5:22 error: mismatched types in range:
expected integral variable,
found char [E0211]
/home/michael/Temp/range.rs:5 10 ... 'z' => (),
^~~~~~
/home/michael/Temp/range.rs:6:9: 6:19 error: only char and numeric types are allowed in range [E0029]
/home/michael/Temp/range.rs:6 "what" ... 10 => (),
^~~~~~~~~~
/home/michael/Temp/range.rs:6:9: 6:19 help: run `rustc --explain E0029` to see a detailed explanation
/home/michael/Temp/range.rs:6:9: 6:19 note: Start type: &'static str
End type: _
/home/michael/Temp/range.rs:6 "what" ... 10 => (),
^~~~~~~~~~
/home/michael/Temp/range.rs:7:9: 7:26 error: only char and numeric types are allowed in range [E0029]
/home/michael/Temp/range.rs:7 "what" ... "well" => (),
^~~~~~~~~~~~~~~~~
/home/michael/Temp/range.rs:7:9: 7:26 help: run `rustc --explain E0029` to see a detailed explanation
/home/michael/Temp/range.rs:7:9: 7:26 note: Start type: &'static str
End type: &'static str
/home/michael/Temp/range.rs:7 "what" ... "well" => (),
^~~~~~~~~~~~~~~~~
/home/michael/Temp/range.rs:8:16: 8:25 error: only char and numeric types are allowed in range [E0029]
/home/michael/Temp/range.rs:8 10 ... "what" => ()
^~~~~~~~~
/home/michael/Temp/range.rs:8:16: 8:25 help: run `rustc --explain E0029` to see a detailed explanation
/home/michael/Temp/range.rs:8:16: 8:25 note: Start type: _
End type: &'static str
/home/michael/Temp/range.rs:8 10 ... "what" => ()
^~~~~~~~~
error: aborting due to 5 previous errors
```
I think this is already tonnes better, but the `Start type/End type` stuff could be neater. I don't think there's really any need to start a `note:` block but I wanted to get some feedback on this. I'd also appreciate advice on how to print the integer types as something other than `_`.
This was always a weird feature, and isn't being used in the compiler.
Static assertions should be done better than this.
This implements RFC #1096.
Fixes#13951Fixes#23008Fixes#6676
This is behind a feature gate, but that's still a
[breaking-change]
The E0397 explanation, as I've written it, isn't really an explanation, but I'm not sure what to put here. I will happily take suggestions.
Partially addresses https://github.com/rust-lang/rust/issues/25851
Currently, for `use` declarations with multiple paths, only the `use` item itself is saved in the AST map, not the individual path nodes. This can lead to a problem when a span of a specific path node is needed.
For example, #24818 caused an ICE because of this, in `ImportResolver::check_for_conflicting_import()`.
Fixes#25763.
Changes:
- adds explanations for E0185, E0186, E0202, E0326
- fixes the explanation for E0053. The previous description was too narrow; there are other error cases.
- changes the error message for E0202 to be specific for associated types, since it seems inherent associated constants are implemented.
Part of #24407
Closes#25046 (by rejecting the code that causes the ICE) and #24946. I haven't been able to deal with the array size or recursion issues yet for associated consts, though my hope was that the change I made for range match patterns might help with array sizes, too.
This PR is pretty much orthogonal to #25065.
Currently, for `use` declarations with multiple paths, only the `use`
item itself is saved in the AST map, not the individual path nodes. This
can lead to a problem when a span of a specific path node is needed.
For example, #24818 caused an ICE because of this, in
`ImportResolver::check_for_conflicting_import()`.
Fixes#25763.
- add feature gate
- add basic tests
- adjust parser to eliminate conflict between `const fn` and associated
constants
- allow `const fn` in traits/trait-impls, but forbid later in type check
- correct some merge conflicts
I think I didn't run tests properly - my second call to
select_all_obligations_or_error has made 3 tests fail. However, this is
just an error message change - integer fallback never worked with casts.
This should hopefully fix all cast-related ICEs once and for all.
I managed to make diagnostics hate me and give me spurious "decoder error"
- removing $build/tmp/extended-errors seems to fix it.
Constants with values that depend on generic parameters or `Self` cause
ICEs in `check_const`, and are not yet accepted via RFC, so we need to
throw a proper error in these cases.
This allows compiling entire crates from memory or preprocessing source files before they are tokenized.
Minor API refactoring included, which is a [breaking-change] for libsyntax users:
* `ParseSess::{next_node_id, reserve_node_ids}` moved to rustc's `Session`
* `new_parse_sess` -> `ParseSess::new`
* `new_parse_sess_special_handler` -> `ParseSess::with_span_handler`
* `mk_span_handler` -> `SpanHandler::new`
* `default_handler` -> `Handler::new`
* `mk_handler` -> `Handler::with_emitter`
* `string_to_filemap(sess source, path)` -> `sess.codemap().new_filemap(path, source)`
This also updates the error messages for both. For E0066, it removes mention
of "managed heap", which was removed in 8a91d33. For E0069, I just tweaked
the wording to make it a bit more explicit.
Also change several error messages to refer to "items" rather than
"methods", since associated items that require resolution during type
checking are not always methods.
There is no subtyping relationship between the types (or their non-freshened
variants), so they can not be merged.
Fixes#22645Fixes#24352Fixes#23825
Should fix#25235 (no test in issue).
Should fix#19976 (test is outdated).
* segfault due to not copying drop flag when coercing
* fat pointer casts
* segfault due to not checking drop flag properly
* debuginfo for DST smart pointers
* unreachable code in drop glue
There is no subtyping relationship between the types (or their non-freshened
variants), so they can not be merged.
Fixes#22645Fixes#24352Fixes#23825
Should fix#25235 (no test in issue).
Should fix#19976 (test is outdated).
There were still some mentions of `~[T]` and `~T`, mostly in comments and debugging statements. I tried to do my best to preserve meaning, but I might have gotten some wrong-- I'm happy to fix anything :)
Fixes the problem in #16974 with unhelpful error messages when accidentally using the wrong syntax for the `crate_type="lib"` attribute. The attribute syntax error now shows up instead of "main function not found".
If the user intended to set the crate_type to "lib" but accidentally used
incorrect syntax such as `#![crate_type(lib)]`, the compilation would fail with
"main function not found". This made it hard to locate the source of the
problem, since the failure would cause the warning about the incorrect
attribute not to be shown.
This change is worrisome to me, both because:
1. I thought the rules in RFC 599 imply that the `Box<Trait>` without `'static`
in the first case would expand to the second case, but their behaviors
here differ. And,
2. The explicit handling of `'static` should mean `dropck` has no application
here and thus we should have seen no change to the expected error messages.
Nonetheless, the error messages changed.
