| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fixes #41849. Problem was that evaluating the constant expression
required evaluating a trait, which would equate types, which would
request variance information, which it would then discard. However,
computing the variance information would require determining the type of
a field, which would evaluate the constant expression.
(This problem will potentially arise *later* as we move to more sophisticated
constants, however, where we need to check subtyping. We can tackle that
when we come to it.)
|
|
r=nikomatsakis
ICH: Handle case of removed FileMaps.
This PR fixes a bug introduced in #41709 where removing a source file between compilation sessions would cause an ICE:
https://travis-ci.org/rust-icci/crossbeam/jobs/230582234#L633
r? @nikomatsakis
|
|
Add `eprint!` and `eprintln!` macros to the prelude.
These are exactly the same as `print!` and `println!` except that they write to stderr instead of stdout. Issues #39228 and #40528; previous PR #39229; accepted RFC rust-lang/rfcs#1869; proposed revision to The Book rust-lang/book#615.
I have _not_ revised this any since the original submission; I will do that later this week. I wanted to get this PR in place since it's been quite a while since the RFC was merged.
Known outstanding review comments:
* [x] @steveklabnik requested a new chapter for the unstable version of The Book -- please see if the proposed revisions to the second edition cover it.
* [x] @nodakai asked if it were possible to merge the internal methods `_print` and `_eprint` - not completely, since they both refer to different internal globals which we don't want to expose, but I will see if some duplication can be factored out.
Please let me know if I missed anything.
|
|
|
|
|
|
These are exactly the same as `print!` and `println!` except that
they write to stderr instead of stdout. Issue #39228.
|
|
|
|
|
|
incr.comp.: Hash more pieces of crate metadata to detect changes there.
This PR adds incr. comp. hashes for non-`Entry` pieces of data in crate metadata.
The first part of it I like: `EntryBuilder` is refactored into the more generally applicable `IsolatedEncoder` which provides means of encoding something into metadata while also feeding the encoded data into an incr. comp. hash. We already did this for `Entry`, now we are doing it for various other pieces of data too, like the set of exported symbols and so on. The hashes generated there are persisted together with the per-`Entry` hashes and are also used for dep-graph dirtying the same way.
The second part of the PR I'm not entirely happy with: In order to make sure that we don't forget registering a read to the new `DepNodes` introduced here, I added the `Tracked<T>` struct. This struct wraps a value and requires a `DepNode` when accessing the wrapped value. This makes it harder to overlook adding read edges in the right places and works just fine.
However, crate metadata is already used in places where there is no `tcx` yet or even in places where no `cnum` has been assigned -- this makes it harder to apply this feature consistently or implement it ergonomically. The result is not too bad but there's a bit more code churn and a bit more opportunity to get something wrong than I would have liked. On the other hand, wrapping things in `Tracked<T>` already has revealed some bugs, so there's definitely some value in it.
This is still a work in progress:
- [x] I need to write some test cases.
- [x] Accessing the CodeMap should really be dependency tracked too, especially with the new path-remapping feature.
cc @nikomatsakis
|
|
dump-mir was causing cycles by invoking item-path-str at bad times
Workaround for now, but probably a better fix is to opt **in** to using the types for impls (if we do that at all; maybe filename/line is better).
Fixes #41697
|
|
Fixed argument inference for closures when coercing into 'fn'
This fixes https://github.com/rust-lang/rust/issues/41755. The tests `compile-fail/closure-no-fn.rs` and `compile-fail/issue-40000.rs` were modified. A new test `run-pass/closure_to_fn_coercion-expected-types.rs` was added
r? @nikomatsakis
|
|
try to fix lvalue ops for real
Hopefully this is the last PR needed.
Fixes #41726.
Fixes #41742.
Fixes #41774.
|
|
Allow bare CR in ////-style comment.
Fixes #40624 in a way that bare CR is allowed in all non-doc comments.
|
|
Use diagnostics for trace_macro instead of println
When using `trace_macro`, use `span_label`s instead of `println`:
```rust
note: trace_macro
--> $DIR/trace-macro.rs:14:5
|
14 | println!("Hello, World!");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: expands to `println! { "Hello, World!" }`
= note: expands to `print! { concat ! ( "Hello, World!" , "\n" ) }`
```
Fix #22597.
|
|
Implement the illegal_floating_point_literal_pattern compat lint
Adds a future-compatibility lint for the [breaking-change] introduced by issue #41620 . cc issue #41255 .
|
|
rustc: treat const bodies like fn bodies in middle::region.
Allows `T::ASSOC_CONST` to be used without a `T: 'static` bound.
cc @rust-lang/compiler @rust-lang/lang
|
|
|
|
|
|
|
|
|
|
Workaround for now, but probably a better fix is to opt **in** to using
the types for impls (if we do that at all; maybe filename/line is
better).
|
|
Hopefully this is the last PR needed.
Fixes #41726.
Fixes #41742.
Fixes #41774.
|
|
|
|
|
|
Point at fields that make the type recursive
On recursive types of infinite size, point at all the fields that make
the type recursive.
```rust
struct Foo {
bar: Bar,
}
struct Bar {
foo: Foo,
}
```
outputs
```
error[E0072]: recursive type `Foo` has infinite size
--> file.rs:1:1
1 | struct Foo {
| ^^^^^^^^^^ recursive type has infinite size
2 | bar: Bar,
| -------- recursive here
|
= help: insert indirection (e.g., a `Box`, `Rc`, or `&`) at some point to make `Foo` representable
error[E0072]: recursive type `Bar` has infinite size
--> file.rs:5:1
|
5 | struct Bar {
| ^^^^^^^^^^ recursive type has infinite size
6 | foo: Foo,
| -------- recursive here
|
= help: insert indirection (e.g., a `Box`, `Rc`, or `&`) at some point to make `Bar` representable
```
|
|
Allow # to appear in rustdoc code output.
"##" at the start of a trimmed rustdoc line is now cut to "#" and then
shown. If the user wanted to show "##", they can type "###".
I'm somewhat concerned about the potential implications for users, since this does make a potentially backwards-incompatible change. Previously, `##` had no special handling, and now we do change it. However, I'm not really sure what we can do here to improve this, and I can't think of any cases where `##` would likely be correct in a code block, though of course I could be wrong.
Fixes #41783.
|
|
Fix issue #41652
Fix issue #41652. Don't print anything in `render_source_line()` if no source code is given.
(cc @jonathandturner #34789)
|
|
"##" at the start of a trimmed rustdoc line is now cut to "#" and then
shown. If the user wanted to show "##", they can type "###".
|
|
|
|
|
|
|
|
|
|
|
|
Add regression test for issue #24106
Fixes #24106.
|
|
Refactor variance and remove last `[pub]` map
This PR refactors variance to work in a more red-green friendly way. Because red-green doesn't exist yet, it has to be a bit hacky. The basic idea is this:
- We compute a big map with the variance for all items in the crate; when you request variances for a particular item, we read it from the crate
- We now hard-code that traits are invariant (which they are, for deep reasons, not gonna' change)
- When building constraints, we compute the transitive closure of all things within the crate that depend on what using `TransitiveRelation`
- this lets us gin up the correct dependencies when requesting variance of a single item
Ah damn, just remembered, one TODO:
- [x] Update the variance README -- ah, I guess the README updates I did are sufficient
r? @michaelwoerister
|
|
Suggest `!` for bitwise negation when encountering a `~`
Fix #41679
Here is a program
```rust
fn main() {
let x = ~1;
}
```
It's output:
```
error: `~` can not be used as an unary operator
--> /home/fcc/temp/test.rs:4:13
|
4 | let x = ~1;
| ^^
|
= help: use `!` instead of `~` if you meant to bitwise negation
```
cc @bstrie
|
|
r=alexcrichton
Reload nameserver information on lookup failure
As discussed in #41570, UNIX systems often cache the contents of `/etc/resolv.conf`, which can cause lookup failures to persist even after a network connection becomes available. This patch modifies lookup_host to force a reload of the nameserver entries following a lookup failure. This is in line with what many C programs already do (see #41570 for details). On systems with nscd, this should not be necessary, but not all systems run nscd.
Fixes #41570.
Depends on rust-lang/libc#585.
r? @alexcrichton
|
|
|
|
As discussed in #41570, UNIX systems often cache the contents of
/etc/resolv.conf, which can cause lookup failures to persist even after
a network connection becomes available. This patch modifies lookup_host
to force a reload of the nameserver entries following a lookup failure.
This is in line with what many C programs already do (see #41570 for
details). On systems with nscd, this should not be necessary, but not
all systems run nscd.
Introduces an std linkage dependency on libresolv on macOS/iOS (which
also makes it necessary to update run-make/tools.mk).
Fixes #41570.
Depends on rust-lang/libc#585.
|
|
* clean up code
* point only fields that cause the type to be of infinite size
* fix unittests
|
|
On recursive types of infinite size, point at all the fields that make
the type recursive.
```rust
struct Foo {
bar: Bar,
}
struct Bar {
foo: Foo,
}
```
outputs
```
error[E0072]: recursive type `Foo` has infinite size
--> file.rs:1:1
1 | struct Foo {
| _^ starting here...
2 | | bar: Bar,
| | -------- recursive here
3 | | }
| |_^ ...ending here: recursive type has infinite size
|
= help: insert indirection (e.g., a `Box`, `Rc`, or `&`) at some point to make `Foo` representable
error[E0072]: recursive type `Bar` has infinite size
--> file.rs:5:1
|
5 | struct Bar {
| _^ starting here...
6 | | foo: Foo,
| | -------- recursive here
7 | | }
| |_^ ...ending here: recursive type has infinite size
|
= help: insert indirection (e.g., a `Box`, `Rc`, or `&`) at some point to make `Bar` representable
```
|
|
Fixes #24106.
|
|
(Now that variances are not part of signature.)
|
|
make it work for traits etc uniformly
|
|
There are now two queries: crate and item. The crate one computes the
variance of all items in the crate; it is sort of an implementation
detail, and not meant to be used. The item one reads from the crate one,
synthesizing correct deps in lieu of the red-green algorithm.
At the same time, remove the `variance_computed` flag, which was a
horrible hack used to force invariance early on (e.g. when type-checking
constants). This is only needed because of trait applications, and
traits are always invariant anyway. Therefore, we now change to take
advantage of the query system:
- When asked to compute variances for a trait, just return a vector
saying 'all invariant'.
- Remove the corresponding "inferreds" from traits, and tweak the
constraint generation code to understand that traits are always
inferred.
|
|
|
|
Add test for Inherent static methods
Fixes #28848
|
|
Don't print the source code in emit_message_default() and
render_source_line() if the source code is None.
|
|
Rollup of 7 pull requests
- Successful merges: #41217, #41625, #41640, #41653, #41656, #41657, #41705
- Failed merges:
|
|
Consider changing to & for let bindings #40402
This is a fix for #40402
For the example
```
fn main() {
let v = vec![String::from("oh no")];
let e = v[0];
}
```
It gives
```
error[E0507]: cannot move out of indexed content
--> ex1.rs:4:13
|
4 | let e = v[0];
| ^^^^ cannot move out of indexed content
|
= help: consider changing to `&v[0]`
error: aborting due to previous error
```
Another alternative is
```
error[E0507]: cannot move out of indexed content
--> ex1.rs:4:13
|
4 | let e = v[0];
| ^^^^ consider changing to `&v[0]`
error: aborting due to previous error
```
Also refer to #41564 for more details.
r? @nikomatsakis
|
