Extend rustc::middle::dataflow to allow filtering kills from flow-exits.
Fix borrowck analysis so that it will not treat a break that pops through an assignment
```rust
x = { ... break; ... }
```
as a kill of the "moved-out" bit for `x`.
Fix#24267.
[breaking-change], but really, its only breaking code that was already buggy.
* In `noop_fold_expr`, call `new_span` in these cases:
- `ExprMethodCall`'s identifier
- `ExprField`'s identifier
- `ExprTupField`'s integer
Calling `new_span` for `ExprMethodCall`'s identifier is necessary to print
an acceptable diagnostic for `write!(&2, "")`. We see this error:
```
<std macros>:2:20: 2:66 error: type `&mut _` does not implement any method in scope named `write_fmt`
<std macros>:2 ( & mut * $ dst ) . write_fmt ( format_args ! ( $ ( $ arg ) * ) ) )
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
With this change, we also see a macro expansion backtrace leading to
the `write!(&2, "")` call site.
* After fully expanding a macro, we replace the expansion expression's
span with the original span. Call `fld.new_span` to add a backtrace to
this span. (Note that I'm call `new_span` after `bt.pop()`, so the macro
just expanded isn't on the backtrace.)
The motivating example for this change is `println!("{}")`. The format
string literal is `concat!($fmt, "arg")` and is inside the libstd macro.
We need to see the backtrace to find the `println!` call site.
* Add a backtrace to the `format_args!` format expression span.
r? alexcrichton
Addresses #23459
We provide tools to tell what exact symbols to emit for any fn or static, but
don’t quite check if that won’t cause any issues later on. Some of the issues
include LLVM mangling our names again and our names pointing to wrong locations,
us generating dumb foreign call wrappers, linker errors, extern functions
resolving to different symbols altogether (`extern {fn fail();} fail();` in some
cases calling `fail1()`), etc.
Before the commit we had a function called `note_unique_llvm_symbol`, so it is
clear somebody was aware of the issue at some point, but the function was barely
used, mostly in irrelevant locations.
Along with working on it I took liberty to start refactoring trans/base into
a few smaller modules. The refactoring is incomplete and I hope I will find some
motivation to carry on with it.
This is possibly a [breaking-change] because it makes dumbly written code
properly invalid.
This fixes all those issues about incorrect use of #[no_mangle] being not reported/misreported/ICEd by the compiler.
NB. This PR does not attempt to tackle the parallel codegen issue that was mentioned in https://github.com/rust-lang/rust/pull/22811, but I believe it should be very straightforward in a follow up PR by modifying `trans::declare::get_defined_value` to look at all the contexts.
cc @alexcrichton @huonw @nrc because you commented on the original RFC issue.
EDIT: wow, this became much bigger than I initially intended.
Don't use skolemized parameters but rather fresh variables in coherence. Skolemized parameters wind up preventing unification. Surprised we had no test for this! Fixes#24241.
r? @pnkfelix
Example showing sample inputs, old message, new message:
https://gist.github.com/nikomatsakis/11126784ac678b7eb6ba
Also adds infrastructure for reporting suggestions \"in situ\" and does some (minor) cleanups to `CodeMap`.
r? @brson
Statement macros are now treated somewhat like item macros, in that a statement macro can now expand into a series of statements, rather than just a single statement.
This allows statement macros to be nested inside other kinds of macros and expand properly, where previously the expansion would only work when no nesting was present.
See:
- `src/test/run-pass/macro-stmt_macro_in_expr_macro.rs`
- `src/test/run-pass/macro-nested_stmt_macro.rs`
This changes the interface of the MacResult trait. make_stmt has become make_stmts and now returns a vector, rather than a single item. Plugin writers who were implementing MacResult will have breakage, as well as anyone using MacEager::stmt.
See:
- `src/libsyntax/ext/base.rs`
This also causes a minor difference in behavior to the diagnostics produced by certain malformed macros.
See:
- `src/test/compile-fail/macro-incomplete-parse.rs`
This is a really minor issue. I noticed some tests no longer need the ignore
tidy comment directive.
A quick grep turned up the following files:
src/test/compile-fail/bad-mid-path-type-params.rs
src/test/compile-fail/bad-sized.rs
src/test/compile-fail/coherence-default-trait-impl.rs
src/test/compile-fail/coherence-orphan.rs
src/test/compile-fail/issue-8767.rs
src/test/compile-fail/lint-stability.rs
src/test/compile-fail/lint-uppercase-variables.rs
src/test/compile-fail/typeck-default-trait-impl-outside-crate.rs
src/test/compile-fail/use-after-move-implicity-coerced-object.rs
src/test/debuginfo/gdb-pretty-std.rs
It didn't seem like it was worth opening an issue for this, but if that is not
the case (i.e. it is required), I'll open one up. Thanks!
Modify the ExprUseVisitor to walk each part of an AutoRef, and in
particular to treat an AutoUnsize as as kind of \"instantaneous\" borrow
of the value being unsized. This prevents us from feeding uninitialized
data.
This caused a problem for the eager reborrow of comparison traits,
because that wound up introducing a \"double AutoRef\", which was not
being thoroughly checked before but turned out not to type check.
Fortunately, we can just remove that \"eager reborrow\" as it is no longer
needed now that `PartialEq` doesn't force both LHS and RHS to have the
same type (and even if we did have this problem, the better way would be
to lean on introducing a common supertype).
Fixes#20791.
r? @nrc
particular to treat an AutoUnsize as as kind of "instantaneous" borrow
of the value being unsized. This prevents us from feeding uninitialized
data.
This caused a problem for the eager reborrow of comparison traits,
because that wound up introducing a "double AutoRef", which was not
being thoroughly checked before but turned out not to type check.
Fortunately, we can just remove that "eager reborrow" as it is no longer
needed now that `PartialEq` doesn't force both LHS and RHS to have the
same type (and even if we did have this problem, the better way would be
to lean on introducing a common supertype).
Encode more precise scoping rules for function params
Function params outlive everything in the body (incl temporaries). Thus if we assign them their own `CodeExtent`, the region inference can properly show that it is sound to have temporaries with destructors that reference the parameters (because such temporaries will be dropped before the parameters are dropped).
Fix#23338
A recent change to the implementation of range iterators meant that,
even when stepping by 1, the iterators *always* involved checked
arithmetic.
This commit reverts to the earlier behavior (while retaining the
refactoring into traits).
Fixes#24095Closes#24119
cc #24014
r? @alexcrichton
Addresses issue #22425. See `src/test/compile-fail/macro-incomplete-parse.rs` for a relevant test:
macro-incomplete-parse.rs:15:9: 15:10 error: macro expansion ignores token `,` and any following
macro-incomplete-parse.rs:15 , //~ ERROR macro expansion ignores token `,`
^
macro-incomplete-parse.rs:27:1: 27:17 note: caused by the macro expansion here; the usage of `ignored_item` is likely invalid in this context
macro-incomplete-parse.rs:27 ignored_item!();
^~~~~~~~~~~~~~~~
macro-incomplete-parse.rs:20:14: 20:15 error: macro expansion ignores token `,` and any following
macro-incomplete-parse.rs:20 () => ( 1, 2 ) //~ ERROR macro expansion ignores token `,`
^
macro-incomplete-parse.rs:30:5: 30:21 note: caused by the macro expansion here; the usage of `ignored_expr` is likely invalid in this context
macro-incomplete-parse.rs:30 ignored_expr!();
^~~~~~~~~~~~~~~~
macro-incomplete-parse.rs:24:14: 24:15 error: macro expansion ignores token `,` and any following
macro-incomplete-parse.rs:24 () => ( 1, 2 ) //~ ERROR macro expansion ignores token `,`
^
macro-incomplete-parse.rs:32:9: 32:23 note: caused by the macro expansion here; the usage of `ignored_pat` is likely invalid in this context
macro-incomplete-parse.rs:32 ignored_pat!() => (),
^~~~~~~~~~~~~~
This does not address the case of improper expansion inside of an impl { } as seen in issue #21607.
I'm not sure if the note text is ideal, but it can be refined if needed.
A recent change to the implementation of range iterators meant that,
even when stepping by 1, the iterators *always* involved checked
arithmetic.
This commit reverts to the earlier behavior (while retaining the
refactoring into traits).
Fixes#24095
cc #24014
Statement macros are now treated somewhat like item macros, in that a
statement macro can now expand into a series of statements, rather than
just a single statement.
This allows statement macros to be nested inside other kinds of macros and
expand properly, where previously the expansion would only work when no
nesting was present.
See: src/test/run-pass/macro-stmt_macro_in_expr_macro.rs
src/test/run-pass/macro-nested_stmt_macro.rs
This changes the interface of the MacResult trait. make_stmt has become
make_stmts and now returns a vector, rather than a single item. Plugin
writers who were implementing MacResult will have breakage, as well as
anyone using MacEager::stmt.
See: src/libsyntax/ext/base.rs
This also causes a minor difference in behavior to the diagnostics
produced by certain malformed macros.
See: src/test/compile-fail/macro-incomplete-parse.rs
`Trait`, prefer the object. Also give a nice error for attempts to
manually `impl Trait for Trait`, since they will be ineffectual.
Fixes#24015.
Fixes#24051.
Fixes#24037.
Fixes#23853.
Fixes#21942.
cc #21756.
