| Age | Commit message (Collapse) | Author | Lines |
|
Remove vector fadd/fmul reduction workarounds
The bugs that this was working around have been fixed in LLVM 9.
r? @gnzlbg
|
|
Remove support for -Zlower-128bit-ops
It is broken and unused
cc https://github.com/rust-lang/rust/issues/58969
blocked https://github.com/rust-lang-nursery/compiler-builtins/pull/302 (removes definitions of the lang items removed in this PR)
r? @alexcrichton
|
|
Introduce `as_deref` to Option
This is re-submission for #59628.
Renames `deref()` to `as_deref()` and adds `deref_mut()` impls and tests.
CC #50264
r? @Kimundi
(I picked you as you're the previous reviewer.)
|
|
Add support for UWP targets
Hi,
This pull request aims at adding support for UWP (Universal Windows Apps) platform.
A few notes:
- This requires a very recent mingw-w64 version (containing this commit and the previous related ones: https://github.com/mirror/mingw-w64/commit/e8c433c871687a78408ae9b40ab7776577db908d#diff-eefdfbfe9cec5f4ebab88c9a64d423a9)
- This was tested using LLVM/clang rather than gcc, and so far it assumes that LLVM/clang will be the native compiler. This is mostly due to the fact that the support for exceptions/stack unwinding for UWP got much more attention in libunwind
- The "uwp" part of the target needs support for it in the `cc-rs` & `backtrace-rs` crates. I'll create the MR there right after I submit this one and will link everything together, but I'm not sure what's the correct way of dealing with external dependencies in the context of rust
- Enabling import libraries and copying them across stages requires a change in cargo, for which I'll open a MR right after I submit this one as well
- The i686 stack unwinding is unsupported for now, because LLVM assumes SjLj, while rust seems to assume SEH will be used. I'm unsure how to fix this
Also, this is my first encounter with rust, so please bear with my code, it might not feel so idiomatic or even correct :)
I'm pretty sure there's a way of doing things in a cleaner way when it comes to win/c.rs, maybe having a UWP & desktop specific modules, and import those conditionally? It doesn't feel right to sprinkle `#[cfg(...)]` all over the place
Off course, I'll gladly update anything you see fit (to the extent of my abilities/knowledge :) )!
Thanks,
|
|
Add note suggesting to borrow a String argument to find
Fix #62843.
|
|
Add test for #51559
Closes #51559
|
|
r=estebank
Add method disambiguation help for trait implementation
Closes #51046
Closes #40471
|
|
Make the parser TokenStream more resilient after mismatched delimiter recovery
Fix #62881, fix #62895.
|
|
Turn `#[global_allocator]` into a regular attribute macro
It was a 99% macro with exception of some diagnostic details.
As a result of the change, `#[global_allocator]` now works in nested modules and even in nameless blocks.
Fixes https://github.com/rust-lang/rust/issues/44113
Fixes https://github.com/rust-lang/rust/issues/58072
|
|
Add tests for overlapping explicitly dropped locals in generators
Closes #62686
r? @tmandry
|
|
rustdoc: make #[doc(include)] relative to the containing file
This matches the behavior of other in-source paths like `#[path]` and the `include_X!` macros.
Fixes https://github.com/rust-lang/rust/pull/58373#issuecomment-462349380
Also addresses https://github.com/rust-lang/rust/issues/44732#issuecomment-467660239
cc #44732
This is still missing a stdsimd change (https://github.com/jonas-schievink/stdsimd/commit/42ed30e0b5fb5e2d11765b5d1e1f36234af85984), so CI will currently fail. I'll land that change once I get initial feedback for this PR.
|
|
Stabilize the type_name intrinsic in core::any
Stabilize `type_name` in `core::any`.
Closes rust-lang/rfcs#1428
FCP completed over there.
`RELEASES.md`: Prefer T-libs for categorization.
|
|
So far it is assumed that using a DLL as a -l parameter argument is ok,
but the assumption doesn't hold when compiling the native code with
llvm.
In which case, an import library is required, so let's build one
This also requires the cargo counterpart to add the import library in
the stamp files, at least when compiling libstd. Otherwise, the files
don't get uplifted
|
|
|
|
Closes rust-lang/rfcs#1428
|
|
Polonius: fix some cases of `killed` fact generation, and most of the `ui` test suite
Since basic Polonius functionality was re-enabled by @matthewjasper in #54468, some tests were still failing in the polonius compare-mode.
This PR fixes all but one test in the `ui` suite by:
- fixing some bugs in the fact generation code, related to the `killed` relation: Polonius would incorrectly reject some NLL-accepted code, because of these missing `killed` facts.
- ignoring some tests in the polonius compare-mode: a lot of those manually test the NLL or migrate mode, and the failures were mostly artifacts of the test revisions, e.g. that `-Z polonius` requires full NLLs. Some others were also both failing with NLL and succeeding with Polonius, which we can't encode in tests at the moment.
- blessing the output of some tests: whenever Polonius and NLL have basically the same errors, except for diagnostics differences, the Polonius output is blessed. Whenever we've advanced into a less experimental phase, we'll want to revisit these cases (much like we did on the NLL test suite last year) to specifically work on diagnostics.
Fact generation changes:
- we now kill loans on the destination place of `Call` terminators
- we now kill loans on the locals destroyed by `StorageDead`
- we now also handle assignments to projections: killing the loans on a either a deref-ed local, or the ones whose `borrowed_place` conflicts with the current place.
One failing test remains: an overflow during fact generation, on a case of polymorphic recursion (and which I'll continue investigating later).
This adds some tests for the fact generation changes, with some simple Polonius cases similar to the existing smoke tests, but also for some cases encountered in the wild (in the `rand` crate for example).
A more detailed write-up is available [here](https://hackmd.io/CjYB0fs4Q9CweyeTdKWyEg?view) with an explanation for each test failure, the steps taken to resolve it (as a commit in the current PR), NLL and Polonius outputs (and diff), etc.
Since they've worked on this before, and we've discussed some of these failures together:
r? @matthewjasper
|
|
|
|
Always emit trailing slash error
Fix #62913.
r? @petrochenkov
|
|
Add test `self-in-enum-definition`
Apparently there was no test covering this...
r? @oli-obk
cc @petrochenkov
|
|
fakenine:normalize_use_of_backticks_compiler_messages_p15, r=Centril
Normalize use of backticks in compiler messages for libsyntax/*
https://github.com/rust-lang/rust/issues/60532
|
|
Suggest trait bound on type parameter when it is unconstrained
Given
```
trait Foo { fn method(&self) {} }
fn call_method<T>(x: &T) {
x.method()
}
```
suggest constraining `T` with `Foo`.
Fix #21673, fix #41030.
|
|
Closes #51559
|
|
fakenine:normalize_use_of_backticks_compiler_messages_p17, r=alexreg
normalize use of backticks for compiler messages in remaining modules
https://github.com/rust-lang/rust/issues/60532
|
|
|
|
|
|
Instead of
```
mod allocator_abi { /* methods */ }
```
we now generate
```
const _: () = { /* methods */ }
```
and use `std_path` for paths referring to standard library entities.
This way we no longer need to generate `use` and `extern crate` imports, and `#[global_allocator]` starts working inside unnamed blocks.
|
|
|
|
|
|
|
|
|
|
Closes #51046
Closes #40471
|
|
|
|
https://github.com/rust-lang/rust/issues/60532
|
|
|
|
|
|
https://github.com/rust-lang/rust/issues/60532
|
|
fakenine:normalize_use_of_backticks_compiler_messages_p14, r=Centril
normalize use of backticks in compiler messages for librustc_allocator
https://github.com/rust-lang/rust/issues/60532
|
|
add rustc_private as a proper language feature gate
At the moment, `rustc_private` as a (library) feature exists by
accident: `char::is_xid_start`, `char::is_xid_continue` methods in
libcore define it.
cc https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/How.20to.20declare.20new.20langauge.20feature.3F
I don't know if this is at all reasonable, but at least tests seem to pass locally. That probably means that we can remove/rename to something more resonable the feature in libcore in the next release?
|
|
Add tests for issue-58887
Closes #58887
|
|
Tweak span for variant not found error
|
|
rustc_typeck: improve diagnostics for _ const/static declarations
This continues https://github.com/rust-lang/rust/pull/62694 and adds type suggestions to const/static declarations with `_` type.
r? @eddyb
|
|
Handle more cases of typos misinterpreted as type ascription
Fix #60933, #54516.
CC #47666, #34255, #48016.
|
|
Delay bug to resolve HRTB ICE
Fix #62203
|
|
|
|
|
|
https://github.com/rust-lang/rust/issues/60532
|
|
fix lexing of comments with many \r
closes #62863
|
|
fakenine:normalize_use_of_backticks_compiler_messages_p13, r=Centril
normalize use of backticks in compiler messages for librustc/hir
https://github.com/rust-lang/rust/issues/60532
|
|
fakenine:normalize_use_of_backticks_compiler_messages_p12, r=Centril
normalize use of backticks in compiler messages for librustc_incremental
https://github.com/rust-lang/rust/issues/60532
|
|
fakenine:normalize_use_of_backticks_compiler_messages_p11, r=GuillaumeGomez
normalize use of backticks in compiler messages for librustc_metadata
https://github.com/rust-lang/rust/issues/60532
|