diff options
| author | bors <bors@rust-lang.org> | 2020-05-03 22:54:55 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2020-05-03 22:54:55 +0000 |
| commit | a0c61a904482129989f5c1e5cb9f1008efb76f7f (patch) | |
| tree | a917faba4deb07e508d9dae797da04317a9f61a8 /library/std/src/sys/unix/stack_overflow.rs | |
| parent | 65b448273dd280401cd440a6740a7cd891525ba3 (diff) | |
| parent | 182133f8c842cff0b737f0e322156a9d6497b05c (diff) | |
| download | rust-a0c61a904482129989f5c1e5cb9f1008efb76f7f.tar.gz rust-a0c61a904482129989f5c1e5cb9f1008efb76f7f.zip | |
Auto merge of #71631 - RalfJung:miri-unleash-the-gates, r=oli-obk
Miri: unleash all feature gates IMO it is silly to unleash features that do not even have a feature gate yet, but not unleash features that do. The only thing this achieves is making unleashed mode annoying to use as we have to figure out the feature flags to enable (and not always do the error messages say what that flag is). Given that the point of `-Z unleash-the-miri-inside-of-you` is to debug the Miri internals, I see no good reason for this extra hurdle. I cannot imagine a situation where we'd use that flag, realize the program also requires some feature gate, and then be like "oh I guess if this feature is unstable I will do something else". Instead, we'll always just add that flag to the code as well, so requiring the flag achieves nothing. r? @oli-obk @ecstatic-morse Fixes https://github.com/rust-lang/rust/issues/71630
Diffstat (limited to 'library/std/src/sys/unix/stack_overflow.rs')
0 files changed, 0 insertions, 0 deletions
