similar to: Coding standards: duplicating method comments?

On 30 Jan 2018, at 19:56, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Is this bad style? It seems the current codebase is inconsistent on > this point. The upside of such duplication is that it reduces the need > to cross-reference to other files when using a dumb editor. I generally use the rendered docs on the LLVM web site when using a dumb editor, so

On 01/31/2018 02:37 AM, David Chisnall via llvm-dev wrote: > On 30 Jan 2018, at 19:56, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Is this bad style? It seems the current codebase is inconsistent on >> this point. The upside of such duplication is that it reduces the need >> to cross-reference to other files when using a dumb editor. > I

On 1 February 2018 at 03:44, Philip Reames <listmail at philipreames.com> wrote: > > > On 01/31/2018 02:37 AM, David Chisnall via llvm-dev wrote: >> >> On 30 Jan 2018, at 19:56, Alex Bradbury via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>> >>> Is this bad style? It seems the current codebase is inconsistent on >>> this

Hi LLVM-Dev, I have just integrated the changes from top-of-tree at SVN #262824 (yesterday) having been previously at #262217 (a week ago). I am getting the following error for every instruction: CUSTOMBUILD : error : No schedule information for instruction 'FOOBAR' What has changed that would cause this and how can I fix it in my target? Thanks, MartinO

On Tue, 29 Jan 2019 at 21:05, JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The patch is about ready to land, which means any older compiler will soft-error (which you can turn off with LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN). I think we should then cherry-pick the patch to the LLVM 8 branch. > > The last remaining issue are the buildbots. I audited *all* bots in

After a few attempts I think we’re in sight of success: we only have the two following bots remaining with old versions of libstdc++ and new versions of clang: polly-amd64-linux polly-arm-linux Once fixed the toolchain bump should stick. > On Jan 31, 2019, at 2:07 PM, JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > >> On Jan 31, 2019, at 2:03 PM,

Hi From what I understand about documentation about require_dependency, this function will work like require but the file will be reloaded on every request to the server when in development mode. I have bootstrapped am minimal RoR project with 0.13.1 Rails. I have created a minimal Controller and hooked up it''s "index" action at the site root. I have also created a

According to the LLVM coding standards, Immediately after the header file comment <http://llvm.org/docs/CodingStandards.html#header-file-comment> (and include guards if working on a header file), the minimal list of #includes <http://llvm.org/docs/CodingStandards.html#minimal-list-of-includes>required by the file should be listed. We prefer these #includes to be listed in this order:

Hello All, I''ve just upgraded to rspec/rspec_on_rails 0.9.3 and am very excited about shared descriptions. They couldn''t have come at a better time: I just finished refactoring some REST controllers so that the bulk of the actions are inherited from a superclass. Now I can write the specs once, too. :) I''ve hit a couple of snags, though. I thought I''d

Generally it is safer to include ISO headers first (using the ‘#include <...>’ form) so as to minimise the possibility that a later user declaration or macro definition interferes with the correctness of the Standard libraries. It also tends to make pre-compiled header implementations faster and more shareable across a larger set of files. I would like to suggest revising the LLVM

On Mon, Dec 11, 2017 at 3:37 PM, Mikhail Zolotukhin via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Hi Kim, > > On Dec 10, 2017, at 7:39 AM, Kim Gräsman <kim.grasman at gmail.com> wrote: > > Hi Michael, > > On Thu, Dec 7, 2017 at 3:16 AM, Michael Zolotukhin > <mzolotukhin at apple.com> wrote: > > > Nice to IWYU developers here:) I wonder how

Hello, In one recent change (https://anongit.mindrot.org/openssh.git/commit/?id=2b13d3934d5803703c04803ca3a93078ecb5b715), I noticed a regression. If ssh-keygen is given a private file without passphrase and without the corresponding .pub file, I doesn't extract the comment after the commit, while it did before: Before the commit: $ ./ssh-keygen -q -t dsa -N '' -C foobar -f

Can someone explain what the problem is when I use the generating function? And how to get debug() to stop in the Superclass initialize method? ---- source ----- setClass("Superclass", representation(id = "character"), contains = "VIRTUAL") setMethod("initialize", signature(.Object = "Superclass"),

I have some specs that involve the use of eval and class definitions to test code generation. I want to always start with a clean slate so none of my tests fail or succeed incorrectly due to artifacts left over from previous specs. Example of my situation Spec 1 defines class Fish class Cod < Fish Spec 2 defines class Animal class Cod < Animal In this situation the

I'm a little late to the party, but one observation that I haven't seen mentioned is that simply removing #includes and testing that the program compiles is not guaranteed to be a correct transformation. Imagine, for example, that a header file provides an overload of a function that is a better match than one found elsewhere. It will compile either way, but without the #include, you

I''ve got a question about how variables are made available to templates. We have a test that looks something like this: def test_variable_assigned xhr :get, :do_stuff, :id => 1 assert_not_nil assigns(:thing) end And our app code looks like this: class SuperClass < ActionController def do_stuff @parent_model = ParentModel.find(params[:id]) render :template

Hi Le 17/04/2020 ? 05:52, Damien Miller a ?crit?: > On Wed, 15 Apr 2020, Lo?c wrote: > >> Hello, >> >> In one recent change >> (https://anongit.mindrot.org/openssh.git/commit/?id=2b13d3934d5803703c04803ca3a93078ecb5b715), >> I noticed a regression. >> >> If ssh-keygen is given a private file without passphrase and without the >> corresponding

On 14 November 2017 at 16:03, Alex Bradbury <asb at lowrisc.org> wrote: > Dear list, > > At the RISC-V BoF at the LLVM Dev Meeting and the longer working > session the day after, those of us working on RISC-V with LLVM decided > it would be worthwhile to schedule regular sync-up calls in order to > better co-ordinate ongoing work between different developers. This is >

>> reload! Reloading... => true >> puts Class < Module true => nil >> puts Module < Class false => nil >> puts Module < Object true => nil >> puts Object < Module false => nil >> Object.parent => Object The above indicates that the Class object instance inherits from the Module object instance and the Module object instance

"Object is the root of Ruby''s class hierarchy. Its methods are available to all classes unless explicitly overridden." Wouldn''t Class class be at the root of the class hierarchy? After all, look at this: 1.9.2p290 :006 > Object.instance_of? Class => true Object is an instance of class, after all we can use one of Class'' instance methods on Object: