jiebi/CodeConvo huggingface dataset:
Code change:
The documentation for with say "no re-ordering of reads and writes across this point is allowed". As I understand it, for a single thread doesn't give anything more than . E.g., a store before the fence could be moved past a load after then fence. Is that correct? cc
Hmm, that's a good point, though the details are a little subtle. From the : I think what this translates into is that guarantees that: no subsequent operations can be moved before this operation if it is a load, and no operations can be moved after this operation if it is a store. The italic parts there aren't present in the current documentation, so that should probably be rectified. I think some annotated source code would really help here!
It actually depends on the other operation, does it not? stores after the fence can be moved up, but stores cannot. TBH I have a hard time thinking in terms of reorderings; I usually think in terms of what actually happens in the underlying memory model. Some of these models can be fully characterized by the allowed reorderings, but not all of them can (as far as we know). And anyway, SC fences are broken in the C11 memory model and probably going to change in the next version, so...^^ On top of that, all are in a total order, and that is the entire point of . (The website says it but you left it away in your quote. Just making sure nobody thinks that a load is the same as an load. It is not.)
I'm actually not entirely sure about that. Another store to the same memory location shouldn't be ordered before, but I don't see from the reference text why an unrelated store with couldn't be. I'd be happy for this to be rephrased this in terms of the memory model, but I'm not entirely sure how we'd even do that. Proposals welcome. I think talking about what can and cannot happen, with examples, is probably the most understandable way to present what the different orderings do. I left off the total order part because it didn't seem directly related to the original question. But you're right that it's a vital part of that shouldn't get lost in the docs!
It says The sequentially-consistent ordering consists of all operation, across all locations, and the order in which they are observed must be consistent across all threads. In particular, if one thread performs two operations (i.e., they are ordered by program-order), then the order in which it does them must match the order in which every other thread observes them. That rules out reordering them. This is the sole justification for the existence of .
Yes, good point. So how about we move the bullet point to bottom and change it to say

Related discussion:
text: ///     } /// } /// ``` <del> /// /// [memory barriers]: https://www.kernel.org/doc/Documentation/memory-barriers.txt </del> #[inline] #[stable(feature = "compiler_fences", since = "1.21.0")] #[rustc_diagnostic_item = "compiler_fence"]
Code change:
Given: results in: Is this intentional due to some soundness issue with having it otherwise? (I cannot think of any...) We could fix this by attaching to manually. While having be structurally matchable is quite boring and useless on its lonesome it prevents other types that contain it from being structurally matchable. (not likely to occur very often, but when it occur it seems like it would be annoying...) r? cc

Related discussion:
text: #![feature(const_transmute)] #![feature(reverse_bits)] #![feature(non_exhaustive)] <ins> #![feature(structural_match)] </ins> #[prelude_import] #[allow(unused)]
Code change:
Given: results in: Is this intentional due to some soundness issue with having it otherwise? (I cannot think of any...) We could fix this by attaching to manually. While having be structurally matchable is quite boring and useless on its lonesome it prevents other types that contain it from being structurally matchable. (not likely to occur very often, but when it occur it seems like it would be annoying...) r? cc

Related discussion:
text: /// /// [drop check]: ../../nomicon/dropck.html #[lang = "phantom_data"] <ins> #[structural_match] </ins> #[stable(feature = "rust1", since = "1.0.0")] pub struct PhantomData<T:?Sized>;
Code change:
Given: results in: Is this intentional due to some soundness issue with having it otherwise? (I cannot think of any...) We could fix this by attaching to manually. While having be structurally matchable is quite boring and useless on its lonesome it prevents other types that contain it from being structurally matchable. (not likely to occur very often, but when it occur it seems like it would be annoying...) r? cc

