This will break code that used the old `Index` trait. Change this code
to use the new `Index` traits. For reference, here are their signatures:
pub trait Index<Index,Result> {
fn index<'a>(&'a self, index: &Index) -> &'a Result;
}
pub trait IndexMut<Index,Result> {
fn index_mut<'a>(&'a mut self, index: &Index) -> &'a mut Result;
}
Closes#6515.
[breaking-change]
LLVM doesn't handle i1 value in allocas/memory very well and skips a number of optimizations if it hits it. So we have to do the same thing that Clang does, using i1 for SSA values, but storing i8 in memory.
Fixes#15203.
LLVM doesn't really like types with a bit-width that isn't a multiple of
8 and disable various optimizations if it encounters such types used
with loads/stores. OTOH, booleans must be represented as i1 when used as
SSA values. To get the best results, we must use i1 for SSA values, and
i8 when storing the value to memory.
By using range asserts on loads, LLVM can eliminate the required
zero-extend and truncate operations.
Fixes#15203
This comit implements a new flag, --extern, which is used to specify where a
crate is located. The purpose of this flag is to bypass the normal crate
loading/matching of the compiler to point it directly at the right file.
This flag takes the form `--extern foo=bar` where `foo` is the name of a crate
and `bar` is the location at which to find the crate. Multiple `--extern`
directives are allowed with the same crate name to specify the rlib/dylib pair
for a crate. It is invalid to specify more than one rlib or more than one dylib,
and it's required that the crates are valid rust crates.
I have also added some extensive documentation to metadata::loader about how
crate loading should work.
RFC: 0035-remove-crate-id
This commit removes all support in the compiler for the #[crate_id] attribute
and all of its derivative infrastructure. A list of the functionality removed is:
* The #[crate_id] attribute no longer exists
* There is no longer the concept of a version of a crate
* Version numbers are no longer appended to symbol names
* The --crate-id command line option has been removed
To migrate forward, rename #[crate_id] to #[crate_name] and only the name of the
crate itself should be mentioned. The version/path of the old crate id should be
removed.
For a transitionary state, the #[crate_id] attribute is still accepted if
the #[crate_name] is not present, but it is warned about if it is the only
identifier present.
RFC: 0035-remove-crate-id
[breaking-change]
In my informal measurements, this brings the peak memory usage when
building librustc from 1662M down to 1502M. Since 1662 - 1502 = 160,
this may not recover the entirety of the observed memory regression
(250M) from PR #14604. (However, according to my local measurements,
the regression when building librustc was more like 209M, so perhaps
this will still recover the lions share of the lost memory.)
This basically meant changing the interface so that no borrowed `&Vec`
is exposed, by hiding `fn get_vec` and `fn get_mut_vec` and revising
`fn all_vecs`.
Instead, clients should use one of the other methods; `get_slice`,
`pop`, `truncate`, `replace`, `push_all`, or `is_empty_in`, which
should work for any case currently used in rustc.
This pull request adds hygiene for 3 kinds of argument bindings:
- arguments to item fns,
- arguments to `ExprFnBlock`s, and
- arguments to `ExprProc`s
It also adds a bunch of unit tests, fixes a few macro uses to be non-capturing, and has a few cleanup items.
local `make check` succeeds.
Closes#15276 (Guide: if)
Closes#15280 (std::os - Add join_paths, make setenv non-utf8 capable)
Closes#15314 (Guide: functions)
Closes#15327 (Simplify PatIdent to contain an Ident rather than a Path)
Closes#15340 (Guide: add mutable binding section)
Closes#15342 (Fix ICE with nested macro_rules!-style macros)
Closes#15350 (Remove duplicated slash in install script path)
Closes#15351 (correct a few spelling mistakes in the tutorial)
Closes#15352 (librustc: Have the kind checker check sub-bounds in trait casts.)
Closes#15359 (Fix spelling errors.)
Closes#15361 (Rename set_broadast() to set_broadcast().)
Closes#15366 (Simplify creating a parser from a token tree)
Closes#15367 (Add examples for StrVector methods)
Closes#15372 (Vec::grow should use reserve_additional, Vec::reserve should check against capacity)
Closes#15373 (Fix minor issues in the documentation of libtime.)
Rationale: for what appear to be historical reasons only, the PatIdent contains
a Path rather than an Ident. This means that there are many places in the code
where an ident is artificially promoted to a path, and---much more problematically---
a bunch of elements from a path are simply thrown away, which seems like an invitation
to some really nasty bugs.
This commit replaces the Path in a PatIdent with a SpannedIdent, which just contains an ident
and a span.
This was causing lots of ICEs in cargo. I sadly wasn't ever able to reduce the
test case down, but I presume that's because it has to do with node id
collisions which are pretty difficult to turn up...
So far, type names generated for debuginfo where a bit sketchy. It was not clearly defined when a name should be fully qualified and when not, if region parameters should be shown or not, and other things like that.
This commit makes the debuginfo module responsible for creating type names instead of using `ppaux::ty_to_str()` and brings type names (as they show up in the DWARF information) in line with GCC and Clang:
* The name of the type being described is unqualified. It's path is defined by its position in the namespace hierarchy.
* Type arguments are always fully qualified, no matter if they would actually be in scope at the type definition location.
Care is also taken to make type names consistent across crate boundaries. That is, the code now tries make the type name the same, regardless if the type is in the local crate or reconstructed from metadata. Otherwise LLVM will complain about violating the one-definition-rule when using link-time-optimization.
This commit also removes all source location information from type descriptions because these cannot be reconstructed for types instantiated from metadata. Again, with LTO enabled, this can lead to two versions of the debuginfo type description, one with and one without source location information, which then triggers the LLVM ODR assertion.
Fortunately, source location information about types is rarely used, so this has little impact. Once source location information is preserved in metadata (#1972) it can also be re-enabled for type descriptions.
`RUSTFLAGS=-g make check` no works again for me locally, including the LTO test cases (note that I've taken care of #15156 by reverting the change in LLVM that @luqmana identified as the culprit for that issue).
So far, type names generated for debuginfo where a bit sketchy. It was not clearly defined when a name should be fully qualified and when not, if region parameters should be shown or not, and other things like that.
This commit makes the debuginfo module responsible for creating type names instead of using ppaux::ty_to_str() and brings type names, as they show up in the DWARF information, in line with GCC and Clang:
* The name of the type being described is unqualified. It's path is defined by its position in the namespace hierarchy.
* Type arguments are always fully qualified, no matter if they would actually be in scope at the type definition location.
Care is also taken to reliably make type names consistent across crate boundaries. That is, the code now tries make the type name the same, regardless if the type is in the local crate or reconstructed from metadata. Otherwise LLVM will complain about violating the one-definition-rule when using link-time-optimization.
This commit also removes all source location information from type descriptions because these cannot be reconstructed for types instantiated from metadata. Again, with LTO enabled, this can lead to two versions of the debuginfo type description, one with and one without source location information, which then triggers the LLVM ODR assertion.
Fortunately, source location information about types is rarely used, so this has little impact. Once source location information is preserved in metadata (#1972) it can also be reenabled for type descriptions.
floating point numbers for real.
This will break code that looks like:
let mut x = 0;
while ... {
x += 1;
}
println!("{}", x);
Change that code to:
let mut x = 0i;
while ... {
x += 1;
}
println!("{}", x);
Closes#15201.
[breaking-change]
This change registers new snapshots, allowing `*T` to be removed from the language. This is a large breaking change, and it is recommended that if compiler errors are seen that any FFI calls are audited to determine whether they should be actually taking `*mut T`.
The f128 type has very little support in the compiler and the feature is
basically unusable today. Supporting half-baked features in the compiler can be
detrimental to the long-term development of the compiler, and hence this feature
is being removed.
This breaks a fair amount of code. The typical patterns are:
* `for _ in range(0, 10)`: change to `for _ in range(0u, 10)`;
* `println!("{}", 3)`: change to `println!("{}", 3i)`;
* `[1, 2, 3].len()`: change to `[1i, 2, 3].len()`.
RFC #30. Closes#6023.
[breaking-change]
The f128 type has very little support in the compiler and the feature is
basically unusable today. Supporting half-baked features in the compiler can be
detrimental to the long-term development of the compiler, and hence this feature
is being removed.
Also change some code formatting.
lint::builtin becomes a sibling of lint::context in order to ensure that lints
implemented there use the same public API as lint plugins.
We're going to have more modules under lint, and the paths get unwieldy. We
also plan to have lints run at multiple points in the compilation pipeline.
The aim of these changes is not working out a generic bi-endianness architectures support but to allow people develop for little endian MIPS machines (issue #7190).
We currently compiled bools to i8 values, because there was a bug in
LLVM that sometimes caused miscompilations when using i1 in, for
example, structs.
Using i8 means a lot of unnecessary zero-extend and truncate operations
though, since we have to convert the value from and to i1 when using for
example icmp or br instructions. Besides the unnecessary overhead caused
by this, it also sometimes made LLVM miss some optimizations.
Fixes#8106.
To fix#8106, we need an LLVM version that contains r211082 aka 0dee6756
which fixes a bug that blocks that issue.
There have been some tiny API changes in LLVM, and cmpxchg changed its
return type. The i1 part of the new return type is only interesting when
using the new weak cmpxchg, which we don't do.
