| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
This reverts commit 80cf3f99f4a3377fd9b544d18017ef29b8713dfd.
|
|
Backport of #44215
Backport of https://github.com/rust-lang/rust/pull/44215.
r? @alexcrichton
cc @nikomatsakis
|
|
|
|
|
|
This boolean field on the error `Handler` is toggled to silence
warnings when `-A warnings` is passed. (This is actually a separate
mechanism from the global lint level—whether there's some redundancy
to be factored away here is an important question, but not one we
concern ourselves with in this commit.) But the same rationale
applies for `--cap-lints allow`. In particular, this makes the "soft"
feature-gate warning introduced in 8492ad24 (which is not a lint, but
just calls `struct_span_warn`) not pollute the builds of dependent
crates.
Thanks to @kennytm for pointing out the potential of
`can_emit_warnings` for this purpose.
Resolves #44213.
|
|
|
|
(cherry picked from commit 81bac74c2ddc6c39f3628a36966f4a56a1282d02)
|
|
|
|
This commit flags all allocation-related functions in liballoc as "this can't
unwind" which should largely resolve the size-related issues found on #42808.
The documentation on the trait was updated with such a restriction (they can't
panic) as well as some other words about the relative instability about
implementing a bullet-proof allocator.
Closes #42808
|
|
Fixes issue #43205: ICE in Rvalue::Len evaluation.
- fixes evaluation of array length for zero-sized type referenced by rvalue operand.
- adds test to verify fix.
*Cause of the issue*.
Zero-sized aggregates are handled as operands, not lvalues. Therefore while visiting `Assign` statement by `LocalAnalyser`, `mark_as_lvalue()` is not called for related `Local`. This behaviour is controlled by `rvalue_creates_operand()` method.
As result it causes error later, when rvalue operand is evaluated in `trans_rvalue_operand()` while handling `Rvalue::Len` case. Array length evaluation invokes `trans_lvalue()` which expects referenced `Local` to be value, not operand.
*How it is fixed*.
In certain cases result of `Rvalue::Len` can be evaluated without calling
`trans_lvalue()`. Method `evaluate_array_len()` is introduced to handle length
evaluation for zero-sized types referenced by Locals.
*Some concerns*.
- `trans_lvalue()` has two other entry points in `rvalue.rs`: it is invoked while handling `Rvalue::Ref` and `Rvalue::Discriminant`. There is a chance those may produce the same issue, but I've failed to write a specific test that leads to this.
- `evaluate_array_len()` performs the same check (matches lvalue and `Local`), which is performed again in `trans_lvalue()`. Without changing `trans_lvalue()` signature to make it aware that caller deals with rvalue, it seems there is no cheap solution to avoid this check.
|
|
|
|
|
|
Add test for wrong code generation for HashSet creation on arm cpu
This is test for #42918.
To reproduce bug you need machine with arm cpu and compile with optimization.
I tried with rustc 1.19.0-nightly (3d5b8c626 2017-06-09),
if compile test with -C opt-level=3 for target=arm-linux-androideabi
and run on "Qualcomm MSM 8974 arm cpu" then assert fails,
if compile and run with -C opt-level=2 it gives segmentation fault.
So I add `compile-flags: -O`.
With rustc 1.19.0 (0ade33941 2017-07-17) all works fine.
Closes #42918
|
|
Fix destruction extent lookup during HIR -> HAIR translation
My method for finding the destruction extent, if any, from cbed41a174aad44e069bec09bf1e502591c132ae (in #39409), was buggy in that it sometimes failed to find an extent that was nonetheless present.
This fixes that, and is cleaner code to boot.
Fix #43457
|
|
Rollup of 7 pull requests
- Successful merges: #43776, #43966, #43979, #44072, #44086, #44090, #44091
- Failed merges:
|
|
Remove duplicates in rustdoc
Fixes #43934.
Two things however:
1. I'm not happy with the current check. It seems completely overkill and unsatisfying.
2. I have no idea how to test if there is only one element and not two.
r? @rust-lang/docs
|
|
feature-gate #[must_use] for functions as `fn_must_use`
@eddyb I [was](https://github.com/rust-lang/rust/pull/43728#issuecomment-320854120) [dithering](https://github.com/rust-lang/rust/pull/43728#issuecomment-320856407) on this, but [your comment](https://github.com/rust-lang/rust/issues/43302#issuecomment-321174989) makes it sound like we do want a feature gate for this? Please advise.
r? @eddyb
|
|
Fix a byte/char confusion issue in the error emitter
Fixes #44078. Fixes #44023.
The start_col member is given in chars, while the code previously assumed it was given in bytes.
The more basic issue #44080 doesn't get fixed.
|
|
This is test for #42918.
To reproduce bug you need machine with arm cpu and compile with optimization.
I tried with rustc 1.19.0-nightly (3d5b8c626 2017-06-09),
if compile test with -C opt-level=3 for target=arm-linux-androideabi
and run on "Qualcomm MSM 8974 arm cpu" then assert fails,
if compile and run with -C opt-level=2 it gives segmentation fault.
So I add `compile-flags: -O`.
With rustc 1.19.0 (0ade33941 2017-07-17) all works fine.
Closes #42918
|
|
Fixes #41701.
|
|
Fixes #44078. Fixes #44023.
The start_col member is given in chars,
while the code previously assumed it was given in bytes.
The more basic issue #44080 doesn't get fixed.
|
|
|
|
Adding E0623 for structs
This is a fix to #43275
The error message is
```
+error[E0623]: lifetime mismatch
+ --> $DIR/ex3-both-anon-regions-both-are-structs.rs:15:12
+ |
+14 | fn foo(mut x: Vec<Ref>, y: Ref) {
+ | --- --- these structs are declared with different lifetimes...
+15 | x.push(y);
+ | ^ ...but data from `y` flows into `x` here
+
+error: aborting due to previous error
```
r? @nikomatsakis
|
|
Elaborate trait obligations when typechecking impls
When typechecking trait impl declarations, we only checked that bounds explictly written on the trait declaration hold.
We now also check that bounds which would have been implied by the trait reference do hold.
Fixes #43784.
|
|
|
|
Desugar parenthesized generic arguments in HIR
Fixes ICE in https://github.com/rust-lang/rust/issues/43431 and maybe some other similar issues.
r? @eddyb
|
|
|
|
|
|
- fixes evaluation of array length for zero-sized type referenced by
rvalue operand.
- adds test to verify fix.
Cause of the issue.
Zero-sized aggregates are handled as operands, not lvalues. Therefore while
visiting Assign statement by LocalAnalyser, mark_as_lvalue() is not called for
related Local. This behaviour is controlled by rvalue_creates_operand() method.
As result it causes error later, when rvalue operand is evaluated in
trans_rvalue_operand() while handling Rvalue::Len case. Array length evaluation
invokes trans_lvalue() which expects referenced Local to be value, not operand.
How it is fixed.
In certain cases result of Rvalue::Len can be evaluated without calling
trans_lvalue(). Method evaluate_array_len() is introduced to handle length
evaluation for zero-sized types referenced by Locals.
|
|
Fix little-endian assumptions in run-pass/union/union-basic
None
|
|
Support dynamically-linked and/or native musl targets
These changes allow native compilation on musl-based distributions and the use of dynamic libraries on linux-musl targets. This is intended to remove limitations based on past assumptions about musl targets, while maintaining existing behavior by default.
A minor related bugfix is included.
|
|
This continues to be in the matter of #43302.
|
|
Before `#[must_use]` for functions was implemented, a `#[must_use]` attribute
on a function was a no-op. To avoid a breaking change in this behavior, we add
an option for "this-and-such feature is experimental" feature-gate messages to
be a mere warning rather than a compilation-halting failure (so old code that
used to have a useless no-op `#[must_use]` attribute now warns rather than
breaking). When we're on stable, we add a help note to clarify that the feature
isn't "on."
This is in support of #43302.
|
|
We'll actually want a new "soft" warning-only gate to maintain
backwards-compatibility, but it's cleaner to start out with the established,
well-understood gate before implementing the alternative warn-only behavior in
a later commit.
This is in the matter of #43302.
|
|
|
|
|
|
Now that musl supports dynamic libraries (although not by default)
enable the tests that now pass. Additional currently-ignored tests
will pass if rustc is built with crt_static=false in config.toml.
|
|
|
|
Register fn-ptr coercion obligations out of a snapshot
Fixes #43923.
beta-nominating because regression.
r? @eddyb
|
|
Rollup of 5 pull requests
- Successful merges: #43993, #44001, #44010, #44014, #44029
- Failed merges:
|
|
borrowck: name the correct type in error message
Closes #36407.
r? @Mark-Simulacrum
|
|
Make sure crates not opting in to staged_api don't use staged_api
This also fixes the problem that with `-Zforce-unstable-if-unmarked` set, crates could not use `#[deprecated]`.
If you prefer, I can instead submit another version which just fixes this problem, but still allows the staged API attributes for all crates when `-Zforce-unstable-if-unmarked` is set. I have prepared that at <https://github.com/RalfJung/rust/tree/staged2>. As yet another alternative, @alexcrichton suggested to turn this error into a lint, but that seems to be much more work, so is it worth it?
Cc @alexcrichton #43975
|
|
Point out missing if conditional
On a case where an else conditional is missing, point this out
instead of the token immediately after the (incorrect) else block:
```
error: missing condition for `if` statemementt push fork -f
--> $DIR/issue-13483.rs:16:5
|
13 | } else if {
| ^ expected if condition here
```
instead of
```
error: expected `{`, found `else`
--> ../../src/test/ui/issue-13483.rs:14:7
|
14 | } else {
| ^^^^
```
Fix #13483.
|
|
Generate builtin impls for `Clone`
This fixes a long-standing ICE and limitation where some builtin types implement `Copy` but not `Clone` (whereas `Clone` is a super trait of `Copy`).
However, this PR has a few side-effects:
* `Clone` is now marked as a lang item.
* `[T; N]` is now `Clone` if `T: Clone` (currently, only if `T: Copy` and for `N <= 32`).
* `fn foo<'a>() where &'a mut (): Clone { }` won't compile anymore because of how bounds for builtin traits are handled (e.g. same thing currently if you replace `Clone` by `Copy` in this example). Of course this function is unusable anyway, an error would pop as soon as it is called.
Hence, I'm wondering wether this PR would need an RFC...
Also, cc-ing @nikomatsakis, @arielb1.
Related issues: #28229, #24000.
|
|
syntax: Relax path grammar
TLDR: Accept the disambiguator `::` in "type" paths (`Type::<Args>`), accept the disambiguator `::` before parenthesized generic arguments (`Fn::(Args)`).
The "turbofish" disambiguator `::<>` in expression paths is a necessary evil required for path parsing to be both simple and to give reasonable results.
Since paths in expressions usually refer to values (but not necessarily, e.g. `Struct::<u8> { field: 0 }` is disambiguated, but refers to a type), people often consider `::<>` to be inherent to *values*, and not *expressions* and want to write disambiguated paths for values even in contexts where disambiguation is not strictly necessary, for example when a path is passed to a macro `m!(Vec::<i32>::new)`.
The problem is that currently, if the disambiguator is not *required*, then it's *prohibited*. This results in confusion - see https://github.com/rust-lang/rust/issues/41740, https://internals.rust-lang.org/t/macro-path-uses-novel-syntax/5561.
This PR makes the disambiguator *optional* instead of prohibited in contexts where it's not strictly required, so people can pass paths to macros in whatever form they consider natural (e.g. disambiguated form for value paths).
This PR also accepts the disambiguator in paths with parenthesized arguments (`Fn::(Args)`) for consistency and to simplify testing of stuff like https://github.com/rust-lang/rust/pull/41856#issuecomment-301219194.
Closes https://github.com/rust-lang/rust/issues/41740
cc @rust-lang/lang
r? @nikomatsakis
|
|
rustc: Add `Local` to the HIR map of parents
When walking parents for lints we want to be sure to hit `let` statements which
can have attributes, so hook up these statements in the HIR map.
Closes #43910
|
|
Fixes #43923.
|
|
Improve placement of `use` suggestions
r? @nrc
cc @estebank @Mark-Simulacrum
fixes #42835
fixes #42548
fixes #43769
|