Related discussion:
text: <ins> // run-pass // This file checks that `PhantomData` is considered structurally matchable. use std::marker::PhantomData; fn main() { let mut count = 0; // A type which is not structurally matchable: struct NotSM; // And one that is: #[derive(PartialEq, Eq)] struct SM; // Check that SM is #[structural_match]: const CSM: SM = SM; match SM { CSM => count += 1, }; // Check that PhantomData<T> is #[structural_match] even if T is not. const CPD1: PhantomData<NotSM> = PhantomData; match PhantomData { CPD1 => count += 1, }; // Check that PhantomData<T> is #[structural_match] when T is. const CPD2: PhantomData<SM> = PhantomData; match PhantomData { CPD2 => count += 1, }; // Check that a type which has a PhantomData is `#[structural_match]`. #[derive(PartialEq, Eq, Default)] struct Foo { alpha: PhantomData<NotSM>, beta: PhantomData<SM>, } const CFOO: Foo = Foo { alpha: PhantomData, beta: PhantomData, }; match Foo::default() { CFOO => count += 1, }; // Final count must be 4 now if all assert_eq!(count, 4); } </ins>
Code change:
The output from , at the top of the page for a or a , etc., includes a line like, Clicking the on a browser w/ restrictive cookie settings (which typically includes ) results in an error similar to the following: Additionally, the section fails to expand or contract, as the exception isn't handled. is attempting to store the collapse/expand state, s.t. later visits to the page presumably maintain that state for the user's convenience. I browse the web with an admittedly somewhat atypical setup: I whitelist cookies. , in most browsers, counts, since it is a similar mechanism of persistence. I think Rust's use of here is fine, but I would request that, if is forbidden by the user agent, that the documentation gracefully "degrade" to just expanding or contracting the requested item, but not persist it. As it is, the JS crashes while storing the state, and appears to never make it to actually expanding/contracting the item.

