Use the integer sizes LLVM uses, rather than having random projections
laying around. Sizes are u64, Alignments are u32, C_*int is target-dependent
but 64-bit is fine (the int -> C_int conversion is non-precision-losing,
but it can be preceded by `as int` conversions which are, so it is
somewhat ugly. However, being able to suffix a `u` to properly infer
integer types is nice).
RFC 344 proposes a set of naming conventions for lints. This commit
renames existing lints to follow the conventions.
Use the following sed script to bring your code up to date:
```
s/unnecessary_typecast/unused_typecasts/g
s/unsigned_negate/unsigned_negation/g
s/type_limits/unused_comparisons/g
s/type_overflow/overflowing_literals/g
s/ctypes/improper_ctypes/g
s/owned_heap_memory/box_pointers/g
s/unused_attribute/unused_attributes/g
s/path_statement/path_statements/g
s/unused_must_use/unused_must_use/g
s/unused_result/unused_results/g
s/non_uppercase_statics/non_upper_case_globals/g
s/unnecessary_parens/unused_parens/g
s/unnecessary_import_braces/unused_import_braces/g
s/unused_unsafe/unused_unsafe/g
s/unsafe_block/unsafe_blocks/g
s/unused_mut/unused_mut/g
s/unnecessary_allocation/unused_allocation/g
s/missing_doc/missing_docs/g
s/unused_imports/unused_imports/g
s/unused_extern_crate/unused_extern_crates/g
s/unnecessary_qualification/unused_qualifications/g
s/unrecognized_lint/unknown_lints/g
s/unused_variable/unused_variables/g
s/dead_assignment/unused_assignments/g
s/unknown_crate_type/unknown_crate_types/g
s/variant_size_difference/variant_size_differences/g
s/transmute_fat_ptr/fat_ptr_transmutes/g
```
Closes#16545Closes#17932
Due to deprecation, this is a:
[breaking-change]
This commit makes rustc emit debug locations for all call
and invoke statements in LLVM IR, if they are contained
within a function that debuginfo is enabled for. This is
important because LLVM does not handle the case where a
function body containing debuginfo is inlined into another
function with debuginfo, but the inlined call statement
does not have a debug location. In this case, LLVM will
not know where (in terms of source code coordinates) the
function was inlined to and we end up with some statements
still linked to the source locations in there original,
non-inlined function without any indication that they are
indeed an inline-copy. Later, when generating DWARF from
the IR, LLVM will interpret this as corrupt IR and abort.
Unfortunately, the undesirable case described above can
still occur when using LTO. If there is a crate compiled
without debuginfo calling into a crate compiled with
debuginfo, we again end up with the conditions triggering
the error. This is why some LTO tests still fail with the
dreaded assertion, if the standard library was built with
debuginfo enabled.
That is, `RUSTFLAGS_STAGE2=-g make rustc-stage2` will
succeed but `RUSTFLAGS_STAGE2=-g make check` will still
fail after this commit has been merged. This is a problem
that has to be dealt with separately.
Fixes#17201Fixes#15816Fixes#15156
This unifies the `non_snake_case_functions` and `uppercase_variables` lints
into one lint, `non_snake_case`. It also now checks for non-snake-case modules.
This also extends the non-camel-case types lint to check type parameters, and
merges the `non_uppercase_pattern_statics` lint into the
`non_uppercase_statics` lint.
Because the `uppercase_variables` lint is now part of the `non_snake_case`
lint, all non-snake-case variables that start with lowercase characters (such
as `fooBar`) will now trigger the `non_snake_case` lint.
New code should be updated to use the new `non_snake_case` lint instead of the
previous `non_snake_case_functions` and `uppercase_variables` lints. All use of
the `non_uppercase_pattern_statics` should be replaced with the
`non_uppercase_statics` lint. Any code that previously contained non-snake-case
module or variable names should be updated to use snake case names or disable
the `non_snake_case` lint. Any code with non-camel-case type parameters should
be changed to use camel case or disable the `non_camel_case_types` lint.
[breaking-change]
`call_visit_glue` is only ever called from trans_intrinsic, and the
block won't be unreachable there. Also, the comment doesn't make sense
anymore. When the code was introduced in 38fee9526a the function was
also responsible for the cleanup glue, which is no longer the case.
While we're at it, also fixed the debug message to output the right
function name.
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
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.
only known post-monomorphization, and report `transmute` errors before
the code is generated for that `transmute`.
This can break code that looked like:
unsafe fn f<T>(x: T) {
let y: int = transmute(x);
}
Change such code to take a type parameter that has the same size as the
type being transmuted to.
Closes#12898.
[breaking-change]
parameters
This involves numerous substeps:
1. Treat Self same as any other parameter.
2. No longer compute offsets for method parameters.
3. Store all generic types (both trait/impl and method) with a method,
eliminating odd discrepancies.
4. Stop doing unspeakable things to static methods and instead just use
the natural types, now that we can easily add the type parameters from
trait into the method's polytype.
5. No doubt some more. It was hard to separate these into distinct commits.
Fixes#13564
* The select/plural methods from format strings are removed
* The # character no longer needs to be escaped
* The \-based escapes have been removed
* '{{' is now an escape for '{'
* '}}' is now an escape for '}'
Closes#14810
[breaking-change]
ty::substs struct. This is a holdover from the olden days of yore. This patch
removes the last vestiges of that practice. This is part of the work
I was doing on #5527.
This exposes volatile versions of the memset/memmove/memcpy intrinsics.
The volatile parameter must be constant, so this can't simply be a
parameter to our intrinsics.
This comes with a number of fixes to be compatible with upstream LLVM:
* Previously all monomorphizations of "mem::size_of()" would receive the same
symbol. In the past LLVM would silently rename duplicated symbols, but it
appears to now be dropping the duplicate symbols and functions now. The symbol
names of monomorphized functions are now no longer solely based on the type of
the function, but rather the type and the unique hash for the
monomorphization.
* Split stacks are no longer a global feature controlled by a flag in LLVM.
Instead, they are opt-in on a per-function basis through a function attribute.
The rust #[no_split_stack] attribute will disable this, otherwise all
functions have #[split_stack] attached to them.
* The compare and swap instruction now takes two atomic orderings, one for the
successful case and one for the failure case. LLVM internally has an
implementation of calculating the appropriate failure ordering given a
particular success ordering (previously only a success ordering was
specified), and I copied that into the intrinsic translation so the failure
ordering isn't supplied on a source level for now.
* Minor tweaks to LLVM's API in terms of debuginfo, naming, c++11 conventions,
etc.
It's surprising that `RefCell::get()` is implicitly doing a clone
on a value. This patch removes it and replaces all users with
either `.borrow()` when we can autoderef, or `.borrow().clone()`
when we cannot.
