- 21 11月, 2018 1 次提交
-
-
由 bors 提交于
Make const_eval_raw query return just an AllocId r? @oli-obk
-
- 20 11月, 2018 19 次提交
-
-
由 bors 提交于
Allow #[must_use] on traits Addresses https://github.com/rust-lang/rust/issues/55506, but we'll probably want to add it to some library traits like `Iterator` before the issue is considered fixed. Fixes https://github.com/rust-lang/rust/issues/51560. `#[must_use]` is already permitted on traits, with no effect, so this seems like a bug fix, but I might be overlooking something. This currently warns for `impl Trait` or `dyn Trait` when the `Trait` is `#[must_use]` (although I don't think the latter is currently possible, so it's simply future-proofed).
-
由 bors 提交于
Updated RELEASES.md for 1.31.0 [Rendered](https://github.com/Aaronepower/rust/blob/master/RELEASES.md) r? @Mark-Simulacrum cc @rust-lang/release
-
由 Aaron Power 提交于
-
由 bors 提交于
Add temporary renames to manifests for rustfmt/clippy This will be part of our strategy for shipping renamed versions of these components for the Rust 2018 edition. Closes #55967
-
由 bors 提交于
Fix stability hole with `static _` The `underscore_const_names` only gated const items with `_` as the name. `static _: () = ();` works on beta without feature gates right now, this PR fixes that.
-
由 bors 提交于
Revert #51601 Closes: #55985 Specialization of `StepBy<Range(Inclusive)>` results in an incorrectly behaving code when `step_by` is combined with `skip` or `nth`. If this will get merged we probably should reopen issues previously closed by #51601 (if there was any).
-
由 Alex Crichton 提交于
This will be part of our strategy for shipping renamed versions of these components for the Rust 2018 edition. Closes #55967
-
由 Ralf Jung 提交于
-
由 Ralf Jung 提交于
-
由 Ralf Jung 提交于
-
由 Ralf Jung 提交于
-
由 bors 提交于
Ignore non-semantic tokens for 'probably_eq' streams. Improves the situation in #43081 by skipping typically non-semantic tokens when checking for 'probably_eq'. r? @alexcrichton
-
由 varkor 提交于
-
由 varkor 提交于
-
由 varkor 提交于
-
由 varkor 提交于
-
由 varkor 提交于
-
由 varkor 提交于
-
- 19 11月, 2018 20 次提交
-
-
由 bors 提交于
Rollup of 25 pull requests Successful merges: - #55562 (Add powerpc- and powerpc64-unknown-linux-musl targets) - #55564 (test/linkage-visibility: Ignore on musl targets) - #55827 (A few tweaks to iterations/collecting) - #55834 (Forward the ABI of the non-zero sized fields of an union if they have the same ABI) - #55857 (remove unused dependency) - #55862 (in which the E0618 "expected function" diagnostic gets a makeover) - #55867 (do not panic just because cargo failed) - #55894 (miri enum discriminant handling: Fix treatment of pointers, better error when it is undef) - #55916 (Make miri value visitor useful for mutation) - #55919 (core/tests/num: Simplify `test_int_from_str_overflow()` test code) - #55923 (reword #[test] attribute error on fn items) - #55949 (ty: return impl Iterator from Predicate::walk_tys) - #55952 (Update to Clang 7 on CI.) - #55953 (#53488 Refactoring UpvarId) - #55962 (rustdoc: properly calculate spans for intra-doc link resolution errors) - #55963 (Stress test for MPSC) - #55968 (Clean up some non-mod-rs stuff.) - #55970 (Miri backtrace improvements) - #56007 (CTFE: dynamically make sure we do not call non-const-fn) - #56011 (Replace data.clone() by Arc::clone(&data) in mutex doc.) - #56012 (avoid shared ref in UnsafeCell::get) - #56016 (Add VecDeque::resize_with) - #56027 (docs: Add missing backtick in object_safety.rs docs) - #56043 (remove "approx env bounds" if we already know from trait) - #56059 (Increase `Duration` approximate equal threshold to 1us)
-
由 kennytm 提交于
Increase `Duration` approximate equal threshold to 1us Previously this threshold when testing was 100ns, but the Windows documentation states: > which is a high resolution (<1us) time stamp which presumably means that we could have up to 1us resolution, which means that 100ns doesn't capture "equivalent" time intervals due to various bits of rounding here and there. It's hoped that this.. Closes #56034
-
由 Pietro Albini 提交于
remove "approx env bounds" if we already know from trait Alternative to https://github.com/rust-lang/rust/pull/55988 that fixes #55756 -- smaller fix that I cannot see having (correctness) repercussions beyond the test at hand, and hence better for backporting. (Famous last words, I know.) r? @EddyB
-
由 Pietro Albini 提交于
docs: Add missing backtick in object_safety.rs docs Closes #56019. r? @bjorn3
-
由 Pietro Albini 提交于
Add VecDeque::resize_with This already exists on `Vec`; I'm just adding it to `VecDeque`. I wanted to resize a `VecDeque<Vec<T>>` when I didn't know `T: Clone`, so I couldn't use `.resize(n, Vec::new())`. With this I could do `.resize_with(n, Vec::new)` instead, which doesn't need `T: Clone`. Tracking issue: https://github.com/rust-lang/rust/issues/41758
-
由 Pietro Albini 提交于
avoid shared ref in UnsafeCell::get Avoid taking a shared reference in `UnsafeCell::get`. This *should* be taking a raw reference (see https://github.com/rust-lang/rfcs/pull/2582), but that operation is not currently available, so I propose we exploit `repr(transparent)` instead and cast the pointer around. This is required to make `UnsafeCell::get` pass the [stacked borrows implementation](https://www.ralfj.de/blog/2018/11/16/stacked-borrows-implementation.html) in miri (currently, `UnsafeCell::get` is on a whitelist, but that is of course not very satisfying). It shouldn't affect normal execution/codegen. Would be great if we could get this landed and shrink miri's whitelist! Cc @nikomatsakis
-
由 Pietro Albini 提交于
Replace data.clone() by Arc::clone(&data) in mutex doc. Arc::clone(&from) is considered as more idiomatic because it conveys more explicitly the meaning of the code. Since this clone is visible in the official documentation, I thought it could be better to use the more idiomatic version.
-
由 Pietro Albini 提交于
CTFE: dynamically make sure we do not call non-const-fn I'd love to have a test case for this, but I don't know how. I am also really surprised by this test case that changed behavior: Why did it even start execution if it already determined that it shouldn't?!? r? @oli-obk
-
由 Pietro Albini 提交于
Miri backtrace improvements Nicer pretty-printing of the `RUST_CTFE_BACKTRACE`-backtraces: ``` 0: backtrace::backtrace::libunwind::trace::hc410fcb66fe85b11 at /home/r/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.9/src/backtrace/libunwind.rs:53 backtrace::backtrace::trace::h2106294a22648407 at /home/r/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.9/src/backtrace/mod.rs:42 1: backtrace::capture::Backtrace::new_unresolved::h5d8d98b993d092ba at /home/r/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.9/src/capture.rs:88 2: <rustc::mir::interpret::error::EvalError<'tcx> as core::convert::From<rustc::mir::interpret::error::EvalErrorKind<'tcx, u64>>>::from::h6355269b2a661412 at librustc/mir/interpret/error.rs:236 3: <T as core::convert::Into<U>>::into::h70fcb917509539bd at /home/r/src/rust/rustc.2/src/libcore/convert.rs:455 4: <rustc_mir::interpret::eval_context::EvalContext<'a, 'mir, 'tcx, miri::Evaluator<'tcx>> as miri::fn_call::EvalContextExt<'tcx, 'mir>>::emulate_foreign_item::h9cde0e3ce7455a4a at src/fn_call.rs:292 5: <rustc_mir::interpret::eval_context::EvalContext<'a, 'mir, 'tcx, miri::Evaluator<'tcx>> as miri::fn_call::EvalContextExt<'tcx, 'mir>>::find_fn::h83f89524b9d1a49a at src/fn_call.rs:74 6: <miri::Evaluator<'tcx> as rustc_mir::interpret::machine::Machine<'a, 'mir, 'tcx>>::find_fn::hf9980473c4775f0c at src/lib.rs:345 rustc_mir::interpret::terminator::<impl rustc_mir::interpret::eval_context::EvalContext<'a, 'mir, 'tcx, M>>::eval_fn_call::h401dec4a687f96e9 at /home/r/src/rust/rustc.2/src/librustc_mir/interpret/terminator.rs:285 ``` Indentation is now consistent with `RUST_BACKTRACE`, and the frame number is not repeated when there are multiple symbols for a frame. Also preserve the `ty::Instance` for the internal backtrace (showing which frames in the user code where on the interpreter stack when the error happened), used by miri to avoid printing spans for libstd internals: ``` error[E0080]: constant evaluation error: the evaluated program panicked --> /home/r/src/rust/rustc.2/src/libstd/panicking.rs:525:9 | 525 | __rust_start_panic(obj as usize) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked | = note: inside call to `std::panicking::rust_panic` at /home/r/src/rust/rustc.2/src/libstd/panicking.rs:496:5 = note: inside call to `std::panicking::rust_panic_with_hook` at /home/r/src/rust/rustc.2/src/libstd/panicking.rs:390:5 = note: inside call to `std::panicking::continue_panic_fmt` at /home/r/src/rust/rustc.2/src/libstd/panicking.rs:345:5 note: inside call to `std::rt::begin_panic_fmt` at <::std::macros::panic macros>:8:1 --> tests/compile-fail/panic.rs:4:5 | 4 | assert_eq!(5, 6); | ^^^^^^^^^^^^^^^^^ = note: inside call to `main` at /home/r/src/rust/rustc.2/src/libstd/rt.rs:74:34 = note: inside call to closure at /home/r/src/rust/rustc.2/src/libstd/rt.rs:59:75 = note: inside call to closure at /home/r/src/rust/rustc.2/src/libstd/sys_common/backtrace.rs:136:5 = note: inside call to `std::sys_common::backtrace::__rust_begin_short_backtrace::<[closure@DefId(1/1:1913 ~ std[78f0]::rt[0]::lang_start_internal[0]::{{closure}}[0]::{{closure}}[0]) 0:&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe], i32>` at /home/r/src/rust/rustc.2/src/libstd/rt.rs:59:13 = note: inside call to closure at /home/r/src/rust/rustc.2/src/libstd/panicking.rs:310:40 = note: inside call to `std::panicking::try::do_call::<[closure@DefId(1/1:1912 ~ std[78f0]::rt[0]::lang_start_internal[0]::{{closure}}[0]) 0:&&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe], i32>` at /home/r/src/rust/rustc.2/src/libstd/panicking.rs:306:5 = note: inside call to `std::panicking::try::<i32, [closure@DefId(1/1:1912 ~ std[78f0]::rt[0]::lang_start_internal[0]::{{closure}}[0]) 0:&&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe]>` at /home/r/src/rust/rustc.2/src/libstd/panic.rs:398:9 = note: inside call to `std::panic::catch_unwind::<[closure@DefId(1/1:1912 ~ std[78f0]::rt[0]::lang_start_internal[0]::{{closure}}[0]) 0:&&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe], i32>` at /home/r/src/rust/rustc.2/src/libstd/rt.rs:58:25 = note: inside call to `std::rt::lang_start_internal` at /home/r/src/rust/rustc.2/src/libstd/rt.rs:74:5 = note: inside call to `std::rt::lang_start::<()>` ``` Also notice that we show filenames and line numbers here now. r? @oli-obk
-
由 Pietro Albini 提交于
Clean up some non-mod-rs stuff. This includes the following: - Remove unused `non_modrs_mods` from `ParseSess` which as only used for feature gate diagnostics. - Remove the vestiges of the feature gate tests in `test/ui`, they were only partially removed during stabilization. - Fix the run-pass test, it was accidentally removed during stabilization. - Add a ui test to verify error behavior for missing inline-nested mods. - Add some tests for `#[path]` for inline-nested mods (both mod and non-mod-rs). - Enable the diagnostic tests on windows, they should be fixed by #49478. cc @cramertj
-
由 Pietro Albini 提交于
Stress test for MPSC `concurrent_recv_timeout_and_upgrade` reproduces a problem 100% times on my MacBook with command: ``` ./x.py test --stage 0 ./src/test/run-pass/mpsc_stress.rs ``` Thus it is commented out. Other tests cases were useful for catching another test cases which may arise during the fix. This diff is a part of my previous rewrite attempt: #42883 CC #39364
-
由 Pietro Albini 提交于
rustdoc: properly calculate spans for intra-doc link resolution errors Fixes https://github.com/rust-lang/rust/issues/55723 When rustdoc is reporting a resolution error for intra-doc links, it needs to convert a span from one relative to the *markdown* (as the links are only found on the final markdown text) to one relative to the *source code* (as the error reporting is meant to show where the line is in the source, so the user can fix it). However, a calculation for how much "offset" to apply had a subtle error: it trimmed the whole line when attempting to account for leading indentation. This caused it to add in *trailing* whitespace into this calculation, which created an incorrect span. In a lot of situations, this isn't a problem - the span will be shifted in the code slightly, but the warning will still be displayed and mostly legible. However, there is one important situation where this can cause an ICE: multi-byte codepoints. If a shifted span now has a starting point in the middle of a multi-byte codepoint, libsyntax will panic when trying to track what source item it corresponds to. This flew under our radar because trailing whitespace and multi-byte codepoints are both situations that we don't run into in the compiler repo. (There is one more situation where this can error, that will be much harder to fix: block-style doc comments. Lines in a block-style doc comment have a zero-or-more (usually one) character offset per line, causing this calculation to be way off. I'm punting that to another issue, though...)
-
由 Pietro Albini 提交于
#53488 Refactoring UpvarId
-
由 Pietro Albini 提交于
Update to Clang 7 on CI. Handles Linux and macOS. Windows seems to already have been updated. r? @Mark-Simulacrum cc @rust-lang/infra
-
由 Pietro Albini 提交于
ty: return impl Iterator from Predicate::walk_tys Fixes the lazyboye `FIXME` by returning a custom `Iterator` as intended by the original author of the function. It is indeed a bit convoluted, so I'm ok with not changing this if perf results are not favourable enough. Also happy to adjust any names if need be.
-
由 Nick Cameron 提交于
-
由 Alex Crichton 提交于
Previously this threshold when testing was 100ns, but the Windows documentation states: > which is a high resolution (<1us) time stamp which presumably means that we could have up to 1us resolution, which means that 100ns doesn't capture "equivalent" time intervals due to various bits of rounding here and there. It's hoped that this.. Closes #56034
-
由 bors 提交于
[nightly] resolve: Implement uniform paths 2.0 Forward-port of https://github.com/rust-lang/rust/pull/55884 to nightly. r? @ghost
-
由 Pietro Albini 提交于
reword #[test] attribute error on fn items fix of [#55787](https://github.com/rust-lang/rust/issues/55787) Reworded error message from "#[test] attribute is only allowed on fn items" to "#[test] attribute is only allowed on non associated functions"
-
由 Pietro Albini 提交于
core/tests/num: Simplify `test_int_from_str_overflow()` test code This commit changes the test code to compare against easier-to-read, static values instead of relying on the result of `wrapping_add()` which may or may not result in the value that we expect.
-