| Age | Commit message (Collapse) | Author | Lines |
|---|
|
When warnings and errors occur, the associated help message should not print the same code snippet.
https://github.com/rust-lang/rust/issues/21938
|
|
|
|
Fixes #19674
Fixes #17396 (already closed, yeah)
cc @kmcallister , @cmr
|
|
This commit deprecates the majority of std::old_io::fs in favor of std::fs and
its new functionality. Some functions remain non-deprecated but are now behind a
feature gate called `old_fs`. These functions will be deprecated once
suitable replacements have been implemented.
The compiler has been migrated to new `std::fs` and `std::path` APIs where
appropriate as part of this change.
|
|
|
|
This allows to create proper debuginfo line information for items inlined from other crates (e.g. instantiations of generics).
Only the codemap's 'metadata' is stored in a crate's metadata. That is, just filename, line-beginnings, etc. but not the actual source code itself. We are thus missing the opportunity of making Rust the first "open-source-only" programming language out there. Pity.
|
|
Many of the modifications putting in `Box::new` calls also include a
pointer to Issue 22405, which tracks going back to `box <expr>` if
possible in the future.
(Still tried to use `Box<_>` where it sufficed; thus some tests still
have `box_syntax` enabled, as they use a mix of `box` and `Box::new`.)
Precursor for overloaded-`box` and placement-`in`; see Issue 22181.
|
|
Rebase and follow-through on work done by @cmr and @aatch.
Implements most of rust-lang/rfcs#560. Errors encountered from the checks during building were fixed.
The checks for division, remainder and bit-shifting have not been implemented yet.
See also PR #20795
cc @Aatch ; cc @nikomatsakis
|
|
|
|
This changes the type of some public constants/statics in libunicode.
Notably some `&'static &'static [(char, char)]` have changed
to `&'static [(char, char)]`. The regexp crate seems to be the
sole user of these, yet this is technically a [breaking-change]
|
|
The API this exposes is a little strange (being attached to `static`s),
so it makes sense to conservatively feature gate it. If it is highly
popular, it is possible to reverse this gating.
|
|
|
|
Many of the core rust libraries have places that rely on integer
wrapping behaviour. These places have been altered to use the wrapping_*
methods:
* core::hash::sip - A number of macros
* core::str - The `maximal_suffix` method in `TwoWaySearcher`
* rustc::util::nodemap - Implementation of FnvHash
* rustc_back::sha2 - A number of macros and other places
* rand::isaac - Isaac64Rng, changed to use the Wrapping helper type
Some places had "benign" underflow. This is when underflow or overflow
occurs, but the unspecified value is not used due to other conditions.
* collections::bit::Bitv - underflow when `self.nbits` is zero.
* collections::hash::{map,table} - Underflow when searching an empty
table. Did cause undefined behaviour in this case due to an
out-of-bounds ptr::offset based on the underflowed index. However the
resulting pointers would never be read from.
* syntax::ext::deriving::encodable - Underflow when calculating the
index of the last field in a variant with no fields.
These cases were altered to avoid the underflow, often by moving the
underflowing operation to a place where underflow could not happen.
There was one case that relied on the fact that unsigned arithmetic and
two's complement arithmetic are identical with wrapping semantics. This
was changed to use the wrapping_* methods.
Finally, the calculation of variant discriminants could overflow if the
preceeding discriminant was `U64_MAX`. The logic in `rustc::middle::ty`
for this was altered to avoid the overflow completely, while the
remaining places were changed to use wrapping methods. This is because
`rustc::middle::ty::enum_variants` now throws an error when the
calculated discriminant value overflows a `u64`.
This behaviour can be triggered by the following code:
```
enum Foo {
A = U64_MAX,
B
}
```
This commit also implements the remaining integer operators for
Wrapped<T>.
|
|
The API this exposes is a little strange (being attached to `static`s),
so it makes sense to conservatively feature gate it. If it is highly
popular, it is possible to reverse this gating.
|
|
|
|
This changes the type of some public constants/statics in libunicode.
Notably some `&'static &'static [(char, char)]` have changed
to `&'static [(char, char)]`. The regexp crate seems to be the
sole user of these, yet this is technically a [breaking-change]
|
|
|
|
Fixing #21475. Right now this code can not be parsed:
```rust
use m::{START, END};
fn main() {
match 42u32 {
m::START...m::END => {}, // error: expected one of `::`, `=>`, or `|`, found `...`
_ => {},
}
}
mod m {
pub const START: u32 = 4;
pub const END: u32 = 14;
}
```
I fixed the parser and added test for this case, but now there are still problems with mixing literals and paths in interval:
```rust
match 42u32 {
0u32...m::END => {}, // mismatched types in range [E0031]
m::START...59u32 => {}, // mismatched types in range [E0031]
_ => {},
}
}
```
I'll try fix this problem and need review.
|
|
This is leftover from #21843
If you still have `|&:| {}` closures in your code, simply remove the `&:` part.
[breaking-change]
|
|
MacEager is a MacResult implementation for the common case where you've already built each form of AST that you might return.
Fixes #17637. Based on #18814.
This is a [breaking-change] for syntax extensions:
* MacExpr::new becomes MacEager::expr.
* MacPat::new becomes MacEager::pat.
* MacItems::new becomes MacEager::items. It takes a SmallVector directly,
not an iterator.
r? @sfackler
|
|
Now that the `std::env` module has had some time to bake this commit marks most
of its APIs as `#[stable]`. Some notable APIs that are **not** stable (and still
use the same `env` feature gate) are:
* `{set,get}_exit_status` - there are still questions about whether this is the
right interface for setting/getting the exit status of a process.
* `page_size` - this may change location in the future or perhaps name as well.
This also effectively closes #22122 as the variants of `VarError` are
`#[stable]` now. (this is done intentionally)
|
|
|
|
|
|
|
|
closes #22881
|
|
Now that the `std::env` module has had some time to bake this commit marks most
of its APIs as `#[stable]`. Some notable APIs that are **not** stable (and still
use the same `env` feature gate) are:
* `{set,get}_exit_status` - there are still questions about whether this is the
right interface for setting/getting the exit status of a process.
* `page_size` - this may change location in the future or perhaps name as well.
This also effectively closes #22122 as the variants of `VarError` are
`#[stable]` now. (this is done intentionally)
|
|
MacEager is a MacResult implementation for the common case where you've already
built each form of AST that you might return.
Fixes #17637. Based on #18814.
This is a [breaking-change] for syntax extensions:
* MacExpr::new becomes MacEager::expr.
* MacPat::new becomes MacEager::pat.
* MacItems::new becomes MacEager::items. It takes a SmallVector directly,
not an iterator.
|
|
|
|
Fixes #21370.
`unused-macro-with-follow-violation.rs` was already handled correctly. That test is just for good measure. :)
I have a more involved plan to clean this up, but it ran into difficulties such as #22814.
|
|
|
|
|
|
Fixes #21370.
unused-macro-with-follow-violation.rs was already handled correctly. That test
is just for good measure. :)
|
|
r=alexcrichton
Turn `unsafe_no_drop_flag` back into a gated-feature.
Fix #22173
|
|
r? @steveklabnik
|
|
Fix #22173
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
fmt and hash are pretty straightforward I think. sync is a bit more complex. I thought one or two of the `isize`s ought to be `i32`s, but that would require a bunch of casting (the root cause being the lack of atomics other than isize/usize).
r? @alexcrichton
|
|
This is one more step towards completing #13231
This series of commits add support for default trait implementations. The changes in this PR don't break existing code and they are expected to preserve the existing behavior in the compiler as far as built-in bounds checks go.
The PR adds negative implementations of `Send`/`Sync` for some types and it removes the special cases for `Send`/`Sync` during the trait obligations checks. That is, it now fully relies on the traits check rather than lang items.
Once this patch lands and a new snapshot is created, it'll be possible to add default impls for `Send` and `Sync` and remove entirely the use of `BuiltinBound::{BoundSend,BoundSync}` for positive implementations as well.
This PR also removes the restriction on negative implementations. That is, it is now possible to add negative implementations for traits other than `Send`/`Sync`
|
|
|
|
|
|
|
|
Please see discussion in #19284 .
|
|
This is not a complete implementation of the RFC:
- only existing methods got updated, no new ones added
- doc comments are not extensive enough yet
- optimizations got lost and need to be reimplemented
See https://github.com/rust-lang/rfcs/pull/528
Technically a
[breaking-change]
|
