| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This reverts commit c14b615534ebcd5667f594c86d18eebff6afc7cb, reversing
changes made to dda25f2221cc7dd68ed28254665dc7d25e2648ed.
This caused a regression in compiler performance and backporting the fix
to beta was deemed too risky and too challenging, since it is
non-trivial and builds on prior commits in various ways.
Conflicts:
src/librustc/middle/traits/fulfill.rs
src/librustc_data_structures/lib.rs
|
|
Fix #30438.
|
|
|
|
Supersedes https://github.com/rust-lang/rust/pull/30517
Fixes https://github.com/rust-lang/rust/issues/29575
cc @luqmana
r? @nikomatsakis
|
|
|
|
Encountered while I was trying to work on #28518. Please let me know whether this is a correct move.
|
|
|
|
|
|
recognize that it should error
|
|
|
|
|
|
This commit stabilizes and deprecates the FCP (final comment period) APIs for
the upcoming 1.7 beta release. The specific APIs which changed were:
Stabilized
* `Path::strip_prefix` (renamed from `relative_from`)
* `path::StripPrefixError` (new error type returned from `strip_prefix`)
* `Ipv4Addr::is_loopback`
* `Ipv4Addr::is_private`
* `Ipv4Addr::is_link_local`
* `Ipv4Addr::is_multicast`
* `Ipv4Addr::is_broadcast`
* `Ipv4Addr::is_documentation`
* `Ipv6Addr::is_unspecified`
* `Ipv6Addr::is_loopback`
* `Ipv6Addr::is_unique_local`
* `Ipv6Addr::is_multicast`
* `Vec::as_slice`
* `Vec::as_mut_slice`
* `String::as_str`
* `String::as_mut_str`
* `<[T]>::clone_from_slice` - the `usize` return value is removed
* `<[T]>::sort_by_key`
* `i32::checked_rem` (and other signed types)
* `i32::checked_neg` (and other signed types)
* `i32::checked_shl` (and other signed types)
* `i32::checked_shr` (and other signed types)
* `i32::saturating_mul` (and other signed types)
* `i32::overflowing_add` (and other signed types)
* `i32::overflowing_sub` (and other signed types)
* `i32::overflowing_mul` (and other signed types)
* `i32::overflowing_div` (and other signed types)
* `i32::overflowing_rem` (and other signed types)
* `i32::overflowing_neg` (and other signed types)
* `i32::overflowing_shl` (and other signed types)
* `i32::overflowing_shr` (and other signed types)
* `u32::checked_rem` (and other unsigned types)
* `u32::checked_shl` (and other unsigned types)
* `u32::saturating_mul` (and other unsigned types)
* `u32::overflowing_add` (and other unsigned types)
* `u32::overflowing_sub` (and other unsigned types)
* `u32::overflowing_mul` (and other unsigned types)
* `u32::overflowing_div` (and other unsigned types)
* `u32::overflowing_rem` (and other unsigned types)
* `u32::overflowing_neg` (and other unsigned types)
* `u32::overflowing_shl` (and other unsigned types)
* `u32::overflowing_shr` (and other unsigned types)
* `ffi::IntoStringError`
* `CString::into_string`
* `CString::into_bytes`
* `CString::into_bytes_with_nul`
* `From<CString> for Vec<u8>`
* `From<CString> for Vec<u8>`
* `IntoStringError::into_cstring`
* `IntoStringError::utf8_error`
* `Error for IntoStringError`
Deprecated
* `Path::relative_from` - renamed to `strip_prefix`
* `Path::prefix` - use `components().next()` instead
* `os::unix::fs` constants - moved to the `libc` crate
* `fmt::{radix, Radix, RadixFmt}` - not used enough to stabilize
* `IntoCow` - conflicts with `Into` and may come back later
* `i32::{BITS, BYTES}` (and other integers) - not pulling their weight
* `DebugTuple::formatter` - will be removed
* `sync::Semaphore` - not used enough and confused with system semaphores
Closes #23284
cc #27709 (still lots more methods though)
Closes #27712
Closes #27722
Closes #27728
Closes #27735
Closes #27729
Closes #27755
Closes #27782
Closes #27798
|
|
The only way to get a value for a zero-sized type is `undef`, so
there's really no point in actually having a return type other than
void for such types. Also, while the comment in return_type_is_void
mentioned something about aiding C ABI support, @eddyb correctly
pointed out on IRC that there is no such thing as a zero-sized type in
C. And even with clang, which allows empty structs, those get
translated as void return types as well.
Fixes #28766
|
|
Add support to use functions exported using vectorcall.
This essentially only allows to pass a new LLVM calling convention
from rust to LLVM.
```rust
extern "vectorcall" fn abc(param: c_void);
```
references
----
http://llvm.org/docs/doxygen/html/CallingConv_8h_source.html
https://msdn.microsoft.com/en-us/library/dn375768.aspx
|
|
This commit stabilizes and deprecates the FCP (final comment period) APIs for
the upcoming 1.7 beta release. The specific APIs which changed were:
Stabilized
* `Path::strip_prefix` (renamed from `relative_from`)
* `path::StripPrefixError` (new error type returned from `strip_prefix`)
* `Ipv4Addr::is_loopback`
* `Ipv4Addr::is_private`
* `Ipv4Addr::is_link_local`
* `Ipv4Addr::is_multicast`
* `Ipv4Addr::is_broadcast`
* `Ipv4Addr::is_documentation`
* `Ipv6Addr::is_unspecified`
* `Ipv6Addr::is_loopback`
* `Ipv6Addr::is_unique_local`
* `Ipv6Addr::is_multicast`
* `Vec::as_slice`
* `Vec::as_mut_slice`
* `String::as_str`
* `String::as_mut_str`
* `<[T]>::clone_from_slice` - the `usize` return value is removed
* `<[T]>::sort_by_key`
* `i32::checked_rem` (and other signed types)
* `i32::checked_neg` (and other signed types)
* `i32::checked_shl` (and other signed types)
* `i32::checked_shr` (and other signed types)
* `i32::saturating_mul` (and other signed types)
* `i32::overflowing_add` (and other signed types)
* `i32::overflowing_sub` (and other signed types)
* `i32::overflowing_mul` (and other signed types)
* `i32::overflowing_div` (and other signed types)
* `i32::overflowing_rem` (and other signed types)
* `i32::overflowing_neg` (and other signed types)
* `i32::overflowing_shl` (and other signed types)
* `i32::overflowing_shr` (and other signed types)
* `u32::checked_rem` (and other unsigned types)
* `u32::checked_neg` (and other unsigned types)
* `u32::checked_shl` (and other unsigned types)
* `u32::saturating_mul` (and other unsigned types)
* `u32::overflowing_add` (and other unsigned types)
* `u32::overflowing_sub` (and other unsigned types)
* `u32::overflowing_mul` (and other unsigned types)
* `u32::overflowing_div` (and other unsigned types)
* `u32::overflowing_rem` (and other unsigned types)
* `u32::overflowing_neg` (and other unsigned types)
* `u32::overflowing_shl` (and other unsigned types)
* `u32::overflowing_shr` (and other unsigned types)
* `ffi::IntoStringError`
* `CString::into_string`
* `CString::into_bytes`
* `CString::into_bytes_with_nul`
* `From<CString> for Vec<u8>`
* `From<CString> for Vec<u8>`
* `IntoStringError::into_cstring`
* `IntoStringError::utf8_error`
* `Error for IntoStringError`
Deprecated
* `Path::relative_from` - renamed to `strip_prefix`
* `Path::prefix` - use `components().next()` instead
* `os::unix::fs` constants - moved to the `libc` crate
* `fmt::{radix, Radix, RadixFmt}` - not used enough to stabilize
* `IntoCow` - conflicts with `Into` and may come back later
* `i32::{BITS, BYTES}` (and other integers) - not pulling their weight
* `DebugTuple::formatter` - will be removed
* `sync::Semaphore` - not used enough and confused with system semaphores
Closes #23284
cc #27709 (still lots more methods though)
Closes #27712
Closes #27722
Closes #27728
Closes #27735
Closes #27729
Closes #27755
Closes #27782
Closes #27798
|
|
This PR introduces an `ObligationForest` data structure that the fulfillment context can use to track what's going on, instead of the current flat vector. This enables a number of improvements:
1. transactional support, at least for pushing new obligations
2. remove the "errors will be reported" hack -- instead, we only add types to the global cache once their entire subtree has been proven safe. Before, we never knew when this point was reached because we didn't track the subtree.
- this in turn allows us to limit coinductive reasoning to structural traits, which sidesteps #29859
3. keeping the backtrace should allow for an improved error message, where we give the user full context
- we can also remove chained obligation causes
This PR is not 100% complete. In particular:
- [x] Currently, types that embed themselves like `struct Foo { f: Foo }` give an overflow when evaluating whether `Foo: Sized`. This is not a very user-friendly error message, and this is a common beginner error. I plan to special-case this scenario, I think.
- [x] I should do some perf. measurements. (Update: 2% regression.)
- [x] More tests targeting #29859
- [ ] The transactional support is not fully integrated, though that should be easy enough.
- [ ] The error messages are not taking advantage of the backtrace.
I'd certainly like to do 1 through 3 before landing, but 4 and 5 could come as separate PRs.
r? @aturon // good way to learn more about this part of the trait system
f? @arielb1 // already knows this part of the trait system :)
|
|
|
|
a FIXME for later.
|
|
to get the `Sized` error usable, since that hits new users
frequently. Further work is needed for the error reporting for non-Sized
cycle cases; those currently just fallback to the old path. Also adjust tests.
|
|
this makes sure the checks run before typeck (which might use the constant or const
function to calculate an array length) and gives prettier error messages in case of for
loops and such (since they aren't expanded yet).
fixes #30887
r? @pnkfelix
|
|
Also add tests for use of empty structs in cross-crate scenarios
Some tests are commented out, they depend on fixes from https://github.com/rust-lang/rust/pull/30882
|
|
This adds back the raw_pointer_derive lint as a 'removed' lint, so that its removal does not cause errors (#30346) but warnings.
In the process I discovered regressions in the code for renamed and removed lints, which didn't appear to have any tests. The addition of a second lint pass (ast vs. hir) meant that attributes were being inspected twice, renamed and removed warnings printed twice. I restructured the code so these tests are only done once and added tests. Unfortunately it makes the patch more complicated for the needed beta backport.
r? @nikomatsakis
|
|
r=nikomatsakis
This provides limited support for using associated consts on type parameters. It generally works on things that can be figured out at trans time. This doesn't work for array lengths or match arms. I have another patch to make it work in const expressions.
CC @eddyb @nikomatsakis
|
|
This PR changes translation of tuple-like ADTs from being calls to being proper aggregates. This change is done in hope to make code generation better. Namely, now we can avoid:
1. Call overhead;
2. Generating landingpads in presence of cleanups (we know for sure constructing ADTs can’t panic);
3. And probably much more, gaining better MIR introspectablilty.
Along with that a few serious deficiencies with translation of ADTs and switches have been fixed as well (commits 2 and 3).
r? @nikomatsakis
cc @tsion
|
|
These tests test building and matching some non-trivial ADT configurations such as C-like enums and
packed structs.
|
|
In my PR for #21659 I accidentally used `// | help` as test annotation. This PR updates it to `//~| help`. I also found and updated 2 other tests with the same issue.
|
|
The only way to get a value for a zero-sized type is `undef`, so
there's really no point in actually having a return type other than
void for such types. Also, while the comment in return_type_is_void
mentioned something about aiding C ABI support, @eddyb correctly
pointed out on IRC that there is no such thing as a zero-sized type in
C. And even with clang, which allows empty structs, those get
translated as void return types as well.
Fixes #28766
|
|
Add tests for use of empty structs in cross-crate scenarios
|
|
this makes sure the checks run before typeck (which might use the constant or const
function to calculate an array length) and gives prettier error messages in case of for
loops and such (since they aren't expanded yet).
|
|
There is now more structure to the report, so that you can specify e.g. an RFC/PR/issue number and other explanatory details.
Example message:
```
type-parameter-invalid-lint.rs:14:8: 14:9 error: defaults for type parameters are only allowed on type definitions, like `struct` or `enum`
type-parameter-invalid-lint.rs:14 fn avg<T=i32>(_: T) {}
^
type-parameter-invalid-lint.rs:14:8: 14:9 warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
type-parameter-invalid-lint.rs:14:8: 14:9 note: for more information, see PR 30742 <https://github.com/rust-lang/rust/pull/30724>
type-parameter-invalid-lint.rs:11:9: 11:28 note: lint level defined here
type-parameter-invalid-lint.rs:11 #![deny(future_incompatible)]
^~~~~~~~~~~~~~~~~~~
error: aborting due to previous error
```
r? @brson
I would really like feedback also on the specific messages!
Fixes #30746
|
|
This adds support for big endian and little endian PowerPC64.
make check runs clean apart from one big endian backtrace issue.
|
|
This is achieved by adding the scan_back method. This method looks back
through the source_text of the StringReader until it finds the target
char, returning it's offset in the source. We use this method to find
the offset of the opening single quote, and use that offset as the start
of the error.
Given this code:
```rust
fn main() {
let _ = 'abcd';
}
```
The compiler would give a message like:
```
error: character literal may only contain one codepoint: ';
let _ = 'abcd';
^~
```
With this change, the message now displays:
```
error: character literal may only contain one codepoint: 'abcd';
let _ = 'abcd';
^~~~~~~
```
Fixes #30033
|
|
[breaking-change]
`OptLevel` variants are no longer `pub use`ed by rust::session::config. If you are using these variants, you must change your code to prefix the variant name with `OptLevel`.
|
|
|
|
cc #30346
|
|
And fix bustage in make check
|
|
Given this code:
fn main() {
let _ = 'abcd';
}
The compiler would give a message like:
error: character literal may only contain one codepoint: ';
let _ = 'abcd';
^~
With this change, the message now displays:
error: character literal may only contain one codepoint: 'abcd'
let _ = 'abcd'
^~~~~~
Fixes #30033
|
|
Fixes #30831
r? @nikomatsakis
|
|
r=dotdash
Put back alloca zeroing for issues #29092, #30018, #30530; inject zeroing for #30822.
----
Background context: `fn alloca_zeroed` was removed in PR #22969, so we haven't been "zero'ing" (\*) the alloca's since at least that point, but the logic behind that PR seems sound, so its not entirely obvious how *long* the underlying bug has actually been present. In other words, I have not yet done a survey to see when the new `alloc_ty` and `lvalue_scratch_datum` calls were introduced that should have had "zero'ing" the alloca's.
----
I first fixed #30018, then decided to do a survey of `alloc_ty` calls to see if they needed similar treatment, which quickly led to a rediscovery of #30530.
While making the regression test for the latter, I discovered #30822, which is a slightly different bug (in terms of where the "zero'ing" needs to go), but still relevant.
I haven't finished the aforementioned survey of `fn alloc_ty` calls, but I decided I wanted to get this up for review in its current state (namely to see if my attempt to force developers to include a justification for passing `Uninit` can possibly fly, or if I should abandon that path of action).
----
(*): I am putting quotation marks around "zero'ing" because we no longer use zero as our "dropped" marker value.
Fix #29092
Fix #30018
Fix #30530
Fix #30822
|
|
This PR fixes an ICE due to an DiagnosticsBuilder not being canceld or emitted.
Ideally it would use `Handler::cancel`, but I did not manage to get a `&mut` reference to the diagnostics handler.
|
|
Closes #30156.
|
|
|
|
Note that the test for #30822 is folded into the test for #30530 (but
the file name mentions only 30530).
|
|
While adding PowerPC64 support it was noticed that some testcases should
just use target_pointer_width, and others should select between
x86 and !x86.
|
|
This adds support for big endian and little endian PowerPC64.
make check runs clean apart from one big endian backtrace issue.
|
|
|
|
|
|
Fixes #30831
|
|
|
|
|
