Closes#13441 (debuginfo: Fixes and improvements for #12840, #12886, and #13213)
Closes#13433 (Remove references to @Trait from a compiler error message)
Closes#13430 (Fix outdated lint warning about inner attribute)
Closes#13425 (Remove a pile of (mainly) internal `~[]` uses)
Closes#13419 (Stop using transmute_mut in RefCell)
Closes#13417 (Remove an unnecessary file `src/libnative/io/p`.)
Closes#13409 (Closing assorted resolve bugs)
Closes#13406 (Generalized the pretty-print entry points to support `-o <file>`.)
Closes#13403 (test: Add a test for #7663)
Closes#13402 (rustdoc: Prune the paths that do not appear in the index.)
Closes#13396 (rustc: Remove absolute rpaths)
Closes#13371 (Rename ast::Purity and ast::Impure Function. Closes#7287)
Closes#13350 (collections: replace all ~[T] with Vec<T>.)
Previously, a private use statement would shadow a public use statement, all of
a sudden publicly exporting the privately used item. The correct behavior here
is to only shadow the use for the module in question, but for now it just
reverts the entire name to private so the pub use doesn't have much effect.
The behavior isn't exactly what we want, but this no longer has backwards
compatibility hazards.
Previously resolve was checking the "import resolution" for whether an import
had succeeded or not, but this was the same structure filled in by a previous
import if a name is shadowed. Instead, this alters resolve to consult the local
resolve state (as opposed to the shared one) to test whether an import succeeded
or not.
Closes#13404
Resolve is currently erroneously allowing imports through private `use`
statements in some circumstances, even across module boundaries. For example,
this code compiles successfully today:
use std::c_str;
mod test {
use c_str::CString;
}
This should not be allowed because it was explicitly decided that private `use`
statements are purely bringing local names into scope, they are not
participating further in name resolution.
As a consequence of this patch, this code, while valid today, is now invalid:
mod test {
use std::c_str;
unsafe fn foo() {
::test::c_str::CString::new(0 as *u8, false);
}
}
While plausibly acceptable, I found it to be more consistent if private imports
were only considered candidates to resolve the first component in a path, and no
others.
Closes#12612
When calculating the sysroot, it's more accurate to use realpath() rather than
just one readlink() to account for any intermediate symlinks that the rustc
binary resolves itself to.
For rpath, realpath() is necessary because the rpath must dictate a relative
rpath from the destination back to the originally linked library, which works
more robustly if there are no symlinks involved.
Concretely, any binary generated on OSX into $TMPDIR requires an absolute rpath
because the temporary directory is behind a symlink with one layer of
indirection. This symlink causes all relative rpaths to fail to resolve.
cc #11734
cc #11857
Concerns have been raised about using absolute rpaths in #11746, and this is the
first step towards not relying on rpaths at all. The only current use case for
an absolute rpath is when a non-installed rust builds an executable that then
moves from is built location. The relative rpath back to libstd and absolute
rpath to the installation directory still remain (CFG_PREFIX).
Closes#11746
Rebasing of #12754
I think that the test case from this issue has become out of date with resolve
changes in the past 9 months, and it's not entirely clear to me what the
original bug was.
Regardless, it seems like tricky resolve behavior, so tests were added to make
sure things resolved correctly and warnings were correctly reported.
Closes#7663
This commit makes sure that code inlined from other functions isn't assigned the source position of the call site, since this leads to undesired behavior when setting line breakpoints (issue #12886)
This fixes the categorization of the upvars of procs (represented internally
as once fns) to consider usage to require a loan. In doing so, upvars are no
longer allowed to be moved out of repeatedly in loops and such.
Closes#10398Closes#12041Closes#12127
This commit changes the way move errors are reported when some value is
captured by a PatIdent. First, we collect all of the "cannot move out
of" errors before reporting them, and those errors with the same "move
source" are reported together. If the move is caused by a PatIdent (that
binds by value), we add a note indicating where it is and suggest the
user to put `ref` if they don't want the value to move. This makes the
"cannot move out of" error in match expression nicer (though the extra
note may not feel that helpful in other places :P). For example, with
the following code snippet,
```rust
enum Foo {
Foo1(~u32, ~u32),
Foo2(~u32),
Foo3,
}
fn main() {
let f = &Foo1(~1u32, ~2u32);
match *f {
Foo1(num1, num2) => (),
Foo2(num) => (),
Foo3 => ()
}
}
```
Errors before the change:
```rust
test.rs:10:9: 10:25 error: cannot move out of dereference of `&`-pointer
test.rs:10 Foo1(num1, num2) => (),
^~~~~~~~~~~~~~~~
test.rs:10:9: 10:25 error: cannot move out of dereference of `&`-pointer
test.rs:10 Foo1(num1, num2) => (),
^~~~~~~~~~~~~~~~
test.rs:11:9: 11:18 error: cannot move out of dereference of `&`-pointer
test.rs:11 Foo2(num) => (),
^~~~~~~~~
```
After:
```rust
test.rs:9:11: 9:13 error: cannot move out of dereference of `&`-pointer
test.rs:9 match *f {
^~
test.rs:10:14: 10:18 note: attempting to move value to here (to prevent the move, you can use `ref num1` to capture value by reference)
test.rs:10 Foo1(num1, num2) => (),
^~~~
test.rs:10:20: 10:24 note: and here (use `ref num2`)
test.rs:10 Foo1(num1, num2) => (),
^~~~
test.rs:11:14: 11:17 note: and here (use `ref num`)
test.rs:11 Foo2(num) => (),
^~~
```
Close#8064
* Use `setq-local' instead of (set (make-local-variable ...) value).
Provides a version for older Emacsen.
* Remove use of `cl.el'.
* Use \' in file regexp instead of line end match $.
* Use type for defcustom and add parent group.
This fixes the categorization of the upvars of procs (represented internally
as once fns) to consider usage to require a loan. In doing so, upvars are no
longer allowed to be moved out of repeatedly in loops and such.
Closes#10398Closes#12041Closes#12127
Previously, if statements of the form "Foo;" or "let _ = Foo;" were encountered
where Foo had a destructor, the destructors were not run. This changes
the relevant locations in trans to check for ty::type_needs_drop and invokes
trans_to_lvalue instead of trans_into.
Closes#4734Closes#6892
