| Age | Commit message (Collapse) | Author | Lines |
|---|
|
parser: support paths in bang macro invocations (e.g. `path::to::macro!()`)
r? @nrc
|
|
|
|
|
|
|
|
Change error message for intrinsic signature.
Makes it so the signature of the intrinsic in the user's code is
"found," while the signature that rustc knows about is "expected."
Before this patch, the code
```
extern "platform-intrinsic" {
fn x86_mm_movemask_ps() -> i32;
}
```
would give the error
```
error[E0444]: platform-specific intrinsic has invalid number of arguments: found 1, expected 0
--> test.rs:4:5
|
4 | fn x86_mm_movemask_ps() -> i32;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to previous error
```
After this patch, it says "found 0, expected 1".
|
|
|
|
|
|
|
|
Forbid user-defined macros named "macro_rules"
This is a [breaking-change].
r? @nrc
|
|
this commit corrects E0520 error text.
See referenced issue for further info
r? @nrc
|
|
|
|
|
|
|
|
|
|
Don't let a type parameter named "Self" unchanged past HIR lowering.
Fixes #36638 by rewriting `Self` type parameters (which are a parse error) to a `gensym("Self")`.
Background: #35605 introduced code across rustc that determines `Self` by its keyword name.
Reverting the sanity checks around that would inadvertently cause confusion between the true `Self` of a `trait` and other type parameters named `Self` (which have caused parse errors already).
I do not like to use `gensym`, and we may do something different here in the future, but this should work.
|
|
binding in generics.
|
|
|
|
Fix ICE test in compiletest fail-tests
While working on Clippy which uses *compiletest*, I noticed that as long as all expected error are found, *compile-fail* tests will be marked *ok* even if there is an ICE. One function seems to have not been updated with JSON errors because ICEs are now reported like this:
```json
{"message":"../src/librustc/ty/context.rs:161: Attempted to intern `_` which contains inference types/regions in the global type context","code":null,"level":"error: internal compiler error","spans":[],"children":[],"rendered":null}
```
I don't think I can add a test for that.
I guess:
r? @nikomatsakis
|
|
|
|
Updated E0560 to new error format
Added a small bit of code to add a label for E0560.
Also renamed src/test/compile-fail/E560.rs file to E0560.rs (not sure why it was named E560).
Updated all test cases which check this error.
Closes #36199
|
|
|
|
|
|
macros: allow attribute invocations at the crate root
Fixes #36617.
r? @nrc
|
|
this commit correct E0502 error text.
See referenced issue for further info
|
|
|
|
|
|
|
|
|
|
|
|
correctly cancel some errors
Fixes #36499.
I also (proactively) changed all other calls in `parser.rs` to use `Handler::cancel`.
|
|
Rollup of 8 pull requests
- Successful merges: #36383, #36424, #36480, #36484, #36505, #36509, #36519, #36521
- Failed merges:
|
|
Update E0049 to new error format
Fixes #35210.
Part of #35233.
r? @jonathandturner
|
|
|
|
The wording of RFC #495 enables moves out of slices. Unfortuantely, non-zeroing
moves out of slices introduce a very annoying complication: as slices can
vary in their length, indexes from the start and end may or may not overlap
depending on the slice's exact length, which prevents assigning a particular
drop flag for each individual element.
For example, in the code
```Rust
fn foo<T>(a: Box<[Box<[T]>]>, c: bool) -> T {
match (a, c) {
(box [box [t, ..], ..], true) => t,
(box [.., box [.., t]], false) => t,
_ => panic!()
}
}
```
If the condition is false, we have to drop the first element
of `a`, unless `a` has size 1 in which case we drop all the elements
of it but the last.
If someone comes with a nice way of handling it, we can always re-allow
moves out of slices.
This is a [breaking-change], but it is behind the `slice_patterns` feature
gate and was not allowed until recently.
|
|
|
|
clear obligations-added flag with nested fulfillcx
This flag is a debugging measure designed to detect cases where we start
a snapshot, create type variables, register obligations involving those
type variables in the fulfillment cx, and then have to unroll the
snapshot, leaving "dangling type variables" behind. HOWEVER, in some
cases the flag is wrong. In particular, we sometimes create a
"mini-fulfilment-cx" in which we enroll obligations. As long as this
fulfillment cx is fully drained before we return, this is not a problem,
as there won't be any escaping obligations in the main cx. So we add a
fn to save/restore the flag.
Fixes #36053.
r? @arielb1
|
|
Assign node ids during macro expansion
After this PR,
- The `ExtCtxt` can access `resolve`'s `Resolver` through the trait object `ext::base::Resolver`.
- The `Resolver` trait object can load macros and replaces today's `MacroLoader` trait object.
- The macro expander uses the `Resolver` trait object to resolve macro invocations.
- The macro expander assigns node ids and builds the `Resolver`'s `macros_at_scope` map.
- This is groundwork for merging import resolution and expansion.
- Performance of expansion together with node id assignment improves by ~5%.
**EDIT:** Since Github is reordering the commits, here is `git log`:
- b54e1e399741579612f13e2df98a25ea9447989d: Differentiate between monotonic and non-monotonic expansion and only assign node ids during monotonic expansion.
- 78c00398780db6f59ebf43e765fa9368dad436d2: Expand generated test harnesses and macro registries.
- f3c2dca3539e6edc745f9c91898cb97d281865c1: Remove scope placeholders from the crate root.
- c86c8d41a26b2037e80c9fd028a59313a78b3a66: Perform node id assignment and `macros_at_scope` construction during the `InvocationCollector` and `PlaceholderExpander` folds.
- 72a636975fc5d0bb4af45af7bdd97987cc722a6a: Move macro resolution into `librustc_resolve`.
- 20b43b23230ce063ccf99a4841d85790ad311bdf: Rewrite the unit tests in `ext/expand.rs` as a `compile-fail` test.
- a9821e1658240bb2c056f260a4b6bc9789301fae: Refactor `ExtCtxt` to use a `Resolver` instead of a `MacroLoader`.
- 60440b226d2f70bdae803443ff7ad2e2af2c9b10: Refactor `noop_fold_stmt_kind` out of `noop_fold_stmt`.
- 50f94f6c95c944f08c4af264f48260e42efefd47: Avoid needless reexpansions.
r? @nrc
|
|
fix "X is not a member of trait Y" span labels
Fixes #36428.
|
|
Improve shallow `Clone` deriving
`Copy` unions now support `#[derive(Clone)]`.
Less code is generated for `#[derive(Clone, Copy)]`.
+
Unions now support `#[derive(Eq)]`.
Less code is generated for `#[derive(Eq)]`.
---
Example of code reduction:
```
enum E {
A { a: u8, b: u16 },
B { c: [u8; 100] },
}
```
Before:
```
fn clone(&self) -> E {
match (&*self,) {
(&E::A { a: ref __self_0, b: ref __self_1 },) => {
::std::clone::assert_receiver_is_clone(&(*__self_0));
::std::clone::assert_receiver_is_clone(&(*__self_1));
*self
}
(&E::B { c: ref __self_0 },) => {
::std::clone::assert_receiver_is_clone(&(*__self_0));
*self
}
}
}
```
After:
```
fn clone(&self) -> E {
{
let _: ::std::clone::AssertParamIsClone<u8>;
let _: ::std::clone::AssertParamIsClone<u16>;
let _: ::std::clone::AssertParamIsClone<[u8; 100]>;
*self
}
}
```
All the matches are removed, bound assertions are more lightweight.
`let _: Checker<CheckMe>;`, unlike `checker(&check_me);`, doesn't have to be translated by rustc_trans and then inlined by LLVM, it doesn't even exist in MIR, this means faster compilation.
---
Union impls are generated like this:
```
union U {
a: u8,
b: u16,
c: [u8; 100],
}
```
```
fn clone(&self) -> U {
{
let _: ::std::clone::AssertParamIsCopy<Self>;
*self
}
}
```
Fixes https://github.com/rust-lang/rust/issues/36043
cc @durka
r? @alexcrichton
|
|
Make `private_in_public` compatibility lint warn-by-default again
More details: https://internals.rust-lang.org/t/regression-report-stable-2016-08-16-vs-beta-2016-08-26/3930/10
r? @nikomatsakis
|
|
|
|
This flag is a debugging measure designed to detect cases where we start
a snapshot, create type variables, register obligations involving those
type variables in the fulfillment cx, and then have to unroll the
snapshot, leaving "dangling type variables" behind. HOWEVER, in some
cases the flag is wrong. In particular, we sometimes create a
"mini-fulfilment-cx" in which we enroll obligations. As long as this
fulfillment cx is fully drained before we return, this is not a problem,
as there won't be any escaping obligations in the main cx. So we add a
fn to save/restore the flag.
|
|
crate-ify compiler-rt into compiler-builtins
libcompiler-rt.a is dead, long live libcompiler-builtins.rlib
This commit moves the logic that used to build libcompiler-rt.a into a
compiler-builtins crate on top of the core crate and below the std crate.
This new crate still compiles the compiler-rt instrinsics using gcc-rs
but produces an .rlib instead of a static library.
Also, with this commit rustc no longer passes -lcompiler-rt to the
linker. This effectively makes the "no-compiler-rt" field of target
specifications a no-op. Users of `no_std` will have to explicitly add
the compiler-builtins crate to their crate dependency graph *if* they
need the compiler-rt intrinsics - this is a [breaking-change]. Users
of the `std` have to do nothing extra as the std crate depends
on compiler-builtins.
Finally, this a step towards lazy compilation of std with Cargo as the
compiler-rt intrinsics can now be built by Cargo instead of having to
be supplied by the user by some other method.
closes #34400
---
r? @alexcrichton
|
|
Update E0297 to new error format
Fixes #35521.
Part of #35233.
I didn't attempt the bonus of narrowing the span to focus on the "for `<pattern>`" piece (it's my first time contributing), but I'm happy to do so given some hints.
r? @jonathandturner
|
|
|
|
libcompiler-rt.a is dead, long live libcompiler-builtins.rlib
This commit moves the logic that used to build libcompiler-rt.a into a
compiler-builtins crate on top of the core crate and below the std crate.
This new crate still compiles the compiler-rt instrinsics using gcc-rs
but produces an .rlib instead of a static library.
Also, with this commit rustc no longer passes -lcompiler-rt to the
linker. This effectively makes the "no-compiler-rt" field of target
specifications a no-op. Users of `no_std` will have to explicitly add
the compiler-builtins crate to their crate dependency graph *if* they
need the compiler-rt intrinsics. Users of the `std` have to do nothing
extra as the std crate depends on compiler-builtins.
Finally, this a step towards lazy compilation of std with Cargo as the
compiler-rt intrinsics can now be built by Cargo instead of having to
be supplied by the user by some other method.
closes #34400
|
|
The span labels for associated types and consts were hardcoded to `Foo`
rather than substituting the name of the trait.
This also normalizes the wording for associated methods', traits', and
consts' span labels.
Fixes #36428.
|
|
fix span for errors E0537, E0535 & E0536
fix #36182 as part of #35233
|
|
Add s390x support
This adds support for building the Rust compiler and standard
library for s390x-linux, allowing a full cross-bootstrap sequence
to complete. This includes:
- Makefile/configure changes to allow native s390x builds
- Full Rust compiler support for the s390x C ABI
(only the non-vector ABI is supported at this point)
- Port of the standard library to s390x
- Update the liblibc submodule to a version including s390x support
- Testsuite fixes to allow clean "make check" on s390x
Caveats:
- Resets base cpu to "z10" to bring support in sync with the default
behaviour of other compilers on the platforms. (Usually, upstream
supports all older processors; a distribution build may then chose
to require a more recent base version.) (Also, using zEC12 causes
failures in the valgrind tests since valgrind doesn't fully support
this CPU yet.)
- z13 vector ABI is not yet supported. To ensure compatible code
generation, the -vector feature is passed to LLVM. Note that this
means that even when compiling for z13, no vector instructions
will be used. In the future, support for the vector ABI should be
added (this will require common code support for different ABIs
that need different data_layout strings on the same platform).
- Two test cases are (temporarily) ignored on s390x to allow passing
the test suite. The underlying issues still need to be fixed:
* debuginfo/simd.rs fails because of incorrect debug information.
This seems to be a LLVM bug (also seen with C code).
* run-pass/union/union-basic.rs simply seems to be incorrect for
all big-endian platforms.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
|
|
|
