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).
This is just a cleanup of the code. Doesn't really change anything deep about the way we operate. This is a prelude to implementing a good solution for one-way matching for #5527.
r? @pnkfelix (we were just crawling about this code, after all)
In other words, Late-bound regions that occur non-free should be
skipped.
Fix#10846 (specifically the ICE, not the weakness in the current type inference).
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.
First, we have to fix some bugs concerning the handling of
attributes in foreign function declarations and calls. These
are required because the i1 type needs the ZExt attribute when
used as a function parameter or return type.
Then we have to update LLVM to get a bugfix without which LLVM
sometimes generates broken code when using i1.
And then, finally, we can switch bools over to i1.
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.
When calling a foreign function, some arguments and/or return value
attributes are required to conform to the foreign ABI. Currently those
attributes are only added to the declaration of foreign functions. With
direct calls, this is no problem, because LLVM can see that those
attributes apply to the call. But with an indirect call, LLVM cannot do
that and the attribute is missing.
To fix that, we have to add those attribute to the calls to foreign
functions as well.
This also allows to remove the special handling of the SRet attribute,
which is ABI-dependent and will be set via the `attr` field of the
return type's `ArgType`.
The ArgType type gives us a generic way to specify an attribute for a
type to ensure ABI conformance for foreign functions. But the code that
actually sets the argument attributes in the function declaration
only sets the attribute for the return type when the type is indirect.
Since LLVMAddAttribute() doesn't allow to set attributes on the return
type, we have to use LLVMAddFunctionAttribute() instead.
This didn't cause problems yet, because currently only some indirect
types require attributes to be set.
This commit makes several changes to the stability index infrastructure:
* Stability levels are now inherited lexically, i.e., each item's
stability level becomes the default for any nested items.
* The computed stability level for an item is stored as part of the
metadata. When using an item from an external crate, this data is
looked up and cached.
* The stability lint works from the computed stability level, rather
than manual stability attribute annotations. However, the lint still
checks only a limited set of item uses (e.g., it does not check every
component of a path on import). This will be addressed in a later PR,
as part of issue #8962.
* The stability lint only applies to items originating from external
crates, since the stability index is intended as a promise to
downstream crates.
* The "experimental" lint is now _allow_ by default. This is because
almost all existing crates have been marked "experimental", pending
library stabilization. With inheritance in place, this would generate
a massive explosion of warnings for every Rust program.
The lint should be changed back to deny-by-default after library
stabilization is complete.
* The "deprecated" lint still warns by default.
The net result: we can begin tracking stability index for the standard
libraries as we stabilize, without impacting most clients.
Closes#13540.
This commit makes several changes to the stability index infrastructure:
* Stability levels are now inherited lexically, i.e., each item's
stability level becomes the default for any nested items.
* The computed stability level for an item is stored as part of the
metadata. When using an item from an external crate, this data is
looked up and cached.
* The stability lint works from the computed stability level, rather
than manual stability attribute annotations. However, the lint still
checks only a limited set of item uses (e.g., it does not check every
component of a path on import). This will be addressed in a later PR,
as part of issue #8962.
* The stability lint only applies to items originating from external
crates, since the stability index is intended as a promise to
downstream crates.
* The "experimental" lint is now _allow_ by default. This is because
almost all existing crates have been marked "experimental", pending
library stabilization. With inheritance in place, this would generate
a massive explosion of warnings for every Rust program.
The lint should be changed back to deny-by-default after library
stabilization is complete.
* The "deprecated" lint still warns by default.
The net result: we can begin tracking stability index for the standard
libraries as we stabilize, without impacting most clients.
Closes#13540.
Closes#14480 (vim: Add :RustRun and associated commands)
Closes#14917 (Deprecate free-standing endian conversions in favor of methods on Int. Merge Bitwise into Int and add more bit operations.)
Closes#14981 (librustc: Use expr_ty_adjusted in trans_overloaded_call.)
Closes#14989 (std::task - Revamp TaskBuilder API)
Closes#14997 (Reject double moves out of array elements)
Closes#14998 (Vim: highlight escapes for byte literals.)
Closes#15002 (Fix FIXME #5275)
Closes#15004 (Fix#14865)
Closes#15007 (debuginfo: Add test case for issue #14411.)
Closes#15012 ((doc) Change search placeholder text.)
Closes#15013 (Update compiler-rt.)
Closes#15017 (Deprecate the bytes!() macro.)
Replace its usage with byte string literals, except in `bytes!()` tests.
Also add a new snapshot, to be able to use the new b"foo" syntax.
The src/etc/2014-06-rewrite-bytes-macros.py script automatically
rewrites `bytes!()` invocations into byte string literals.
Pass it filenames as arguments to generate a diff that you can inspect,
or `--apply` followed by filenames to apply the changes in place.
Diffs can be piped into `tip` or `pygmentize -l diff` for coloring.
Fixes a codegen bug which generates illegal non-terminated LLVM block
when there are wildcard pattern with guard and enum patterns in a match
expression. Also refactors the code a little.
Closes#14865
Details: in a program like:
```
type T = proc(int) -> int; /* 4 */
pub fn outer(captured /* pat 16 */: T) -> T {
(proc(x /* pat 23 */) {
((captured /* 29 */).foo((x /* 30 */)) /* 28 */)
} /* block 27 */ /* 20 */)
} /* block 19 */ /* 12 */
```
the `captured` arg is moved from the outer fn into the inner proc (id=20).
The old dataflow analysis for flowed_move_data_moves, when looking at
the inner proc, would attempt to add a kill bit for `captured` at the
end of its scope; the problem is that it thought the end of the
`captured` arg's scope was the outer fn (id=12), even though at that
point in the analysis, the `captured` arg's scope should now be
restricted to the proc itself (id=20).
This patch fixes handling of upvars so that dataflow of a fn/proc
should never attempts to add a gen or kill bit to any NodeId outside
of the current fn/proc. It accomplishes this by adding an `LpUpvar`
variant to `borrowck::LoanPath`, so for cases like `captured` above
will carry both their original `var_id`, as before, as well as the
`NodeId` for the closure that is capturing them.
As a drive-by fix to another occurrence of a similar bug that
nikomatsakis pointed out to me earlier, this also fixes
`gather_loans::compute_kill_scope` so that it computes the kill scope
of the `captured` arg to be block 27; that is, the block for the proc
itself (id=20).
(This is an updated version that generalizes the new loan path variant
to cover all upvars, and thus renamed the variant from `LpCopiedUpvar`
to just `LpUpvar`.)
Fix#6298.
This is instead of the prior approach of emulating cfg traversal
privately by traversing AST in same way).
Of special note, this removes a special case handling of `ExprParen`
that was actually injecting a bug (since it was acting like an
expression like `(*func)()` was consuming `*func` *twice*: once from
`(*func)` and again from `*func`). nikomatsakis was the first one to
point out that it might suffice to simply have the outer `ExprParen`
do the consumption of the contents (alone).
(This version has been updated to incorporate feedback from Niko's
review of PR 14873.)
1. After recursively processing an ExprWhile, need to pop loop_scopes
the same way we do for ExprLoop.
2. Proposed fix for flowgraph handling of ExprInlineAsm: we need to
represent the flow into the subexpressions of an `asm!` block.