Related discussion:
text: return false; } <ins> function usableLocalStorage() { // Check if the browser supports localStorage at all: if (typeof(Storage) === "undefined") { return false; } // Check if we can access it; this access will fail if the browser // preferences deny access to localStorage, e.g., to prevent storage of // "cookies" (or cookie-likes, as is the case here). try { window.localStorage; } catch(err) { // Storage is supported, but browser preferences deny access to it. return false; } return true; } </ins> function updateLocalStorage(name, value) { <del> if (typeof(Storage) !== "undefined") { </del> <ins> if (usableLocalStorage()) { </ins> localStorage[name] = value; } else { // No Web Storage support so we do nothing
Code change:
The output from , at the top of the page for a or a , etc., includes a line like, Clicking the on a browser w/ restrictive cookie settings (which typically includes ) results in an error similar to the following: Additionally, the section fails to expand or contract, as the exception isn't handled. is attempting to store the collapse/expand state, s.t. later visits to the page presumably maintain that state for the user's convenience. I browse the web with an admittedly somewhat atypical setup: I whitelist cookies. , in most browsers, counts, since it is a similar mechanism of persistence. I think Rust's use of here is fine, but I would request that, if is forbidden by the user agent, that the documentation gracefully "degrade" to just expanding or contracting the requested item, but not persist it. As it is, the JS crashes while storing the state, and appears to never make it to actually expanding/contracting the item.

Related discussion:
text: } function getCurrentValue(name) { <del> if (typeof(Storage) !== "undefined" && localStorage[name] !== undefined) { </del> <ins> if (usableLocalStorage() && localStorage[name] !== undefined) { </ins> return localStorage[name]; } return null;
Code change:
Spawned off of 's on :
to be clear: we don't need to use to reproduce the problem, right? I.e. hypothetically examples exist that don't use that feature? In particular I know this problem is in some way related to , which is definitely a true regression of stable code.
Right, this here is not really a regression. It is just an ICE that should be an error and it is fixed by We can probably do this without const_let, but I couldn't come up with an example.
A user is the
I have tried to reduce the problem. This repository is smaller, but still fails on : . The same crate builds on stable.
I think you are encountering which has a fix in (making everything work again) This issue is different, even though the symptom is the same right now. When this issue is fixed (via ), the ICE will become a hard error.

Related discussion:
text: if self.alloc_map.contains_key(&alloc) { // Not yet interned, so proceed recursively self.intern_static(alloc, mutability)?; <ins> } else if self.dead_alloc_map.contains_key(&alloc) { // dangling pointer return err!(ValidationFailure( "encountered dangling pointer in final constant".into(), )) </ins> } } Ok(())
Code change:
Spawned off of 's on :
to be clear: we don't need to use to reproduce the problem, right? I.e. hypothetically examples exist that don't use that feature? In particular I know this problem is in some way related to , which is definitely a true regression of stable code.
Right, this here is not really a regression. It is just an ICE that should be an error and it is fixed by We can probably do this without const_let, but I couldn't come up with an example.
A user is the
I have tried to reduce the problem. This repository is smaller, but still fails on : . The same crate builds on stable.
I think you are encountering which has a fix in (making everything work again) This issue is different, even though the symptom is the same right now. When this issue is fixed (via ), the ICE will become a hard error.

Related discussion:
text: <ins> // https://github.com/rust-lang/rust/issues/55223 #![feature(const_let)] union Foo<'a> { y: &'a (), long_live_the_unit: &'static (), } const FOO: &() = { //~ ERROR any use of this value will cause an error let y = (); unsafe { Foo { y: &y }.long_live_the_unit } }; fn main() {} </ins>
Code change:
Spawned off of 's on :
to be clear: we don't need to use to reproduce the problem, right? I.e. hypothetically examples exist that don't use that feature? In particular I know this problem is in some way related to , which is definitely a true regression of stable code.
Right, this here is not really a regression. It is just an ICE that should be an error and it is fixed by We can probably do this without const_let, but I couldn't come up with an example.
A user is the
I have tried to reduce the problem. This repository is smaller, but still fails on : . The same crate builds on stable.
I think you are encountering which has a fix in (making everything work again) This issue is different, even though the symptom is the same right now. When this issue is fixed (via ), the ICE will become a hard error.

Related discussion:
text: <ins> error: any use of this value will cause an error --> $DIR/dangling-alloc-id-ice.rs:10:1 | LL | / const FOO: &() = { //~ ERROR any use of this value will cause an error LL | |     let y = (); LL | |     unsafe { Foo { y: &y }.long_live_the_unit } LL | | }; | |__^ type validation failed: encountered dangling pointer in final constant | = note: #[deny(const_err)] on by default error: aborting due to previous error </ins>
Code change:
Spawned off of 's on :
to be clear: we don't need to use to reproduce the problem, right? I.e. hypothetically examples exist that don't use that feature? In particular I know this problem is in some way related to , which is definitely a true regression of stable code.
Right, this here is not really a regression. It is just an ICE that should be an error and it is fixed by We can probably do this without const_let, but I couldn't come up with an example.
A user is the
I have tried to reduce the problem. This repository is smaller, but still fails on : . The same crate builds on stable.
I think you are encountering which has a fix in (making everything work again) This issue is different, even though the symptom is the same right now. When this issue is fixed (via ), the ICE will become a hard error.

Related discussion:
text: <ins> #![feature(const_let)] const FOO: *const u32 = { //~ ERROR any use of this value will cause an error let x = 42; &x }; fn main() { let x = FOO; } </ins>
Code change:
Spawned off of 's on :
to be clear: we don't need to use to reproduce the problem, right? I.e. hypothetically examples exist that don't use that feature? In particular I know this problem is in some way related to , which is definitely a true regression of stable code.
Right, this here is not really a regression. It is just an ICE that should be an error and it is fixed by We can probably do this without const_let, but I couldn't come up with an example.
A user is the
I have tried to reduce the problem. This repository is smaller, but still fails on : . The same crate builds on stable.
I think you are encountering which has a fix in (making everything work again) This issue is different, even though the symptom is the same right now. When this issue is fixed (via ), the ICE will become a hard error.

Related discussion:
text: <ins> error: any use of this value will cause an error --> $DIR/dangling_raw_ptr.rs:3:1 | LL | / const FOO: *const u32 = { //~ ERROR any use of this value will cause an error LL | |     let x = 42; LL | |     &x LL | | }; | |__^ type validation failed: encountered dangling pointer in final constant | = note: #[deny(const_err)] on by default error: aborting due to previous error </ins>
Code change:
With following doctest, where the cfg attribute spans multiple lines, the final program is invalid: the wrapping method doesn't take into account the dangling line that closes the attribute. rust /// # #![cfgattr(not(dox), feature(cfgtargetfeature, targetfeature, /// # stdsimd))] /// /// fn foo() { /// let mut dst = [0]; /// addquickly(&[1], &[2], &mut dst); /// asserteq!(dst[0], 3); /// } ///
cc
cc
I don't see a message associated with the stack trace, is that missing?
The problem lies in how rustdoc parses doctests. It scans lines for crate-level attributes and statements, but it doesn't do anything more intelligent than checking the beginning of each line: We recently changed the parsing for and detection to use the libsyntax parser, but this initial scan is still a string-based search. The way to fix the test in the OP is to actually remove the part of it - rustdoc doesn't pass on any information into doctest compilation, so those features are going to be enabled regardless.
This is the associated message:

Related discussion:
text: self.unclosed_delims.extend(snapshot.unclosed_delims.clone()); } <ins> pub fn unclosed_delims(&self) -> &[UnmatchedBrace] { &self.unclosed_delims } </ins> /// Create a snapshot of the `Parser`. pub(super) fn create_snapshot_for_diagnostic(&self) -> SnapshotParser<'a> { let mut snapshot = self.clone();
Code change:
With following doctest, where the cfg attribute spans multiple lines, the final program is invalid: the wrapping method doesn't take into account the dangling line that closes the attribute. rust /// # #![cfgattr(not(dox), feature(cfgtargetfeature, targetfeature, /// # stdsimd))] /// /// fn foo() { /// let mut dst = [0]; /// addquickly(&[1], &[2], &mut dst); /// asserteq!(dst[0], 3); /// } ///
cc
cc
I don't see a message associated with the stack trace, is that missing?
The problem lies in how rustdoc parses doctests. It scans lines for crate-level attributes and statements, but it doesn't do anything more intelligent than checking the beginning of each line: We recently changed the parsing for and detection to use the libsyntax parser, but this initial scan is still a string-based search. The way to fix the test in the OP is to actually remove the part of it - rustdoc doesn't pass on any information into doctest compilation, so those features are going to be enabled regardless.
This is the associated message:

Related discussion:
text: use rustc_middle::hir::map::Map; use rustc_middle::hir::nested_filter; use rustc_middle::ty::TyCtxt; <ins> use rustc_parse::maybe_new_parser_from_source_str; use rustc_parse::parser::attr::InnerAttrPolicy; </ins> use rustc_session::config::{self, CrateType, ErrorOutputType}; <ins> use rustc_session::parse::ParseSess; </ins> use rustc_session::{lint, DiagnosticOutput, Session}; use rustc_span::edition::Edition; use rustc_span::source_map::SourceMap;
Code change:
With following doctest, where the cfg attribute spans multiple lines, the final program is invalid: the wrapping method doesn't take into account the dangling line that closes the attribute. rust /// # #![cfgattr(not(dox), feature(cfgtargetfeature, targetfeature, /// # stdsimd))] /// /// fn foo() { /// let mut dst = [0]; /// addquickly(&[1], &[2], &mut dst); /// asserteq!(dst[0], 3); /// } ///
cc
cc
I don't see a message associated with the stack trace, is that missing?
The problem lies in how rustdoc parses doctests. It scans lines for crate-level attributes and statements, but it doesn't do anything more intelligent than checking the beginning of each line: We recently changed the parsing for and detection to use the libsyntax parser, but this initial scan is still a string-based search. The way to fix the test in the OP is to actually remove the part of it - rustdoc doesn't pass on any information into doctest compilation, so those features are going to be enabled regardless.
This is the associated message:

Related discussion:
text: edition: Edition, test_id: Option<&str>, ) -> (String, usize, bool) { <del> let (crate_attrs, everything_else, crates) = partition_source(s); </del> <ins> let (crate_attrs, everything_else, crates) = partition_source(s, edition); </ins> let everything_else = everything_else.trim(); let mut line_offset = 0; let mut prog = String::new();
Code change:
With following doctest, where the cfg attribute spans multiple lines, the final program is invalid: the wrapping method doesn't take into account the dangling line that closes the attribute. rust /// # #![cfgattr(not(dox), feature(cfgtargetfeature, targetfeature, /// # stdsimd))] /// /// fn foo() { /// let mut dst = [0]; /// addquickly(&[1], &[2], &mut dst); /// asserteq!(dst[0], 3); /// } ///
cc
cc
I don't see a message associated with the stack trace, is that missing?
The problem lies in how rustdoc parses doctests. It scans lines for crate-level attributes and statements, but it doesn't do anything more intelligent than checking the beginning of each line: We recently changed the parsing for and detection to use the libsyntax parser, but this initial scan is still a string-based search. The way to fix the test in the OP is to actually remove the part of it - rustdoc doesn't pass on any information into doctest compilation, so those features are going to be enabled regardless.
This is the associated message:

Related discussion:
text: rustc_span::create_session_if_not_set_then(edition, |_| { use rustc_errors::emitter::{Emitter, EmitterWriter}; use rustc_errors::Handler; <del> use rustc_parse::maybe_new_parser_from_source_str; </del> use rustc_parse::parser::ForceCollect; <del> use rustc_session::parse::ParseSess; </del> use rustc_span::source_map::FilePathMapping; let filename = FileName::anon_source_code(s);
Code change:
With following doctest, where the cfg attribute spans multiple lines, the final program is invalid: the wrapping method doesn't take into account the dangling line that closes the attribute. rust /// # #![cfgattr(not(dox), feature(cfgtargetfeature, targetfeature, /// # stdsimd))] /// /// fn foo() { /// let mut dst = [0]; /// addquickly(&[1], &[2], &mut dst); /// asserteq!(dst[0], 3); /// } ///
cc
cc
I don't see a message associated with the stack trace, is that missing?
The problem lies in how rustdoc parses doctests. It scans lines for crate-level attributes and statements, but it doesn't do anything more intelligent than checking the beginning of each line: We recently changed the parsing for and detection to use the libsyntax parser, but this initial scan is still a string-based search. The way to fix the test in the OP is to actually remove the part of it - rustdoc doesn't pass on any information into doctest compilation, so those features are going to be enabled regardless.
This is the associated message:

Related discussion:
text: (prog, line_offset, supports_color) } <del> // FIXME(aburka): use a real parser to deal with multiline attributes fn partition_source(s: &str) -> (String, String, String) { </del> <ins> fn check_if_attr_is_complete(source: &str, edition: Edition) -> bool { if source.is_empty() { // Empty content so nothing to check in here... return true; } rustc_span::create_session_if_not_set_then(edition, |_| { let filename = FileName::anon_source_code(source); let sess = ParseSess::with_silent_emitter(None); let mut parser = match maybe_new_parser_from_source_str(&sess, filename, source.to_owned()) { Ok(p) => p, Err(_) => { debug!("Cannot build a parser to check mod attr so skipping..."); return true; } }; // If a parsing error happened, it's very likely that the attribute is incomplete. if !parser.parse_attribute(InnerAttrPolicy::Permitted).is_ok() { return false; } // We now check if there is an unclosed delimiter for the attribute. To do so, we look at // the `unclosed_delims` and see if the opening square bracket was closed. parser .unclosed_delims() .get(0) .map(|unclosed| { unclosed.unclosed_span.map(|s| s.lo()).unwrap_or(BytePos(0)) != BytePos(2) }) .unwrap_or(true) }) } fn partition_source(s: &str, edition: Edition) -> (String, String, String) { </ins> #[derive(Copy, Clone, PartialEq)] enum PartitionState { Attrs,
Code change:
With following doctest, where the cfg attribute spans multiple lines, the final program is invalid: the wrapping method doesn't take into account the dangling line that closes the attribute. rust /// # #![cfgattr(not(dox), feature(cfgtargetfeature, targetfeature, /// # stdsimd))] /// /// fn foo() { /// let mut dst = [0]; /// addquickly(&[1], &[2], &mut dst); /// asserteq!(dst[0], 3); /// } ///
cc
cc
I don't see a message associated with the stack trace, is that missing?
The problem lies in how rustdoc parses doctests. It scans lines for crate-level attributes and statements, but it doesn't do anything more intelligent than checking the beginning of each line: We recently changed the parsing for and detection to use the libsyntax parser, but this initial scan is still a string-based search. The way to fix the test in the OP is to actually remove the part of it - rustdoc doesn't pass on any information into doctest compilation, so those features are going to be enabled regardless.
This is the associated message:

Related discussion:
text: let mut crates = String::new(); let mut after = String::new(); <ins> let mut mod_attr_pending = String::new(); </ins> for line in s.lines() { let trimline = line.trim();