| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
Remove -Zmiri debugging option
|
|
improve Atomic*::fetch_update docs
This clarifies that fetch_update *always* returns the previous value, either as `Ok(_)` or `Err(_)`, depending on whether the supplied update function returned `Some(_)` or `None`.
|
|
[doc] note the special type inference handling for shift ops
This adds a note to the docs about the difference between the shift ops and the corresponding trait methods when it comes to type inference.
|
|
r=petrochenkov
Use InternedString rather than Name for RegionParameterDef
This makes it consistent with `TypeParameterDef`.
|
|
chrisccoulson:fix-rustdoc-themes-test-without-rpath, r=Mark-Simulacrum
Fix test failure in src/tools/rustdoc-themes when rust.rpath = false
See https://github.com/rust-lang/rust/issues/49907
|
|
r=nikomatsakis
Ignore copyright year when generating deriving span tests
Previously, generate-deriving-span-tests.py would regenerate all the tests anew, even if they hadn't changed. This creates unnecessary diffs that only change the copyright year. Now we check to see if any of the content of the test has changed before generating the new one.
|
|
r=steveklabnik,QuietMisdreavus,frewsxcv,GuillaumeGomez
Add docs for the test crate with the std docs
If the compiler docs aren't going to include the test crate then it may as well be included with std.
Fixes #49388
|
|
Don't inject clippy into rls on stable/beta
as discussed at the all-hands
|
|
Cross-compile builder to Windows for PRs on Travis
I chose a completely arbitrary windows target here (I have no idea what's best, we could do multiple -- they are relatively fast).
|
|
proc_macro: Avoid cached TokenStream more often
This commit adds even more pessimization to use the cached `TokenStream` inside
of an AST node. As a reminder the `proc_macro` API requires taking an arbitrary
AST node and transforming it back into a `TokenStream` to hand off to a
procedural macro. Such functionality isn't actually implemented in rustc today,
so the way `proc_macro` works today is that it stringifies an AST node and then
reparses for a list of tokens.
This strategy unfortunately loses all span information, so we try to avoid it
whenever possible. Implemented in #43230 some AST nodes have a `TokenStream`
cache representing the tokens they were originally parsed from. This
`TokenStream` cache, however, has turned out to not always reflect the current
state of the item when it's being tokenized. For example `#[cfg]` processing or
macro expansion could modify the state of an item. Consequently we've seen a
number of bugs (#48644 and #49846) related to using this stale cache.
This commit tweaks the usage of the cached `TokenStream` to compare it to our
lossy stringification of the token stream. If the tokens that make up the cache
and the stringified token stream are the same then we return the cached version
(which has correct span information). If they differ, however, then we will
return the stringified version as the cache has been invalidated and we just
haven't figured that out.
Closes #48644
Closes #49846
|
|
Update Cargo
This includes https://github.com/rust-lang/cargo/pull/5353, which we want to test via opt-in in the wild.
This'll break RLS, the fix is https://github.com/rust-lang-nursery/rls/pull/822
|
|
Make OnDiskCache thread-safer
I'm not sure if `synthetic_expansion_infos` is handled correctly.
`interpret_alloc_cache` and `interpret_alloc_size` seems to be wrong though, since the code may now decode two `AllocId`s in parallel. I'd like some input on how to fix that.
cc @oli-obk
r? @michaelwoerister
|
|
|
|
|
|
Update Rustfmt
Should fix broken RLS/nightlies
r? @alexcrichton
|
|
|
|
|
|
macros: Remove matching on "complex" nonterminals requiring AST comparisons
So, you can actually use nonterminals from outer macros in left hand side of nested macros and invocations of nested macros will try to match passed arguments to them.
```rust
macro outer($nt_item: item) {
macro inner($nt_item) {
struct S;
}
inner!($nt_item); // OK, `$nt_item` matches `$nt_item`
}
```
Why this is bad:
- We can't do this matching correctly. When two nonterminals are compared, the original tokens are lost and we have to compare AST fragments instead. Right now the comparison is done by `PartialEq` impls derived on AST structures.
- On one hand, AST loses information compared to original tokens (e.g. trailing separators and other simplifications done during parsing to AST), so we can produce matches that are not actually correct.
- On another hand derived `PartialEq` impls for AST structures don't make much sense in general and compare various auxiliary garbage like spans. For the argument nonterminal to match we should use literally the same token (possibly cloned) as was used in the macro LHS (as in the example above). So we can reject matches that are actually correct.
- Support for nonterminal matching is the only thing that forces us to derive `PartialEq` for all (!) AST structures. As I mentioned these impls are also mostly nonsensical.
This PR removes support for matching on all nonterminals except for "simple" ones like `ident`, `lifetime` and `tt` for which we have original tokens that can be compared.
After this is done I'll submit another PR removing huge number of `PartialEq` impls from AST and HIR structures.
This is an arcane feature and I don't personally know why would anyone use it, but the change should ideally go through crater.
We'll be able to support this feature again in the future when all nonterminals have original token streams attached to them in addition to (or instead of) AST fragments.
|
|
Debugging information for the extended tools is currently disabled for
concerns about the size. This patch adds `--enable-debuginfo-tools` to
let one opt into having that debuginfo.
This is useful for debugging the tools in distro packages. We always
strip debuginfo into separate packages anyway, so the extra size is not
a concern in regular use.
|
|
Some modules were still using the deprecated `allocator` module, use the
`alloc` module instead.
Some modules were using `super` while it's not needed.
Some modules were more or less ordering them, and other not, so the
latter have been modified to match the others.
|
|
|
|
Rename must-compile-successfully into compile-pass
Fixes #49568.
r? @Mark-Simulacrum
|
|
|
|
|
|
|
|
|
|
Fix ICE by disallowing `impl Trait` in unsupported position
Fixes #47715.
|
|
This makes it consistent with TypeParameterDef.
|
|
This includes https://github.com/rust-lang/cargo/pull/5353,
which we might want to test via opt-in in the wild
|
|
|
|
[NLL] Fix ICE when a borrow wrapped in a temporary is used after dropped
Fixes #47646
r? @nikomatsakis
|
|
|
|
This commit removes allocation of the panic message in instances like
`panic!("foo: {}", "bar")` if we don't actually end up needing the message. We
don't need it in the case of wasm32 right now, and in general it's not needed
for panic=abort instances that use the default panic hook.
For now this commit only solves the wasm use case where with LTO the allocation
is entirely removed, but the panic=abort use case can be implemented at a later
date if needed.
|
|
The expression `&s[..i]` in general can panic if `i` is out of bounds or not on
a character boundary for a string, and this caused the codegen for
`Formatter::pad` to be a bit larger than it otherwise needed to be. This commit
replaces this with `s.get(..i).unwrap_or(&s)` which while having different
behavior if `i` is out of bounds has a much smaller code footprint and otherwise
avoids the need for `unsafe` code.
|
|
Create one canonical location which panics with "capacity overflow" instead of
having many. This reduces the size of a `panic!("{}", 1)` binary on wasm from
34k to 17k.
|
|
This commit applies a few code size optimizations for the wasm target to
the standard library, namely around panics. We notably know that in most
configurations it's impossible for us to print anything in
wasm32-unknown-unknown so we can skip larger portions of panicking that
are otherwise simply informative. This allows us to get quite a nice
size reduction.
Finally we can also tweak where the allocation happens for the
`Box<Any>` that we panic with. By only allocating once unwinding starts
we can reduce the size of a panicking wasm module from 44k to 350 bytes.
|
|
`Layout` is often used at the core of allocation APIs and is as a result pretty
sensitive to codegen in various circumstances. I was profiling `-C opt-level=z`
with a wasm project recently and noticed that the `unwrap()` wasn't removed
inside of `Layout`, causing the program to be much larger than it otherwise
would be. If inlining were more aggressive LLVM would have figured out that the
panic could be eliminated, but in general the methods here can't panic in the
first place!
As a result this commit makes the following tweaks:
* Removes `unwrap()` and replaces it with `unsafe` in `Layout::new` and
`Layout::for_value`. For posterity though a debug assertion was left behind.
* Removes an `unwrap()` in favor of `?` in the `repeat` method. The comment
indicating that the function call couldn't panic wasn't quite right in that if
`alloc_size` becomes too large and if `align` is high enough it could indeed
cause a panic.
This'll hopefully mean that panics never get introduced into code in the first
place, ensuring that `opt-level=z` is closer to `opt-level=s` in this regard.
|
|
This shows up in allocations of vectors and such, so no need for it to not be
inlined!
|
|
|
|
traits: Implement interning for Goal and Clause
r? @nikomatsakis
Close #49054
Contains some refactoring for the interning mechanism, mainly aimed at reducing pain when changing types of interning map.
This should be mostly good, although I'm not sure with the naming of `Goal::from_poly_domain_goal`.
|
|
Add GlobalAlloc trait + tweaks for initial stabilization
This is the outcome of discussion at the Rust All Hands in Berlin. The high-level goal is stabilizing sooner rather than later the ability to [change the global allocator](https://github.com/rust-lang/rust/issues/27389), as well as allocating memory without abusing `Vec::with_capacity` + `mem::forget`.
Since we’re not ready to settle every detail of the `Alloc` trait for the purpose of collections that are generic over the allocator type (for example the possibility of a separate trait for deallocation only, and what that would look like exactly), we propose introducing separately **a new `GlobalAlloc` trait**, for use with the `#[global_allocator]` attribute.
We also propose a number of changes to existing APIs. They are batched in this one PR in order to minimize disruption to Nightly users.
The plan for initial stabilization is detailed in the tracking issue https://github.com/rust-lang/rust/issues/49668.
CC @rust-lang/libs, @glandium
## Immediate breaking changes to unstable features
* For pointers to allocated memory, change the pointed type from `u8` to `Opaque`, a new public [extern type](https://github.com/rust-lang/rust/issues/43467). Since extern types are not `Sized`, `<*mut _>::offset` cannot be used without first casting to another pointer type. (We hope that extern types can also be stabilized soon.)
* In the `Alloc` trait, change these pointers to `ptr::NonNull` and change the `AllocErr` type to a zero-size struct. This makes return types `Result<ptr::NonNull<Opaque>, AllocErr>` be pointer-sized.
* Instead of a new `Layout`, `realloc` takes only a new size (in addition to the pointer and old `Layout`). Changing the alignment is not supported with `realloc`.
* Change the return type of `Layout::from_size_align` from `Option<Self>` to `Result<Self, LayoutErr>`, with `LayoutErr` a new opaque struct.
* A `static` item registered as the global allocator with the `#[global_allocator]` **must now implement the new `GlobalAlloc` trait** instead of `Alloc`.
## Eventually-breaking changes to unstable features, with a deprecation period
* Rename the respective `heap` modules to `alloc` in the `core`, `alloc`, and `std` crates. (Yes, this does mean that `::alloc::alloc::Alloc::alloc` is a valid path to a trait method if you have `exetrn crate alloc;`)
* Rename the the `Heap` type to `Global`, since it is the entry point for what’s registered with `#[global_allocator]`.
Old names remain available for now, as deprecated `pub use` reexports.
## Backward-compatible changes
* Add a new [extern type](https://github.com/rust-lang/rust/issues/43467) `Opaque`, for use in pointers to allocated memory.
* Add a new `GlobalAlloc` trait shown below. Unlike `Alloc`, it uses bare `*mut Opaque` without `NonNull` or `Result`. NULL in return values indicates an error (of unspecified nature). This is easier to implement on top of `malloc`-like APIs.
* Add impls of `GlobalAlloc` for both the `Global` and `System` types, in addition to existing impls of `Alloc`. This enables calling `GlobalAlloc` methods on the stable channel before `Alloc` is stable. Implementing two traits with identical method names can make some calls ambiguous, but most code is expected to have no more than one of the two traits in scope. Erroneous code like `use std::alloc::Global; #[global_allocator] static A: Global = Global;` (where `Global` is defined to call itself, causing infinite recursion) is not statically prevented by the type system, but we count on it being hard enough to do accidentally and easy enough to diagnose.
```rust
extern {
pub type Opaque;
}
pub unsafe trait GlobalAlloc {
unsafe fn alloc(&self, layout: Layout) -> *mut Opaque;
unsafe fn dealloc(&self, ptr: *mut Opaque, layout: Layout);
unsafe fn alloc_zeroed(&self, layout: Layout) -> *mut Opaque {
// Default impl: self.alloc() and ptr::write_bytes()
}
unsafe fn realloc(&self, ptr: *mut Opaque, old_layout: Layout, new_size: usize) -> *mut Opaque {
// Default impl: self.alloc() and ptr::copy_nonoverlapping() and self.dealloc()
}
fn oom(&self) -> ! {
// intrinsics::abort
}
// More methods with default impls may be added in the future
}
```
## Bikeshed
The tracking issue https://github.com/rust-lang/rust/issues/49668 lists some open questions. If consensus is reached before this PR is merged, changes can be integrated.
|
|
|
|
Implement RFC #2169 (Euclidean modulo).
Tracking issue: #49048
|
|
Run rustfmt on build_helper
Using rustfmt 0.4.1-nightly (e784712f 2018-04-09).
|
