| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This commit stabilizes the `std::time` module and the `Duration` type.
`Duration::span` remains unstable, and the `Display` implementation for
`Duration` has been removed as it is still being reworked and all trait
implementations for stable types are de facto stable.
This is a [breaking-change] to those using `Duration`'s `Display`
implementation.
Conflicts:
src/librustc/lib.rs
src/libstd/time/duration.rs
|
|
|
|
Fix #27401.
|
|
not actually broken."
This reverts commit 354cf4b56b8e2af67cc68965eb816deec0e79e4b.
|
|
|
|
Fixes #27467.
|
|
This test case has been removed a while ago because it allegedly was broken. But I don't think it is (at least I couldn't reproduce any failure on Linux). Let's give it another chance `:)`
|
|
Fixes #27467.
|
|
After #26694, the overloaded operator and "impl not known at method lookup time" cases started triggering the lint.
I've also added checks for overloaded autoderef and method calls via paths (i.e. `T::method()`).
All new 8 test cases did not trigger the lint before #26694.
r? @huonw
|
|
|
|
After this change, the only remaining symbol we are pulling from libgcc on Win64 is `__chkstk_ms` - the stack probing routine.
|
|
actually broken.
|
|
|
|
Fix #27255.
|
|
|
|
There are still problems in both the design and implementation of this, so we don't want it landing in 1.2.
cc @arielb1 @nikomatsakis
cc #27364
r? @alexcrichton
|
|
|
|
|
|
Rename the unstable option `--xpretty` to `--unpretty`
(Inspired by discussion with Gankro.)
Make sure this gets a low priority if it gets r-plussed!
|
|
I think this was just missed when `Send` and `Sync` were redone, since it seems odd to not be able to use things like `Arc<AtomicPtr>`. If it was intentional feel free to just close this.
I used another test as a template for writing mine, so I hope I got all the headers and stuff right.
|
|
(Inspired by discussion with Gankro.)
|
|
There are multiple issues with them as designed and implemented.
cc #27364
|
|
This also calls the right API, which e.g. prevents a suggestion
for #![feature(unboxed_closures)] on stable.
Fixes #26970
r? @steveklabnik
|
|
Closure variables represent the closure environment, not the closure
function, so the identifier used to ensure that the debuginfo is unique
for each kind of closure needs to be based on the closure upvars and not
the function signature.
|
|
Improves diagnostics in various locations, namely:
* A few error messages that orignally were a mix of an error message and suggestion how to fix it have been split up into two messages: an error and help/hint.
* Never report “illegal”. Fixes https://github.com/rust-lang/rust/issues/27288
|
|
Fixes #27033
Fixes #27077
r? @alexcrichton
|
|
This fixes multiple bugs, and as several of these are soundness issue, is a [breaking-change].
r? @pnkfelix
|
|
This commit is an implementation of [RFC 1193][rfc] which adds the ability to
the compiler to cap the lint level for the entire compilation session. This flag
will ensure that no lints will go above this level, and Cargo will primarily use
this flag passing `--cap-lints allow` to all upstream dependencies.
[rfc]: https://github.com/rust-lang/rfcs/pull/1193
Closes #27259
|
|
This commit is an implementation of [RFC 1193][rfc] which adds the ability to
the compiler to cap the lint level for the entire compilation session. This flag
will ensure that no lints will go above this level, and Cargo will primarily use
this flag passing `--cap-lints allow` to all upstream dependencies.
[rfc]: https://github.com/rust-lang/rfcs/pull/1193
Closes #27259
|
|
|
|
Mostly by splitting error messages into proper pairs of errors and helps
|
|
|
|
this has quite some fallout. but also made lots of stuff more readable imo
[breaking-change] for plugin authors
|
|
as this breaks code that worked under some conditions, this is a
[breaking-change]
Fixes #27033
Fixes #27077
|
|
This also calls the right API, which e.g. prevents a suggestion
for #![feature(unboxed_closures)] on stable.
Fixes #26970
|
|
|
|
Add dropflag hints (stack-local booleans) for unfragmented paths in trans. Part of #5016.
Added code to maintain these hints at runtime, and to conditionalize drop-filling and calls to destructors.
In this early stage of my incremental implementation strategy, we are using hints, so we are always free to leave out a flag for a path -- then we just pass `None` as the dropflag hint in the corresponding schedule cleanup call. But, once a path has a hint, we must at least maintain it: i.e. if the hint exists, we must ensure it is never set to "moved" if the data in question might actually have been initialized. It remains sound to conservatively set the hint to "initialized" as long as the true drop-flag embedded in the value itself is up-to-date.
I hope the commit series has been broken up to be readable; most of the commits in the series should build (though I did not always check this).
----
Oh, I think this technically qualifies as a:
[breaking-change]
because it removes drop-filling in some cases where one could previously observe it. That should only affect `unsafe` code; no safe code should be able to inspect whether the drop-fill was present or not. For an example of code that needed to change to account for this, see commit a81c24ae0216ab47df59acd724f8a33124fb6d97 (a unit test of the `move_val_init` intrinsic). I have not encountered actual code that needed to be updated to account for the change, since this should only be skipping the drop-filling on *moved* values, not on dropped one, and so even types that use `unsafe_no_drop_flag` should be unchanged by this particular PR. (Their time will come later.)
|
|
drop is in use.
|
|
The functionality this was testing was removed somewhere along the line, and
this commit restores what it was testing.
Closes #20586
|
|
Closure variables represent the closure environment, not the closure
function, so the identifier used to ensure that the debuginfo is unique
for each kind of closure needs to be based on the closure upvars and not
the function signature.
|
|
FreeBSD i386 snapshot is missing, failed tests (possibly spurious).
r? @alexcrichton
|
|
This reverts commit a0efd3a3d99a98e3399a4f07abe6a67cf0660335.
This commit caused a lot of unintended breakage for many Cargo builds. The problem is that Cargo compiles build scripts with `-C prefer-dynamic`, so the standard library is always dynamically linked and hence any imports need to be marked with `dllimport`. Dependencies of build scripts, however, were compiled as rlibs and did not have their imports tagged with `dllimport`, so build scripts would fail to link.
While known that this situation would break, it was unknown that it was a common scenario in the wild. As a result I'm just reverting these heuristics for now.
|
|
The functionality this was testing was removed somewhere along the line, and
this commit restores what it was testing.
Closes #20586
|
|
|
|
Fixes issue #27302.
|
|
Fixes issue #27302.
|
|
|
|
Fixes issue #27268.
r? @nikomatsakis
|
|
This reverts commit a0efd3a3d99a98e3399a4f07abe6a67cf0660335.
|
|
This PR completes [RFC 213](https://github.com/rust-lang/rfcs/blob/master/text/0213-defaulted-type-params.md) by allowing default type parameters to influence inference. This is almost certainly a breaking change due to interactions between default type parameters and the old fallback algorithm used for integral and floating point literals.
The error messages still require polish but I wanted to get early review and feedback from others on the the changes, error messages, and test cases. I also imagine we will want to run anywhere from 1-3 versions of this on crater and evaluate the impact, and it would be best to get that ball rolling.
The only outstanding issue I'm aware of is that type alias defaults don't work. It seems this may require significant restructuring, since during inference type aliases have already been expanded. @nikomatsakis might be able to provide some clarity here.
r? @nikomatsakis
cc @eddyb @Gankro @aturon @brson
|
