`Box<[T]>` is created by allocating `Box<[T, ..n]>` and coercing it so
this code path is never used. It's also broken because it clamps the
capacity of the memory allocations to 4 elements and that's incompatible
with sized deallocation. This dates back to when `~[T]` was a growable
vector type implemented as:
*{ { tydesc, ref_count, prev, next }, { length, capacity, data[] } }
Since even empty vectors had to allocate, it started off the capacity of
all vectors at 4 as a heuristic. It's not possible to grow `Box<[T]>`
and there is no need for a memory allocation when it's empty, so it
would be a terrible heuristic today even if it worked.
type they provide an implementation for.
This breaks code like:
mod foo {
struct Foo { ... }
}
impl foo::Foo {
...
}
Change this code to:
mod foo {
struct Foo { ... }
impl Foo {
...
}
}
Additionally, if you used the I/O path extension methods `stat`,
`lstat`, `exists`, `is_file`, or `is_dir`, note that these methods have
been moved to the the `std::io::fs::PathExtensions` trait. This breaks
code like:
fn is_it_there() -> bool {
Path::new("/foo/bar/baz").exists()
}
Change this code to:
use std::io::fs::PathExtensions;
fn is_it_there() -> bool {
Path::new("/foo/bar/baz").exists()
}
Closes#17059.
RFC #155.
[breaking-change]
The other extension types already worked this way and it can be useful to track some state along with the extension.
I also removed the `BasicMacroExpander` and `BasicIdentMacroExpander` since the span inside of them was never used. The expander function types now directly implement the relevant trait.
The string slices returned by `get_ref` can actually be
invalidated by calling `clear`. Since this method is unused,
it is easiest to simply remove it.
Closes#17181
This PR creates a new lint : ``unused_extern_crate``, which do pretty much the same thing as ``unused_import``, but for ``extern crate`` statements. It is related to feature request #10385.
I adapted the code tracking used imports so that it tracks extern crates usage as well. This was mainly trial and error and while I believe all cases are covered, there might be some code I added that is useless (long compile times didn't give me the opportunity to check this in detail).
Also, I removed some unused ``extern crate`` statements from the libs, that where spotted by this new lint.
Few visitors used the context passing feature and it can be easily emulated.
The added lifetime threading allows a visitor to keep safe references to AST
nodes it visits, making a non-owning ast_map design possible, for #13316.
`Box<[T]>` is created by allocating `Box<[T, ..n]>` and coercing it so
this code path is never used. It's also broken because it clamps the
capacity of the memory allocations to 4 elements and that's incompatible
with sized deallocation. This dates back to when `~[T]` was a growable
vector type implemented as:
*{ { tydesc, ref_count, prev, next }, { length, capacity, data[] } }
Since even empty vectors had to allocate, it started off the capacity of
all vectors at 4 as a heuristic. It's not possible to grow `Box<[T]>`
and there is no need for a memory allocation when it's empty, so it
would be a terrible heuristic today even if it worked.
When checking for an existing crate, compare against the
`crate_metadata::name` field, which is the crate name which
was requested during resolution, rather than the result of the
`crate_metadata::name()` method, which is the crate name within
the crate metadata, as these may not match when using the --extern
option to `rustc`.
This fixes spurious "multiple crate version" warnings under the
following scenario:
- The crate `foo`, is referenced multiple times
- `--extern foo=./path/to/libbar.rlib` is specified to rustc
- The internal crate name of `libbar.rlib` is not `foo`
The behavior surrounding `Context::should_match_name` and the
comments in `loader.rs` both lead me to believe that this scenario
is intended to work.
Fixes#17186
The Guide isn't 100% perfect, but it's basically complete. It's
certainly better than the tutorial is. Time to start pointing more
people its way.
I also just made it consistent to call all things 'guides' rather than
tutorials.
Fixes#9874. This is the big one.
And two bugs that just go away.
Fixes#14503.
Fixes#15009.
The Guide isn't 100% perfect, but it's basically complete. It's
certainly better than the tutorial is. Time to start pointing more
people its way.
I also just made it consistent to call all things 'guides' rather than
tutorials.
Fixes#9874. This is the big one.
And two bugs that just go away.
Fixes#14503.
Fixes#15009.
