| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This prevents ICEs when old crates are used with a new version of
rustc. Currently, the linking of crates compiled with different
versions of rustc is completely unsupported.
Fixes #28700
|
|
|
|
|
|
Make sure Name, SyntaxContext and Ident are passed by value
Make sure Idents don't serve as keys (or parts of keys) in maps, Ident comparison is not well defined
|
|
|
|
|
|
|
|
r? @Manishearth
This is a work in progress.
|
|
This could be a [breaking-change] if your lint or syntax extension (is that even possible?) uses HIR attributes or literals.
|
|
|
|
The sort key is a (DefId, Name), which is *not* stable between
runs, so we must re-sort when loading.
Fixes #24063
Fixes #25467
Fixes #27222
Fixes #28377
r? @eddyb
|
|
The sort key is a (DefId, Name), which is *not* stable between
runs, so we must re-sort when loading.
Fixes #24063
Fixes #25467
Fixes #27222
Fixes #28377
|
|
|
|
this improves the compilation time for small crates by ~20%
|
|
|
|
|
|
|
|
this makes the code cleaner
|
|
This increases regionck performance greatly - type-checking on
librustc decreased from 9.1s to 8.1s. Because of Amdahl's law,
total performance is improved only by about 1.5% (LLVM wizards,
this is your opportunity to shine!).
before:
576.91user 4.26system 7:42.36elapsed 125%CPU (0avgtext+0avgdata 1142192maxresident)k
after:
566.50user 4.84system 7:36.84elapsed 125%CPU (0avgtext+0avgdata 1124304maxresident)k
I am somewhat worried really need to find out why we have this Red Queen's
Race going on here. Originally I suspected it may be a problem from RFC1214's
warnings, but it seems to be an effect from other changes.
However, the increase seems to be mostly in LLVM's time, so I guess
it's the LLVM wizards' problem.
|
|
This reduces the size of CodeExtent to 12 bytes (was 24). We should have
a warning for this kind of problem.
|
|
this should reduce the size of ty::Region to 24 bytes (from 32),
and they are treated differently in most cases anyway.
|
|
|
|
|
|
This is purposely separate to the "rust-intrinsic" ABI, because these
intrinsics are theoretically going to become stable, and should be fine
to be independent of the compiler/language internals since they're
intimately to the platform.
|
|
(this incidentally fixes an error message where the paths separator is " " instead of "::")
|
|
Just a little code cleanup I was doing as part of another refactoring (which may turn out not to be needed). The main thrust of this is to cleanup the interface to `tydecode.rs` to be less ridiculously repetitive. I also purged the generic "def-id conversion" parameter in favor of a trait object, just to reduce code duplication a bit and make the signatures a bit less messy. I measured the bootstrapping time to build stage2 with these changes, it was identical. (But it'd be easy enough to restore the unboxed closure if we wanted it.)
|
|
|
|
|
|
|
|
|
|
|
|
to store the closure in the PSState struct
|
|
|
|
This commit is an implementation of [RFC 1183][rfc] which allows swapping out
the default allocator on nightly Rust. No new stable surface area should be
added as a part of this commit.
[rfc]: https://github.com/rust-lang/rfcs/pull/1183
Two new attributes have been added to the compiler:
* `#![needs_allocator]` - this is used by liballoc (and likely only liballoc) to
indicate that it requires an allocator crate to be in scope.
* `#![allocator]` - this is a indicator that the crate is an allocator which can
satisfy the `needs_allocator` attribute above.
The ABI of the allocator crate is defined to be a set of symbols that implement
the standard Rust allocation/deallocation functions. The symbols are not
currently checked for exhaustiveness or typechecked. There are also a number of
restrictions on these crates:
* An allocator crate cannot transitively depend on a crate that is flagged as
needing an allocator (e.g. allocator crates can't depend on liballoc).
* There can only be one explicitly linked allocator in a final image.
* If no allocator is explicitly requested one will be injected on behalf of the
compiler. Binaries and Rust dylibs will use jemalloc by default where
available and staticlibs/other dylibs will use the system allocator by
default.
Two allocators are provided by the distribution by default, `alloc_system` and
`alloc_jemalloc` which operate as advertised.
Closes #27389
|
|
|
|
|
|
This commit stabilizes the `std::time` module and the `Duration` type.
`Duration::span` remains unstable, and the `Display` implementation for
`Duration` has been removed as it is still being reworked and all trait
implementations for stable types are de facto stable.
This is a [breaking-change] to those using `Duration`'s `Display`
implementation.
I'm opening this PR as a platform for discussion - there may be some method renaming to do as part of the stabilization process.
|
|
Rust's current compilation model makes it impossible on Windows to generate one
object file with a complete and final set of dllexport annotations. This is
because when an object is generated the compiler doesn't actually know if it
will later be included in a dynamic library or not. The compiler works around
this today by flagging *everything* as dllexport, but this has the drawback of
exposing too much.
Thankfully there are alternate methods of specifying the exported surface area
of a dll on Windows, one of which is passing a `*.def` file to the linker which
lists all public symbols of the dynamic library. This commit removes all
locations that add `dllexport` to LLVM variables and instead dynamically
generates a `*.def` file which is passed to the linker. This file will include
all the public symbols of the current object file as well as all upstream
libraries, and the crucial aspect is that it's only used when generating a
dynamic library. When generating an executable this file isn't generated, so all
the symbols aren't exported from an executable.
To ensure that statically included native libraries are reexported correctly,
the previously added support for the `#[linked_from]` attribute is used to
determine the set of FFI symbols that are exported from a dynamic library, and
this is required to get the compiler to link correctly.
|
|
To correctly reexport statically included libraries from a DLL on Windows, the
compiler will soon need to have knowledge about what symbols are statically
included and which are not. To solve this problem a new unstable
`#[linked_from]` attribute is being added and recognized on `extern` blocks to
indicate which native library the symbols are coming from.
The compiler then keeps track of what the set of FFI symbols are that are
included statically. This information will be used in a future commit to
configure how we invoke the linker on Windows.
|
|
This commit stabilizes the `std::time` module and the `Duration` type.
`Duration::span` remains unstable, and the `Display` implementation for
`Duration` has been removed as it is still being reworked and all trait
implementations for stable types are de facto stable.
This is a [breaking-change] to those using `Duration`'s `Display`
implementation.
|
|
This ended up being a bigger refactoring than I thought, as I also cleaned a few ugly points in rustc. There are still a few areas that need improvements.
Performance numbers:
```
Before:
572.70user 5.52system 7:33.21elapsed 127%CPU (0avgtext+0avgdata 1173368maxresident)k
llvm-time: 385.858
After:
545.27user 5.49system 7:10.22elapsed 128%CPU (0avgtext+0avgdata 1145348maxresident)k
llvm-time: 387.119
```
A good 5% perf improvement. Note that after this patch >70% of the time is spent in LLVM - Amdahl's law is in full effect.
Passes make check locally.
r? @nikomatsakis
|
|
|
|
|
|
This search happens a lot! Locally, compiling hyper sees the following improvements:
before
real 0m30.843s
user 0m51.644s
sys 0m2.128s
real 0m30.164s
user 0m53.320s
sys 0m2.208s
after
real 0m28.438s
user 0m51.076s
sys 0m2.276s
real 0m28.612s
user 0m51.560s
sys 0m2.192s
|
|
|
|
|
|
|
|
|
|
This changes the current behaviour for two cases (that I know of)
```rust
mod foo {
extern crate bar;
}
// `bar::` changes to `foo::bar::`
```
```rust
extern crate bar as quux;
// `bar::` changes to `quux::`
```
For example:
```rust
mod foo {
extern crate core;
}
fn assert_clone<T>() where T : Clone { }
fn main() {
assert_clone::<foo::core::atomic::AtomicBool>();
// error: the trait `core::clone::Clone` is not implemented for the type `core::atomic::AtomicBool` [E0277]
// changes to
// error: the trait `foo::core::clone::Clone` is not implemented for the type `foo::core::atomic::AtomicBool` [E0277]
}
```
Notably the following test case broke:
```rust
#[bench]
fn bar(x: isize) { }
//~^ ERROR mismatched types
//~| expected `fn(&mut test::Bencher)`
// changed to
//~| expected `fn(&mut __test::test::Bencher)`
```
If a crate is linked multiple times the path with the least segments is stored.
Partially addresses #1920. (this doesn't solve the issue raised about re-exports)
r? @nikomatsakis
|
|
|
